Kubernetes probes
| Fiche express | |
|---|---|
| Types de sondes | liveness · readiness · startup |
| Mécanismes de check | HTTP GET · commande exec · TCP socket |
| Voir aussi | Kubernetes scheduling · Kubernetes daemonSets |
Les probes (sondes) permettent au cluster Kubernetes de déterminer l'état réel d'un conteneur, au-delà du simple fait que son processus tourne. Trois types de sondes répondent chacune à une question différente, et une politique de redémarrage (restart policy) définit ce qui se passe quand un conteneur se termine.
Les trois types de sondes
livenessProbe
Vérifie que le conteneur est en vie. Si elle échoue, Kubernetes considère le conteneur bloqué et le redémarre (selon la restart policy).
apiVersion: v1
kind: Pod
metadata:
name: liveness-pod
spec:
containers:
- name: app
image: nginx
livenessProbe:
exec:
command: ["cat", "/tmp/healthy"]
initialDelaySeconds: 5
periodSeconds: 10
kubectl create -f liveness-pod.yml
kubectl get pod liveness-pod
Variante en HTTP, courante pour les applications web exposant un endpoint de santé :
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
startupProbe
Sonde active uniquement au démarrage du conteneur, désactivée une fois qu'elle a réussi une première fois. Spécialisée pour les applications dont le démarrage est lent : tant qu'elle n'a pas réussi, les sondes liveness et readiness sont suspendues, ce qui évite qu'une application lente à démarrer soit tuée prématurément par sa propre livenessProbe.
kubectl create -f startup-pod.yml
kubectl get pod startup-pod
readinessProbe
Vérifie que le conteneur est prêt à recevoir du trafic. Contrairement à la livenessProbe, un échec de readinessProbe ne redémarre pas le conteneur : il retire simplement le Pod des endpoints du Service associé, le temps que la condition redevienne vraie.
kubectl create -f readiness-pod.yml
kubectl get pod readiness-pod
Résumé des trois sondes
| Sonde | Question posée | Échec → conséquence |
|---|---|---|
| livenessProbe | Le conteneur est-il vivant ? | Redémarrage du conteneur |
| readinessProbe | Le conteneur peut-il recevoir du trafic ? | Retrait des endpoints du Service, pas de redémarrage |
| startupProbe | Le conteneur a-t-il fini de démarrer ? | Les autres sondes restent suspendues tant qu'elle n'a pas réussi |
Politiques de redémarrage (restart policy)
La restartPolicy d'un Pod détermine le comportement de Kubernetes quand un conteneur se termine (échec de sonde ou fin de process) :
- Always — redémarre systématiquement le conteneur, quel que soit le code de sortie. Politique par défaut, adaptée aux services de longue durée.
kubectl create -f always-pod.yml
kubectl get pod always-pod
- OnFailure — redémarre uniquement si le conteneur se termine en erreur (code de sortie non nul).
kubectl create -f onfailure-pod.yml
kubectl get pod onfailure-pod
- Never — ne redémarre jamais le conteneur, quelle que soit l'issue. Adapté aux tâches ponctuelles (Jobs) dont on veut observer l'échec sans relance automatique.
kubectl create -f never-pod.yml
kubectl get pod never-pod