Kubernetes (10/12) — Probes : readiness & liveness

L’idée reçue

« Si le Pod est Running, l’appli va bien et peut recevoir du trafic. »

Faux, et tu l’as déjà vu en Docker (Phase 3) : un processus vivant peut renvoyer des 500, ou être bloqué. Sans probes, Kubernetes croit qu’un conteneur en marche est sain. Avec elles, il route le trafic seulement vers ce qui est prêt, et redémarre ce qui est cassé.

À la fin de ce module, tu sauras…

Distinguer readiness (trafic) et liveness (auto-réparation)
Ajouter une readiness probe et observer l’exclusion du trafic
Ajouter une liveness probe et observer un redémarrage automatique
Relier tout ça au healthcheck Docker de la Phase 3

01Pourquoi les probes comptent

Expérience 1

Confirmer qu’il n’y en a pas encore

Manipule

kubectl get deploy demo-deploy -o yaml | grep -i probe

Aucune sortie : pas de probe définie. Kubernetes considère donc tes Pods « sains » du moment que le processus tourne — même s’ils renvoyaient des erreurs.

Comprends trois rôles distincts

La readiness contrôle le routage du trafic (un Pod NotReady est retiré du Service). La liveness contrôle l’auto-réparation (un Pod qui échoue est redémarré). La startupProbe évite les redémarrages prématurés au démarrage lent. On se concentre sur les deux premières, les plus utilisées.

02Ajouter une readiness probe

Expérience 2

Contrôler qui reçoit du trafic

Manipule

kubectl patch deploy demo-deploy --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/readinessProbe","value":{
 "httpGet":{"path":"/","port":80},
 "initialDelaySeconds":2,
 "periodSeconds":3,
 "timeoutSeconds":1,
 "failureThreshold":1
}}
]'

Manipule

kubectl get pods -l app=demo-deploy
kubectl get endpointslice -l kubernetes.io/service-name=demo-service

Observe

NAME                          READY   STATUS
demo-deploy-5f9448fbd-9dgkp   0/1     Running   # nouveau, pas encore prêt
demo-deploy-8547ffbb59-dcpk4  1/1     Running   # ancien, toujours prêt

Pendant le rollout, les nouveaux Pods sont Running mais 0/1 (NotReady) tant que la probe n’a pas réussi. Kubernetes garde les anciens Pods Ready pour éviter toute coupure : c’est readiness + RollingUpdate en action.

Comprends NotReady = hors trafic

Un Pod 0/1 est vivant mais exclu des endpoints du Service : il ne reçoit aucun trafic tant qu’il n’est pas Ready. C’est ce qui garantit qu’un utilisateur ne tombe jamais sur un Pod pas encore prêt. failureThreshold: 1 rend la bascule rapide.

03Prouver l’exclusion du trafic

Expérience 3

Casser la readiness, voir le Pod sortir des endpoints

Fais échouer volontairement la probe (pointe-la sur un chemin inexistant), puis regarde les endpoints :

Manipule

kubectl get pods -l app=demo-deploy -o wide
kubectl get endpointslice -l kubernetes.io/service-name=demo-service -o yaml | grep -A3 addresses

Les Pods NotReady disparaissent de la liste des adresses éligibles au trafic. Les Pods Ready y restent. Le Service ne route que vers ce qui est réellement prêt.

Comprends EndpointSlice = éligibles au trafic

Un EndpointSlice représente les Pods « éligibles au trafic ». La readiness pilote directement cette liste : NotReady → retiré ; Ready → présent. C’est le mécanisme fin qui relie santé applicative et routage.

04Ajouter une liveness probe

Expérience 4

Déclencher l’auto-réparation

Manipule

kubectl patch deploy demo-deploy --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/livenessProbe","value":{
 "httpGet":{"path":"/","port":80},
 "initialDelaySeconds":5,
 "periodSeconds":5,
 "timeoutSeconds":1,
 "failureThreshold":1
}}
]'

Provoque un échec (par ex. pointe la liveness sur un chemin inexistant), puis observe la colonne RESTARTS :

Manipule

kubectl get pods -l app=demo-deploy -w

Observe

NAME                          READY   STATUS    RESTARTS   AGE
demo-deploy-xxxxx             1/1     Running   1 (5s ago) 40s   # redémarré !

Quand la liveness échoue, le kubelet redémarre le conteneur — la colonne RESTARTS s’incrémente. Ce n’est pas une question de trafic, mais de récupération du processus.

Comprends readiness vs liveness, la distinction nette

Readiness : « es-tu prêt à recevoir du trafic ? » → si non, on te retire du Service (mais on ne te tue pas). Liveness : « es-tu encore fonctionnel ? » → si non, on te redémarre. Deux questions différentes, deux réactions différentes. Confondre les deux est une erreur classique.

→Le pont avec Docker (Phase 3)

Continuité Le HEALTHCHECK que tu as écrit dans ton Dockerfile (module 3.9) était l’ancêtre de tout ceci. Kubernetes le transforme en deux outils distincts et bien plus puissants : la readiness (gérer le trafic) et la liveness (réparer). Tu avais posé la brique ; la plateforme l’exploite maintenant à l’échelle.

✓Ce que tu retiens

« Running » ≠ « prêt » ≠ « sain ». La readiness pilote le routage du trafic (Pod NotReady retiré du Service, sans coupure grâce au RollingUpdate) ; la liveness pilote l’auto-réparation (redémarrage d’un conteneur cassé). C’est l’évolution directe du healthcheck Docker, en version orchestrée.

Mini-projet

Santé & trafic sous contrôle

À faire

Confirme l’absence de probes, puis ajoute une readiness probe HTTP.
Observe des Pods NotReady exclus des endpoints, sans coupure de service.
Ajoute une liveness probe et provoque un échec.
Prouve le redémarrage via la colonne RESTARTS et les Events (describe pod).
Restaure des probes saines pour revenir à un cluster stable.
Documente dans BookStack : readiness (trafic) vs liveness (réparation), lien avec le HEALTHCHECK Docker.

Fil rouge — Tes Pods sont sains et bien routés. Mais rien ne les empêche de consommer tout le CPU/RAM d’un node, ni ne garantit qu’ils auront de quoi tourner. Au module suivant : requests, limits & QoS.

?Auto-évaluation

1. Quelle est la différence entre readiness et liveness ?

Readiness contrôle si le Pod reçoit du trafic (sinon retiré du Service) ; liveness contrôle si le conteneur doit être redémarré (auto-réparation).

2. Que devient un Pod NotReady vis-à-vis du Service ?

Il est retiré des endpoints (EndpointSlice) : il ne reçoit plus de trafic, mais n’est pas tué.

3. Quel signal montre qu’une liveness probe a agi ?

La colonne RESTARTS qui s’incrémente, et les Events du Pod (describe pod) indiquant l’échec de la probe.