Mesuré le 2026-09-07, quelques heures après le premier déploiement : 30 échecs
de la sonde de disponibilité en 25 minutes, tous en `context deadline
exceeded` — pendant que Loki tournait parfaitement. Il finissait de rejouer
son WAL (`checkpoint done time=4m23s`). Le défaut amont est
`timeoutSeconds: 1`, raisonnable sur une machine rapide et intenable ici.
La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint
derrière le service, donc la source de données Grafana inutilisable — un
magasin de journaux vivant mais injoignable.
Le remède n'assouplit PAS la disponibilité. Il sépare deux questions que le
défaut amont confondait : « Loki a-t-il fini de DÉMARRER ? » (`startupProbe`,
jusqu'à 10 min, c'est le rejeu du WAL qu'on attend) et « répond-il MAL ? »
(`readinessProbe`, stricte, qui ne prend le relais qu'ensuite).
⚠ `initialDelaySeconds: 0` est ÉCRIT, pas omis : le chart FUSIONNE cette table
avec la sienne au lieu de la remplacer. Un premier jet l'omettait, et
`helm template` rendait encore le `15` amont. Le rendu l'a dit, pas moi.
Éprouvé par rendu local, `helm template`, les deux côtés :
livré startup={failureThreshold 60, timeout 5s}
readiness={timeout 5s, initialDelay 0} ← conforme
startupProbe ôté startup=(aucune) ← le sabotage mord
⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un
« False » trompeur (elle cherchait le mot dans un bloc de commentaires qui le
contient). C'est le RENDU qui fait foi, pas ma sonde.
⚠ Ce que ça ne prouve pas : le comportement sous charge réelle. Il faudra
constater que le pod passe `Ready` du premier coup au prochain redémarrage.
Traite un des trois restes de #44.
Co-Authored-By: Claude Opus 5 <[email protected]>
arcodangeandClaude Opus 5