CRIU on Zwindler's Reflection

zeropod v0.12.0 : un an après, le scale-to-zero tient-il ses promesses ?

Sat, 30 May 2026 12:00:00 +0200

Qu’est-ce que zeropod ?

Il y a un peu moins d’un an, j’avais publié un premier article sur un projet open source qui s’apelle zeropod.

Zeropod is a Kubernetes runtime (more specifically a containerd shim) that automatically checkpoints containers to disk after a certain amount of time of the last TCP connection.

While in scaled down state, it will listen on the same port the application inside the container was listening on and will restore the container on the first incoming connection.

À l’époque, la version stable était la v0.6.x, et j’avais testé sur un cluster k3s. Les résultats étaient mitigés : ça marchait dans les grandes lignes, mais avec des limitations rédhibitoires pour une utilisation un peu sérieuse (probes impossibles, comportement flaky sous charge, temps de checkpointing un peu élevés à mon gout).

Entre temps, le projet a pas mal évolué (maintenant v0.12.0), avec des promesses de corrections et d’améliorations. J’ai donc remis le couvert pour voir où on en est vraiment.

Autre changement : j’ai abandonné k3s pour cette série de tests, pour des raisons que je détaillerai au fil de l’article.

Prérequis

Cette fois-ci, j’ai utilisé un serveur fraîchement provisionné chez mon hébergeur préféré :

Un serveur Ubuntu 24.04.3 LTS (Noble), kernel 6.17.0-35 HWE, 7.7 Gi RAM, 100G disk
Un cluster Kubernetes monté avec kubeadm, flannel comme CNI
containerd vanilla
local-path-provisioner (Rancher) pour avoir un stockage local
Pas de cert-manager ni d’Ingress, on va au plus simple cette fois

Installation

J’ai déjà installé kubeadm plein de fois et certainement que vous aussi donc je ne vous fait pas l’affront de refaire un énième tuto.

# Installer kubeadm, kubelet, kubectl + containerd
sudo kubeadm init --pod-network-cidr=10.42.0.0/16
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Une fois le cluster fonctionnel, l’installation de zeropod est triviale :

# Appliquer le kustomize générique
kubectl apply -k https://github.com/ctrox/zeropod/config/generic

# Ajouter un label à notre unique node
kubectl label node <votre-node> zeropod.ctrox.dev/node=true

# Vérifier que le pod tourne
kubectl -n zeropod-system wait --for=condition=Ready pod -l app.kubernetes.io/name=zeropod-node

C’est tout. Pas de flag spécial, pas de configuration supplémentaire. Sur kubeadm, kubelet est un binaire natif (/usr/bin/kubelet) détecté automatiquement par zeropod.

Note sur k3s : sur k3s, la documentation de zeropod est un peu différente puisque la config à utiliser est config/k3s. Le kustomize ajoute un flag -probe-binary-name=k3s sur l’initContainer pour que le shim sache que le kubelet est embarqué dans le binaire k3s. Lors de mes tests, j’ai constaté que même avec ce flag, le comportement n’était pas celui attendu (le socket tracker ne filtrait pas correctement les probes). Avec la config par défaut, le flag est sur l’initContainer mais pas sur le manager. J’avais suspecté qu’il y avait un autre composant à patcher, mais je n’ai pas creusé plus que ça.

Le DaemonSet déploie les images suivantes :

ghcr.io/ctrox/zeropod-manager:v0.12.0
ghcr.io/ctrox/zeropod-installer:v0.12.0
ghcr.io/ctrox/zeropod-criu:v4.2 (CRIU a été mis à jour depuis v0.6.x)

Vérifions que la runtimeClass zeropod est bien disponible :

kubectl get runtimeclass
NAME HANDLER AGE
zeropod zeropod 30m

Premier test : nginx

Comme la dernière fois, commençons par un test simple avec nginx. On déploie un pod tout bête :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 labels:
 app: nginx
 spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 ports:
 - containerPort: 80

Le passage important, c’est l’annotation zeropod.ctrox.dev/scaledown-duration: 10s et runtimeClassName: zeropod.

Peu après le déploiement, zeropod détecte l’absence de trafic. Le container est checkpointé. Si on regarde les logs du manager :

{"time":"2026-05-29T14:26:37.269453861Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"RUNNING","duration":"0s"}

Puis 10 secondes plus tard :

{"time":"2026-05-29T14:26:47.465510937Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"SCALED_DOWN","duration":"191.259383ms"}

Le champ duration dans le log SCALED_DOWN correspond au temps de checkpoint : 191ms. C’est déjà nettement mieux que les ~400ms de v0.6.x sur k3s (probablement grâce à une mise à jour, peut être CRIU 4.2 ?).

Restauration

Quand on envoie une requête HTTP, le container se réveille :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 200 (0.101s)

real 0m0.101s
user 0m0.003s
sys 0m0.003s

101ms pour restaurer nginx et servir une page. C’est comparable aux ~92ms de l’article original.

Petite nouveauté : sous v0.6.x, kubectl top pods retournait une erreur pour les pods checkpointés :

# v0.6.x
kubectl top pods
error: Metrics not available for pod default/php-xxx

Ce bug a été corrigé dans la v0.9.0. Désormais, les pods en SCALED_DOWN retournent 0m 0Mi :

kubectl top pods
NAME CPU(cores) MEMORY(bytes)
nginx 0m 0Mi

C’est plus élégant.

Test des liveness probes

C’était LA limitation majeure de la v0.6.x : zeropod était incompatible avec les probes Kubernetes. Si vous mettiez une liveness probe httpGet sur votre container, la sonde déclenchait le timer de scale-down, et votre container ne passait jamais en SCALED_DOWN. Résultat : probes inutilisables, donc zeropod inutilisable en production.

Ce qui a changé

Deux correctifs ont été apportés entre la v0.6.x et la v0.12.0 :

L’activator (le composant eBPF qui écoute le trafic pendant le SCALED_DOWN) : il intercepte les probes et répond 200 directement, sans réveiller le container. Ça, c’est le comportement “après scale-down”.
Le socket tracker (le composant qui ignore les connexions pendant l’état RUNNING) : depuis la PR #72 (merged août 2025), zeropod est capable de détecter les connexions provenant du kubelet et de ne pas les compter comme du “vrai” trafic. Ça, c’est le comportement “avant scale-down”.

Test grandeur nature

J’ai déployé nginx avec une liveness probe agressive (periodSeconds: 5) et un scaledown-duration: 10s :

spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 livenessProbe:
 httpGet:
 path: /
 port: 80
 periodSeconds: 5

Sur k3s, ce test m’avait donné du fil à retordre : le socket tracker n’arrivait pas à filtrer les connexions des probes, qui resettaient le timer de scale-down en permanence. L’activator par contre (qui filtre les probes une fois le scale down passé) fonctionnait.

Sur kubeadm, le résultat est immédiat :

kubectl get pod -l app=nginx-probe -o json | jq -r '.items[0].metadata.labels["status.zeropod.ctrox.dev/nginx"]'
SCALED_DOWN

Le socket tracker filtre correctement les connexions du kubelet natif. La règle periodSeconds > scaledown-duration que j’avais dû utiliser sur k3s n’est plus nécessaire.

Un mot sur les évolutions entre v0.6.x et v0.12.0

Le tableau des améliorations entre les deux versions :

Point	v0.6.x	v0.12.0
`kubectl top pods` en scaled-down	❌ Erreur	✅ `0m 0Mi` (fix v0.9.0)
Checkpoint (nginx)	~400ms	~185ms (-54%)
Restauration (nginx)	~92ms	~99ms (stable)
CRIU	v3.x	v4.2
Gestion d’échec checkpoint	basique	métriques + events (v0.11.0)
Proxy timeouts configurables	❌	✅ (v0.11.0)
Migration inter-node	basique	améliorée + timeouts (v0.10.0)
Probes	❌ Incompatible	✅ Activator + socket tracker

Note technique intéressante sur les flags CRIU : zeropod a retiré l’option --tcp-established en septembre 2025. Auparavant, les connexions TCP actives étaient sauvegardées et restaurées avec le container. Désormais, zeropod utilise --tcp-skip-in-flight (quand runc >= 1.3 le supporte). Conséquence pratique : si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Il faudra les rétablir après restore.

Déploiement de WordPress (le cas d’usage réaliste :trollface:)

Bon, nginx c’est bien, mais c’est pas très représentatif. Déployons une vraie app avec du PHP, Apache et une base de données.

Reprenons le manifest WordPress de l’article original, sans zeropod sur MySQL :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: wordpress
spec:
 replicas: 1
 selector:
 matchLabels:
 app: wordpress
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 zeropod.ctrox.dev/container-names: wordpress
 zeropod.ctrox.dev/ports-map: wordpress=80
 labels:
 app: wordpress
 spec:
 runtimeClassName: zeropod
 initContainers:
 - name: wait-for-mysql
 image: mysql:8
 command:
 - sh
 - -c
 - |
 until mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "SELECT 1"; do
 echo "Waiting for MySQL..."
 sleep 3
 done
 mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "CREATE DATABASE IF NOT EXISTS wordpress;"
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 containers:
 - image: wordpress:latest
 name: wordpress
 ports:
 - containerPort: 80
 env:
 - name: WORDPRESS_DB_HOST
 value: mysql
 - name: WORDPRESS_DB_USER
 value: root
 - name: WORDPRESS_DB_PASSWORD
 value: verySecurePassword
 - name: WORDPRESS_DB_NAME
 value: wordpress

MySQL (sans zeropod) :

apiVersion: v1
kind: Service
metadata:
 name: mysql
spec:
 ports:
 - port: 3306
 selector:
 app: mysql
 clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 serviceName: mysql
 replicas: 1
 selector:
 matchLabels:
 app: mysql
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - image: mysql:8
 name: mysql
 ports:
 - containerPort: 3306
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 volumeMounts:
 - mountPath: /var/lib/mysql
 name: data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi

Le checkpoint de WordPress (Apache + PHP) :

{"time":"2026-05-29T14:33:35.915988635Z","phase":"SCALED_DOWN","duration":"313.286787ms"}

Les checkpoints mettent autour de 300ms. La restauration est autour de 200 ms :

{"time":"2026-05-29T14:34:31.56806589Z","phase":"RUNNING","duration":"206.33005ms"}

La première requête curl confirme :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.212s)

212ms, c’est environ 2 fois plus rapide que les 454ms de l’article original.

Et maintenant, le test qui tue : cascade WordPress + MySQL

Dans l’article original, j’avais tenté le test ultime : mettre les deux pods (WordPress ET MySQL) avec runtimeClassName: zeropod, puis envoyer une requête HTTP sur WordPress pendant que les deux sont checkpointés.

Le scénario est le suivant :

Au bout de quelques secondes, WordPress est SCALED_DOWN, MySQL est SCALED_DOWN aussi
Un client envoie une requête HTTP à WordPress
L’activator de WordPress intercepte la requête et restore le container WordPress
WordPress (Apache+PHP) démarre, exécute le code PHP qui nécessite une connexion MySQL
WordPress se connecte à MySQL sur le port 3306
L’activator de MySQL intercepte la connexion et restore MySQL
MySQL répond, WordPress génère la page, Apache renvoie la réponse HTTP

Du vrai scale to zero qui scale toute l’app, pas juste le front/back.

Note importante : je sais que vous ne voudrez probablement jamais scaler votre base de données à zéro en production, mais ce test montre que cette approche (eBPF + CRIU) fonctionne au-delà du simple scale-to-zero de serveurs web, ce que d’autres outils sur le marché font déjà très bien.

Sur k3s : pas de chance, sur kubeadm : victoire

Sur k3s, je n’ai pas encore réussi à faire fonctionner ce scénario : WordPress se restaurait mais ne répondait pas sur le port 80. J’ai passé pas mal de temps à essayer de comprendre, sans succès.

Même test, même version de zeropod, mais sur kubeadm :

curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.224s)

224ms. Les deux pods sont passés de SCALED_DOWN à RUNNING, la page WordPress s’affiche. J’ai répété le test 5 fois de suite :

Cycle	Temps (curl)	HTTP
1	229ms	302
2	192ms	302
3	227ms	302
4	230ms	302
5	211ms	302

Les logs zeropod confirment le réveil des deux containers :

WordPress: SCALED_DOWN → RUNNING
MySQL: SCALED_DOWN → RUNNING

Ce qui a vraiment changé depuis v0.6.x

Les probes (enfin !)

C’était mon grief principal dans le premier article. Aujourd’hui, c’est résolu :

Avant : impossible de mettre des probes Kubernetes → zeropod inutilisable dans un usecase un minimum sérieux
Après : l’activator intercepte les probes en SCALED_DOWN (répond 200 sans restore), et le socket tracker filtre les connexions kubelet en RUNNING

La stabilité

Le comportement flaky (perte de pods sous charge simultanée) a disparu. Là où j’avais des échecs sous l’article original, les tests de charge séquentiels et simultanés passent tous.

Les performances

Le checkpoint a gagné ~50% en vitesse (185ms vs 400ms). La restauration aussi (200ms vs 454ms). Merci CRIU v4.2 et les optimisations de zeropod.

kubectl top pods

Ce petit détail faisait tache — kubectl top pods plantait sur les pods checkpointés. Corrigé en v0.9.0.

Mais quelques limitations résiduelles

Je serais malhonnête si je disais que tout est parfait. Voilà ce qui reste problématique :

depuis septembre 2025, zeropod n’utilise plus --tcp-established pour CRIU. Ça veut dire que si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Dans la pratique, pour un serveur web, ça veut dire qu’il faut reconnecter la base de données après restore. Avec zeropod, la connexion MySQL est refaite automatiquement (la requête PHP en cours échoue, la suivante réussit). C’est un détail qui peut avoir son importance selon les cas.
Je n’ai testé que WordPress (Apache + mod_php) et MySQL. Les applications avec des websockets, du streaming, ou des connexions longues pourraient se comporter différemment.
J’ai eu des difficultés à le faire correctement fonctionner sur k3s.
J’ai observé un glitch (segfault Apache) sur le premier restore d’un pod WordPress fraîchement créé. Ce n’est pas reproductible après un cycle checkpoint/restore normal, mais si vous redéployez souvent vos pods, vous pourriez le rencontrer.

Verdict

Un an après, zeropod me parait un peu plus tenir ses promesses :

Même si ce n’était pas rédhibitoire, le performances de checkpoint/restore se sont nettement améliorées (~50% plus rapide), ce qui est toujours bon à prendre
Le support des probes Kubernetes a été ajouté, le blocage principal selon moi est levé
La stabilité générale est meilleure
Le test cascade (WordPress + MySQL) fonctionne

Je reste toujours aussi hypé par l’idée qu’on puisse freezer un container et le restaurer 10 secondes plus tard comme si de rien n’était. La magie de CRIU et d’eBPF combinés commence à se matérialiser, après des années d’attente.

Est-ce que je mettrais ça en production ? Disons que c’est moins risqué qu’il y a un an. Pour rigoler sur mon cluster perso, pourquoi pas. Pour une base de données en prod avec des connexions longues, je pense que je passe toujours mon tour ;-).

Mais franchement, pour le coup, le projet a bien évolué et mérite qu’on s’y attarde.

zeropod : scale-to-zero avec checkpoint du container

Fri, 20 Jun 2025 19:00:00 +0200

Qu’est-ce que zeropod ?

J’ai laissé le paragraphe d’intro de la doc du projet telle quelle parce que je la trouve top. Elle dit tout ce que vous devez savoir sur l’outil, ni trop ni trop peu.

Zeropod is a Kubernetes runtime (more specifically a containerd shim) that automatically checkpoints containers to disk after a certain amount of time of the last TCP connection.

While in scaled down state, it will listen on the same port the application inside the container was listening on and will restore the container on the first incoming connection.

Depending on the memory size of the checkpointed program this happens in tens to a few hundred milliseconds, virtually unnoticable to the user.

As all the memory contents are stored to disk during checkpointing, all state of the application is restored.

It adjusts resource requests in scaled down state in-place if the cluster supports it.

To prevent huge resource usage spikes when draining a node, scaled down pods can be migrated between nodes without needing to start up.

Pour les anglophobes : ça va freezer votre app si elle ne reçoit pas de call TCP, et la restaurer quand un call arrive.

Si vous voulez comprendre plus en détail COMMENT ça marche vraiment, dans ce cas, je vous invite à aller lire la section “How it works” documentation officielle du projet, qui a le mérite d’être assez claire :

https://github.com/ctrox/zeropod?tab=readme-ov-file#how-it-works

Prérequis

On perd pas de temps, on se lance dans l’expérimentation. En prérequis, j’ai eu besoin de :

un serveur Ubuntu avec k3s vanilla (flannel + traefik, un seul node). Si vous ne savez pas comment l’installer, vous pouvez toujours jeter un oeil à mon article à ce sujet.
cert-manager. Pas forcément nécessaire mais j’aime bien avoir des certificats HTTPS valides.

# Install cert-manager CRDs and namespace
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.0/cert-manager.yaml

# Wait for cert-manager to be ready
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=cert-manager -n cert-manager --timeout=60s
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=cainjector -n cert-manager --timeout=60s
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=webhook -n cert-manager --timeout=60s

Configuration du ClusterIssuer :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
 server: https://acme-v02.api.letsencrypt.org/directory
 email: votre.email@example.org
 privateKeySecretRef:
 name: letsencrypt-prod
 solvers:
 - http01:
 ingress:
 class: traefik

Optionnel aussi, pour plus de facilité, j’ai modifié les ports du service traefik en 30080 et 30443 car je n’ai pas de support des Services de type LoadBalancer sur ce cluster :

kubectl get svc -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cert-manager cert-manager ClusterIP 10.43.212.125 <none> 9402/TCP 21h
cert-manager cert-manager-webhook ClusterIP 10.43.134.29 <none> 443/TCP 21h
default kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 21h
kube-system kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 21h
kube-system metrics-server ClusterIP 10.43.83.225 <none> 443/TCP 21h
kube-system traefik LoadBalancer 10.43.208.56 192.168.1.242 80:30080/TCP,443:30443/TCP 21h

Installation de zeropod

Une fois qu’on a notre cluster fonctionnel avec tous les prérequis, on peut installer zeropod. La première étape consiste “juste” à appliquer le manifest kustomize suivant, qui va créer un DaemonSet customisé avec les bons paths pour qu’il puisse se brancher / patcher containerd.

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: zeropod-node
 namespace: zeropod-system
spec:
 template:
 spec:
 volumes:
 - name: containerd-etc
 hostPath:
 path: /var/lib/rancher/k3s/agent/etc/containerd/
 - name: containerd-run
 hostPath:
 path: /run/k3s/containerd/
 - name: zeropod-opt
 hostPath:
 path: /var/lib/rancher/k3s/agent/containerd

kubectl apply -k https://github.com/ctrox/zeropod/config/k3s

Puis on va labéliser le Node et vérifier que le pod controller fonctionne :

kubectl label node zeropod zeropod.ctrox.dev/node=true
kubectl -n zeropod-system wait --for=condition=Ready pod -l app.kubernetes.io/name=zeropod-node

La documentation indique qu’il faut redémarrer le Node dans le cas de k3s car tout est packagé ensemble dans un k3s (probablement pareil pour k0s). C’est probablement pas nécessaire pour la plupart des distributions “normales”.

NAMESPACE NAME READY STATUS RESTARTS AGE
...
zeropod-system zeropod-node-qntzh 1/1 Running 1 (21h ago) 21h

Point intéressant : zeropod va ajouter sa propre runtimeClass (je vous laisse jeter un oeil à la documentation Kubernetes, ça vaut le détour si vous ne connaissez pas) :

kubectl get runtimeclass
NAME HANDLER AGE
crun crun 21h
[...]
zeropod zeropod 21h

Déploiement d’une application WordPress

Quel est le meilleur cas d’usage pour Kubernetes ?

Héberger un blog perso avec Wordpress et de l’autoscaling, bien entendu !! Tout le monde sait ça.

Au delà de la vanne, l’idée était de tester une application stateful, si possible avec une base de données, histoire de voir jusqu’ou on peut pousser l’outil. Car une des limitations des outils scale-to-zero dans kubernetes est justement qu’ils marchent super bien pour des workloads stateless (ou FaaS), mais que c’est plus compliqué quand on a un état.

Première chose à savoir : au delà du label qu’on a mis sur le node, il est nécessaire d’ajouter 2 points de configuration supplémentaires sur nos applications qu’on veut scale to zero.

Les annotations zeropod ; pas trop besoin d’expliquer ce que ça fait : on lui donne le numéro du port, le container et la durée à partir de laquelle, si je n’ai pas de connexion, je scale down :

annotations:
 zeropod.ctrox.dev/ports-map: "wordpress=80"
 zeropod.ctrox.dev/container-names: wordpress
 zeropod.ctrox.dev/scaledown-duration: 10s

La runtimeClass qui doit être définie :

runtimeClassName: zeropod

Manifests de l’application

Voilà à quoi ça pourrait grossièrement ressembler. On peut faire plus propre (charts helm) mais j’ai fait quick and dirty, ça suffit pour ce PoC :

Deployment WordPress :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: php
spec:
 selector:
 matchLabels:
 app: php
 template:
 metadata:
 labels:
 app: php
 annotations:
 zeropod.ctrox.dev/ports-map: "wordpress=80"
 zeropod.ctrox.dev/container-names: wordpress
 zeropod.ctrox.dev/scaledown-duration: 10s
 spec:
 runtimeClassName: zeropod
 initContainers:
 - command:
 - sh
 - -c
 - |
 until mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "SELECT 1"; do
 echo "Waiting for MySQL to be ready..."
 sleep 5
 done
 echo "MySQL is ready!"
 mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "CREATE DATABASE IF NOT EXISTS wordpress;"
 mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'root'@'%';"
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 image: mysql
 imagePullPolicy: IfNotPresent
 name: wait-for-mysql
 containers:
 - env:
 - name: WORDPRESS_DB_HOST
 value: mysql
 - name: WORDPRESS_DB_USER
 value: root
 - name: WORDPRESS_DB_PASSWORD
 value: verySecurePassword
 - name: WORDPRESS_DB_NAME
 value: wordpress
 image: wordpress:latest
 imagePullPolicy: Always
 name: wordpress
 ports:
 - containerPort: 80
 protocol: TCP

StatefulSet MySQL :

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 selector:
 matchLabels:
 app: mysql
 serviceName: "mysql"
 replicas: 1
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - image: mysql
 name: mysql
 ports:
 - containerPort: 3306
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 volumeMounts:
 - name: data
 mountPath: /var/lib/mysql
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 5Gi

Services et Ingress :

apiVersion: v1
kind: Service
metadata:
 name: php
 labels:
 app: php
spec:
 ports:
 - port: 8080
 name: http
 targetPort: 80
 selector:
 app: php
---
apiVersion: v1
kind: Service
metadata:
 name: mysql
 labels:
 app: mysql
spec:
 ports:
 - port: 3306
 name: mysql
 clusterIP: None
 selector:
 app: mysql
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: zeropod-ingress
 namespace: default
 annotations:
 traefik.ingress.kubernetes.io/router.entrypoints: web,websecure
 cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
 rules:
 - host: zeropod.example.org
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: php
 port:
 number: 8080
 tls:
 - hosts:
 - zeropod.example.org
 secretName: zeropod-tls

Observation du comportement

Une fois déployé, on vérifie vite fait l’état des pods et des services :

kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 17h
php-dc7cb9cff-29hzb 1/1 Running 0 17h

kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
[...]
mysql ClusterIP None <none> 3306/TCP 21h
php ClusterIP 10.43.165.131 <none> 8080/TCP 21h

Détection de l’absence de trafic

Peu après avoir déployé Apache PHP, zeropod remarque qu’il n’y a pas eu de connexion depuis un moment et met le container en pause.

Le truc rigolo, c’est que du point de vue Kubernetes, il ne s’est rien passé ! Le pod php-dc7cb9cff-29hzb existe toujours et est présent dans la liste des Non terminated pods du Node :

kubectl get pods php-dc7cb9cff-29hzb
NAME READY STATUS RESTARTS AGE
php-dc7cb9cff-29hzb 1/1 Running 0 17h

kubectl describe nodes
[...]
Non-terminated Pods: (11 in total)
 Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
 --------- ---- ------------ ---------- --------------- ------------- ---
[...]
 default mysql-0 0 (0%) 0 (0%) 0 (0%) 0 (0%) 17h
 default php-dc7cb9cff-29hzb 0 (0%) 0 (0%) 0 (0%) 0 (0%) 17h
[...]

Il n’apparait en revanche plus dans les métriques “top pods” collectés par metrics-server :

kubectl top pods
NAME CPU(cores) MEMORY(bytes)
mysql-0 4m 460Mi

Et si on cherche le processus apache2 sur le node, on ne le retrouvera pas :

sudo ps -ef | grep apache2

Sous le capot, les logs de zeropod

Dans les logs de zeropod, on remarque d’abord la détection d’un container éligible au scale to zero :

{"time":"2025-06-20T17:31:46.222502407Z","level":"INFO","msg":"subscribing to status events","sock":"/run/zeropod/s/5858a327ae5a70c2e12b5dad1e8320a4670ff11152476ad49605ebca5327f7d6.sock"}
{"time":"2025-06-20T17:31:47.572065537Z","level":"INFO","msg":"status event","component":"podlabeller","container":"wordpress","pod":"php-dc7cb9cff-29hzb","namespace":"default","phase":1}
{"time":"2025-06-20T17:31:47.5737556Z","level":"INFO","msg":"attaching redirector for sandbox","pid":64980,"links":["eth0","lo"]}

Et au bout de 10 secondes, comme il n’y a pas eu de connexion, zeropod l’éteint (“phase”:0) :

{"time":"2025-06-20T17:31:57.932464147Z","level":"INFO","msg":"status event","component":"podlabeller","container":"wordpress","pod":"php-dc7cb9cff-29hzb","namespace":"default","phase":0}

Tests de performance

Quand le processus est checkpointé, on va voir que le curl met quand même un peu de temps à être servi. Rien de dramatique, mais quand même :

time curl https://zeropod.example.org:30443 -I
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Fri, 20 Jun 2025 17:41:29 GMT
link: <https://zeropod.example.org:30443/wp-json/>; rel="https://api.w.org/"
server: Apache/2.4.62 (Debian)
x-powered-by: PHP/8.2.28

real 0m0.454s
user 0m0.052s
sys 0m0.010s

En revanche, pour toutes les connexions suivantes, les temps sont corrects pour un Wordpress vide (et pas optimisé) :

time curl https://zeropod.example.org:30443 -I
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Fri, 20 Jun 2025 17:41:42 GMT
link: <https://zeropod.example.org:30443/wp-json/>; rel="https://api.w.org/"
server: Apache/2.4.62 (Debian)
x-powered-by: PHP/8.2.28

real 0m0.088s
user 0m0.053s
sys 0m0.008s

Donc, ça fonctionne !

La première connexion prend bien un peu plus de temps, pendant que le programme eBPF qui “écoute” le trafic pendant que le container est down ne le rallume et rende la main (ici +350-400ms sur une petite VM pas chère et assez chargée).

Une fois le conteneur restauré, on peut d’ailleur voir (ré)apparaitre les processus apache2 avec un ps sur le Node :

ps -ef |grep apache2
root 67038 64955 1 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67055 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67056 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67057 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67058 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67059 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND
www-data 67060 67038 0 18:56 ? 00:00:00 apache2 -DFOREGROUND

Aller plus loin : test avec MySQL

Bon, par contre, scaler à 0 un serveur http, c’est rigolo, mais c’est pas révolutionnaire. Il existe déjà sur le marché des solutions de scale to zero dans Kubernetes, surtout pour tout ce qui est FaaS ou stateless. Mais si on pousse l’expérience jusqu’au bout ?

On a rarement envie de scaler à 0 une base de données dans la vraie vie. L’arrêter puis la redémarrer, ça peut prendre du temps, et potentiellement ça va faire des erreurs dans nos apps si le scaling est mal fait.

Cependant, avec zeropod, le principe est un peu différent, puisqu’on ne va pas vraiment arrêter le processus, juste le freeze.

Pour la science (ne faites pas ça en prod), j’ai donc ajouté zeropod sur la bdd MySQL aussi !

Comme pour wordpress, on met les annotations et la runtimeClass :

template:
 metadata:
 labels:
 app: mysql
 annotations:
 zeropod.ctrox.dev/ports-map: "mysql=3306"
 zeropod.ctrox.dev/container-names: mysql
 zeropod.ctrox.dev/scaledown-duration: 10s
 spec:
 runtimeClassName: zeropod
 containers:
 # ...

Au bout de quelques secondes, zeropod passe la base de données mysql à la phase “0” :

{"time":"2025-06-20T18:06:14.92372877Z","level":"INFO","msg":"status event","component":"podlabeller","container":"mysql","pod":"mysql-0","namespace":"default","phase":1}
{"time":"2025-06-20T18:06:14.925316023Z","level":"INFO","msg":"attaching redirector for sandbox","pid":69570,"links":["eth0","lo"]}
{"time":"2025-06-20T18:06:25.766097339Z","level":"INFO","msg":"status event","component":"podlabeller","container":"mysql","pod":"mysql-0","namespace":"default","phase":0}

kubectl top pods ne remonte plus aucun pod (et une erreur…) :

kubectl top pods
error: Metrics not available for pod default/php-dc7cb9cff-29hzb, age: 35m59.026573861s

Mais les pods restent bien visibles et “Running” du point de vue de Kubernetes :

kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 2m30s
php-dc7cb9cff-29hzb 1/1 Running 0 36m

Test final : réveil en cascade

Le test final : est-ce qu’un call HTTP sur php va le réveiller, ce qui va déclencher une connexion à la base de données mysql qui va à son tour la réveiller aussi ?

Roulement de tambours

time curl https://zeropod.example.org:30443 -I
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Fri, 20 Jun 2025 18:09:24 GMT
link: <https://zeropod.example.org:30443/wp-json/>; rel="https://api.w.org/"
server: Apache/2.4.62 (Debian)
x-powered-by: PHP/8.2.28

real 0m0.978s
user 0m0.053s
sys 0m0.008s

Victoire !!

Limitations

Au delà de cet exemple un peu nouille (qui n’a jamais voulu héberger un wordpress sur Kubernetes avec du scaling to zero ?), on se rend compte que la techno “marche” mais reste un peu flacky.

J’ai eu plusieurs cas dans lequel le scaling to zero se faisait sur le pod php, alors que j’étais en train de faire une boucle avec un “while true; do curl” (peut être lié à la chaine ingress -> service -> pod ?). Et le temps de checkpointing est quand même visible sur ma VM de test (400 ms par container, c’est pas rien).

Un point qui n’est pas abordé dans la doc du projet est qu’il est quasiment impossible de mettre des liveness / readiness correctes quand vous utilisez zeropod.

Si vous mettez une liveness sur un service web, vous allez trigger un call sur le port TCP écouté par zeropod, et donc redémarrer l’app qui ne sera jamais checkpointée. Si vous mettez une readiness, même combat.

Et si vous comptez vous en sortir avec un liveness / readiness qui ne trigger pas un call HTTP sur le port surveillé par zeropod, vous allez vous retrouver avec une app vue par Kubernetes comme (respectivement) KO ou “Not ready”, puisque le container ne sera pas disponible car checkpointé.

une issue ouverte sur le sujet - github.com/ctrox/zeropod/issues/34

Techniquement, zeropod, c’est très rigolo et assez malin, je suis assez admiratif.

Mais je ne vois pas trop dans quel monde on souhaiterait avoir des containers en prod sans liveness / readiness, donc je suis assez sceptique sur l’usage de cette techno en l’état, à part pour des exemples très peu critiques. Cette limitation me semble trop grande.