Que sont les liveness, readiness et startup probes, et quand utilise-t-on chacune ?

Question

IT Interview Practice · Accepted Answer

Les probes permettent au kubelet de vérifier la santé d'un conteneur et d'agir en conséquence. Il y en a trois : **liveness** (est-il vivant, ou faut-il le redémarrer ?), **readiness** (est-il prêt à recevoir du trafic ?) et **startup** (a-t-il fini de démarrer ?). Chacune répond à une question différente.

## Les trois probes en un coup d'œil

```text
LIVENESS   → « L'application est-elle bloquée/deadlockée ? »   ÉCHEC → le kubelet REDÉMARRE le conteneur
READINESS  → « Peut-il servir du trafic maintenant ? »          ÉCHEC → le Pod est retiré des endpoints du Service
                                                                        (PAS redémarré)
STARTUP    → « Le démarrage lent est-il terminé ? »             s'exécute EN PREMIER ; pendant qu'elle tourne, liveness &
                                                                readiness sont mises en attente
```

## Readiness vs liveness — la distinction clé

```text
Readiness contrôle le TRAFIC :
  → un Pod qui échoue à la readiness est RETIRÉ du load-balancer du Service,
    mais continue de tourner (ex. il réchauffe un cache ou une dépendance est indisponible)
Liveness contrôle la VIE :
  → un Pod qui échoue à la liveness est TUÉ et redémarré (il est cassé au-delà de toute récupération)
Utiliser la liveness là où vous vouliez la readiness provoque des boucles de redémarrage inutiles.
```

## Définitions des probes

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # laisse le temps à un démarrage lent avant que les autres n'entrent en jeu
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = jusqu'à 5 min pour démarrer
        periodSeconds: 10

readinessProbe:          # filtre le trafic
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # redémarre si non sain
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mécanismes des probes

```text
httpGet    → GET sur un path ; 2xx/3xx = OK       (le plus courant pour les apps web)
tcpSocket  → peut-on ouvrir une connexion TCP ?    (pour les services non-HTTP)
exec       → exécute une commande ; exit 0 = OK    (vérifications personnalisées)
grpc       → health check gRPC natif
Réglages clés : initialDelaySeconds, periodSeconds, timeoutSeconds,
               failureThreshold, successThreshold.
```

## Pourquoi les startup probes existent

```text
Les apps à démarrage lent (warmup JVM, grosses migrations) obligeaient jadis à mettre un énorme
initialDelaySeconds sur la liveness — ce qui rendait ensuite les vrais crashs lents à détecter.
La startupProbe corrige cela : elle protège le démarrage lent, et SEULEMENT une fois qu'elle passe
la liveness/readiness commencent avec leurs timings normaux (serrés).
```

```bash
kubectl describe pod app     # voir les échecs de probe et les raisons de redémarrage dans les événements
kubectl get pod app          # la colonne READY reflète la readiness ; RESTARTS reflète la liveness
```

## Pourquoi c'est important

Les health probes sont la façon dont Kubernetes assure l'auto-réparation et un routage du trafic sûr, donc comprendre les trois types et quand utiliser chacun est une connaissance essentielle de fiabilité. La distinction cruciale — celle qui piège beaucoup d'ingénieurs — est entre la **readiness** et la **liveness** : la readiness contrôle le **trafic** (un Pod en échec est retiré du load-balancer du Service mais continue de tourner, idéal quand il chauffe ou qu'une dépendance est temporairement indisponible), tandis que la liveness contrôle la **vie** (un Pod en échec est tué et redémarré, pour quand il est deadlocké au-delà de toute récupération). Confondre les deux — utiliser une liveness probe là où la readiness était voulue — provoque des boucles de redémarrage inutiles et des pannes, donc savoir à quelle question répond chaque probe est directement pratique. La **startup** probe résout une vraie douleur historique : les apps à démarrage lent forçaient jadis d'énormes `initialDelaySeconds` sur la liveness (ce qui retardait la détection de véritables crashs), alors qu'une startup probe protège la fenêtre de démarrage et laisse la liveness/readiness tourner avec des timings serrés et normaux uniquement une fois le démarrage réussi. Comprendre les mécanismes des probes (`httpGet`, `tcpSocket`, `exec`, `grpc`) et les réglages (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, etc.) vous permet de configurer le health checking correctement plutôt qu'au jugé. Puisque les probes déterminent directement si les utilisateurs atteignent des Pods sains et si les Pods cassés récupèrent automatiquement, bien les régler est fondamental pour faire tourner des workloads fiables et de qualité production sur Kubernetes.

Les trois probes en un coup d'œil

Readiness vs liveness — la distinction clé

Définitions des probes

Mécanismes des probes

Pourquoi les startup probes existent

Pourquoi c'est important

Questions connexes