Technologie / Analyses et perspectives pratiques

Pas prêt ou bloqué ? Un healthcheck ne peut pas décider de tout

Distinguer disponibilité pour le trafic et vivacité du programme évite qu’une panne temporaire de dépendance déclenche des redémarrages répétés.

ADArdeshir Daryani·2 novembre 2026·2 min de lecture

Illustration de coordination de conteneurs et de choix d’exploitation — Illustration conceptuelle originale générée par IA ; elle ne représente pas fidèlement un produit commercial ou une architecture réelle.

Source technique : documentation officielle des probes Kubernetes. Proposition indépendante, pas configuration prête à copier.

« Peut-il accepter du trafic ? » diffère de « est-il bloqué au point de redémarrer ? ». Mélanger ces décisions peut agrandir un incident bref.

Séparer les rôles

Readiness concerne l’admission du trafic.
Liveness détecte les états auxquels la politique peut répondre par un redémarrage.
Startup concerne le temps d’initialisation.

Ne transposez pas ces noms aveuglément. Le statut unhealthy d’un autre outil n’entraîne pas forcément la même action ; consultez sa politique.

Exemple hypothétique

Une base disparaît brièvement. Si toute connexion ratée fait échouer liveness, des applications saines peuvent redémarrer en boucle. Perdre leur état réchauffé peut aggraver le problème.

Je propose d’exclure les dépendances inutiles de la décision dure de vivacité. La readiness doit refléter le besoin du service, pas seulement un port ouvert.

Avant activation

Testez démarrage lent, surcharge et coupure transitoire en environnement d’essai. Mesurez le coût du contrôle. Documentez réussite, attente et responsable d’alerte.

À lire : la santé au-delà du ping.

Source vérifiée le 2 novembre 2026. Exemple hypothétique, sans seuil universel ni redémarrage recommandé partout.

Des analyses technologiques pour éclairer les décisions.Toutes les publications →