La base PostgreSQL peine : latence multipliée par dix. Les pods de l'interface de programmation répondent en huit secondes au lieu de deux cents millisecondes. La sonde de liveness HTTP expire à trois secondes. Kubernetes redémarre les pods — perte de connexions, cache froid, nouvelle tempête sur la base. L'incident devient une cascade alors que l'application aurait pu se contenter d'être retirée temporairement du répartiteur de charge.
Les sondes sont le thermomètre que le kubelet utilise pour décider : envoyer du trafic, attendre, ou tuer. Mal réglées, elles convertissent une dégradation en catastrophe. Le scénario est fréquent parce que les tutoriels copient une sonde unique /health pour tous les rôles — et parce que liveness est configurée avant que l'équipe comprenne la différence avec readiness.
La bonne nouvelle : une sonde bien calibrée coûte une demi-journée de travail. La mauvaise : une sonde agressive peut coûter des heures de crashloop et amplifier une panne base de données qui aurait pu se résorber seule.
Liveness, readiness, startup : trois signaux distincts
| Sonde | Effet | Question |
|---|---|---|
| Readiness | Retire du Service | « Puis-je recevoir du trafic maintenant ? » |
| Liveness | Redémarre le pod | « Le processus est-il mort sans récupération ? » |
| Startup | Bloque les autres au démarrage | « L'application a-t-elle fini de démarrer ? » |
Erreur classique : une seule URL /health pour les trois rôles. Sous charge, readiness échoue et liveness tue — double peine. Readiness doit retirer le pod du trafic quand une dépendance est lente ; liveness ne doit intervenir que si le processus est réellement bloqué, pas simplement lent.
Redémarrer un pod lent n'accélère pas une base saturée — ça rajoute du chaos.
Pour un déploiement sans liveness au départ, readiness plus alertes Prometheus suffit souvent. Ajoutez liveness quand vous distinguez clairement « lent mais vivant » de « mort sans récupération ».
Calibrer timeouts, période et seuil d'échec
Trois paramètres déterminent l'agressivité :
- timeoutSeconds doit dépasser le percentile 99 sous charge normale — pas sous charge idéale en laboratoire.
- periodSeconds fixe la fréquence des contrôles ; trop agressif multiplie la charge en incident.
- failureThreshold × période = délai avant action ; trois échecs toutes les dix secondes laissent trente secondes avant redémarrage.
Exemple : si votre interface répond en 400 ms au percentile 99 en charge normale, un timeout de trois secondes laisse une marge confortable. Si la base ralentit et le percentile 99 monte à six secondes, readiness échoue — mais liveness ne doit pas tuer tant que le processus répond encore.
Endpoints health : séparer live et ready
Séparez les contrôles dans votre application :
- /health/live : le processus répond — pas d'appel base lourd.
- /health/ready : base joignable, cache chaud, migrations terminées.
Ne mettez pas un appel base coûteux dans liveness. Si PostgreSQL est indisponible, tous les pods ne doivent pas entrer en crashloop — readiness suffit pour les retirer du Service pendant la panne.
Configurez une startupProbe avec trente échecs toutes les dix secondes si le boot dépasse trente secondes : cela laisse cinq minutes de démarrage sans liveness intempestive. Indispensable pour les applications Java, les migrations au démarrage, ou le chargement d'un cache volumineux.
Probes et Kubernetes managé européen
Sur Kubernetes managé OVHcloud, Scaleway Kapsule ou autres offres européennes, le plan de contrôle gère les sondes côté kubelet — votre responsabilité reste le contenu du contrôle et sa charge.
Points de vigilance :
- Conteneurs latéraux qui ajoutent de la latence au démarrage ;
- Limites processeur basses provoquant des timeouts sous charge ;
- Confusion entre contrôle du répartiteur de charge externe et sonde pod — deux mécanismes distincts.
Comparez les offres Kubernetes via l'annuaire et le comparateur. Si vous déployez sur un petit cluster, voir aussi Kubernetes : en avez-vous vraiment besoin ? avant d'ajouter la complexité des sondes à une stack surdimensionnée.
Observabilité : corréler redémarrages et sondes
Métriques utiles en incident :
- Compteur de redémarrages par déploiement ;
- Événements
Unhealthydanskubectl describe pod; - Journaux kubelet au moment du redémarrage.
Runbook recommandé : si crashloop — désactivez temporairement liveness après confirmation que le processus n'est pas zombie ; corrigez la cause racine (base lente, pool épuisé) ; réactivez avec seuils assouplis. Ne jamais désactiver liveness en production sans alerte parallèle sur la disponibilité.
Corréler redémarrages et latence base en production révèle souvent une sonde trop agressive — pas un bug applicatif. Voir métriques Prometheus pour instrumenter le percentile 99 avant de fixer les timeouts.
Le sommet : le redémarrage comme réflexe paresseux
Une sonde utile retire le trafic. Une sonde paresseuse redémarre et espère que le problème disparaîtra. La différence se joue dans la séparation live/ready, les timeouts calibrés sur des mesures réelles, et la discipline de ne pas copier une configuration trouvée sur un forum sans l'adapter à votre charge.
Décider et avancer sans angle mort
Sur une demi-journée, vous pouvez remettre les sondes au service de la stabilité :
- Implémentez des endpoints live et ready séparés — live sans appel base, ready avec les dépendances critiques.
- Configurez une startupProbe si le boot dépasse trente secondes ; sans elle, liveness tuera l'application avant la fin du démarrage.
- Fixez les timeouts à partir du percentile 99 mesuré en charge normale — pas d'une valeur par défaut de tutoriel.
- Testez en préproduction avec saturation base simulée : les pods doivent passer NotReady, pas CrashLoopBackOff.
- Corrélez redémarrages et latence base en production ; ajustez failureThreshold avant d'ajouter des replicas.
- Comparez les offres Kubernetes via l'annuaire si vous migrez vers un cluster managé européen.
Questions fréquentes
Quelle différence entre liveness et readiness ?
Readiness retire le pod du Service sans le tuer — adapté quand une dépendance est temporairement indisponible. Liveness redémarre le conteneur ; réservez-la aux blocages irrécupérables. Confondre les deux provoque des redémarrages inutiles pendant une dégradation passagère.
Pourquoi ma liveness provoque un crashloop ?
Timeouts trop courts, endpoint lent sous charge, ou contrôle passant par la même base saturée. Le kubelet tue le pod alors que readiness suffirait. Assouplissez les seuils ou déplacez le contrôle base vers readiness uniquement.
À quoi sert startupProbe ?
Elle retarde liveness et readiness pendant le boot long — migrations, cache, connexions distantes. Sans elle, liveness tue l'application avant la fin du démarrage. Configurez-la dès qu'un pod met plus de trente secondes à devenir opérationnel.
HTTP ou exec pour une probe ?
HTTP sur un endpoint applicatif léger est préférable. Exec ou socket TCP vérifient peu la santé métier ; réservez-les au dernier recours quand HTTP n'est pas disponible.
Une sonde utile retire le trafic — une sonde paresseuse redémarre et espère que le problème disparaîtra.