DevOps · post-mortem
9h. Tout est vert. Qui a crashé cette nuit?
L'astreinte prépare le post-mortem.
kubectl ne montre que le présent.
Cluster kind de démonstration
Le problème
Kubernetes efface ses events au bout d'une heure.
- Un pod réparé est un nouveau pod: 0 redémarrage.
- Ses events Warning expirent.
- La question du post-mortem n'a plus de réponse dans le cluster.
Le lab
Deux déploiements crashent en boucle.
- payment-api est réparé.
- billing-api crashe encore.
- Le cluster oublie ses events en 3 minutes au lieu d'une heure.
Ce qu'il a fallu écrire
unique_key: $.metadata.uid
cells["workload_key"] =
"$namespace/$deployment"Une clé par event, une par déploiement.
Le hub garde chaque event lu. Le scénario: 3 fichiers, 69 lignes.
Après l'oubli
kubectl: No resources found.
- payment-api: Running, 0 redémarrage.
- Le deuxième run ne lit plus qu'un event sur deux.
La réponse
«Quels déploiements ont eu un événement BackOff?»
- payments/payment-api, oublié par le cluster.
- billing/billing-api, encore en panne.
La preuve
Le témoin kubectl est pris pendant l'incident.
- Même liste, ou le scénario échoue.
- 6 fois sur 6, les mêmes deux déploiements.
Essayer
Le scénario se rejoue sur kind.
Un connecteur, un script, une entité, une question: chaque étape est publiée avec sa sortie.