Quand la sonde de vivacité ment : anatomie d’une panne invisible
Retour sur un incident où un pod restait sain aux yeux de Kubernetes alors que son application était hors service depuis vingt minutes.
3 min de lecture
Le pod était Running, 1/1, sans aucun redémarrage. Le tableau de bord était
vert. Le volume était monté, la réplication saine, l’espace disque occupé à un
pour cent.
L’application, elle, ne répondait plus depuis vingt minutes.
Le symptôme
Toutes les requêtes applicatives échouaient sur une erreur de base de données corrompue. La lecture directe du fichier de base renvoyait une erreur d’entrée/sortie, alors que le contrôleur de stockage déclarait le volume en parfaite santé.
Kubernetes, de son côté, n’avait rien à signaler. Et pour cause.
La cause
La sonde de vivacité interrogeait un point d’entrée qui répondait
systématiquement 200 OK. Elle vérifiait que le processus était vivant. Elle ne
vérifiait rien d’autre.
Or le processus était vivant. Il était simplement incapable de faire son travail.
La chronologie a montré une interruption d’entrées/sorties du stockage pendant une écriture. La réplique fautive a été retirée puis reconstruite en moins d’une minute, et le stockage est redevenu sain — mais le fichier écrit pendant la coupure, lui, était définitivement incohérent.
La leçon
Une sonde qui teste la présence du processus ne teste pas la santé du service. Ce sont deux questions différentes, et Kubernetes en pose deux, précisément pour cette raison.
La sonde de disponibilité répond à « ce pod peut-il servir du trafic ? ». Elle doit vérifier les dépendances réelles : accès à la base, cache joignable, fichier de configuration lisible. Si elle échoue, le pod sort du service, sans être détruit.
La sonde de vivacité répond à « ce pod est-il irrécupérable ? ». Elle doit rester légère et locale. Si elle échoue, le pod est tué.
Le piège inverse
La correction évidente — faire porter la vivacité sur la vérification complète — est un piège que j’ai vu se refermer sur un autre service.
Une dépendance externe lente rendait la vérification plus longue que le délai de la sonde. Kubernetes tuait donc le pod, dont le redémarrage à froid prenait plusieurs minutes, pendant lesquelles il était réellement indisponible. La sonde censée protéger le service en était devenue la cause de panne.
Une dépendance dégradée doit retirer le pod du service, pas provoquer sa destruction.
Ce que j’ai changé
Le point d’entrée de disponibilité effectue désormais une requête réelle sur la base et échoue si elle ne répond pas. Le point d’entrée de vivacité se contente de confirmer que la boucle de traitement n’est pas bloquée.
Une alerte se déclenche par ailleurs sur l’absence d’écriture applicative pendant une durée anormale — le signal qui aurait détecté cet incident en trois minutes au lieu de vingt.
La vraie conclusion
Le stockage n’avait ni sauvegarde, ni instantané exploitable. La réplication protège contre la perte d’un disque ; elle ne protège pas contre l’écriture fidèlement répliquée d’un fichier corrompu.
Une réplication n’est pas une sauvegarde. C’est évident écrit ainsi, et beaucoup moins évident devant un tableau de bord entièrement vert.