Identifier pourquoi un conteneur démarre puis s’arrête en boucle sans masquer la cause par des redémarrages manuels.
Avant de commencer
Travaillez sur une copie ou un test contrôlé lorsque l’action peut affecter la production. Conservez les horodatages, captures et l’ancienne configuration afin de comparer le résultat.
Étapes
- Afficher l’état du Pod, le nombre de redémarrages et les derniers événements.
- Lire les logs du conteneur actuel puis ceux de l’instance précédente.
- Contrôler command, args, variables, secrets, volumes et dépendances réseau.
- Vérifier les probes liveness/startup et les limites mémoire/CPU.
- Corriger la cause dans le Deployment ou le chart puis observer un nouveau rollout.
Validation
Rejouez le test initial après la modification et confirmez que le service attendu fonctionne sans créer de nouvelle régression. Documentez l’état final.
Kubernetes / Prometheus : état du workload et observabilité doivent rester corrélés
Repères techniques
- CrashLoopBackOff est un backoff de redémarrage : la cause réelle se trouve dans exit code, events, logs --previous, probes ou limites de ressources.
- Prometheus scrape une cible ; UP=1 prouve le scrape, pas que chaque métrique est sémantiquement correcte.
- Une forte cardinalité de labels peut augmenter fortement mémoire et stockage sans augmenter la valeur des métriques.
Kubernetes
Pour CrashLoop, lire les logs de l’instance précédente avant qu’ils disparaissent ; pour Prometheus, vérifier Target puis requête simple.
kubectl describe pod <pod>
kubectl logs <pod> --previous
kubectl get pod <pod> -o yamlPièges spécifiques
- Supprimer le Pod en boucle ne corrige pas la configuration du Deployment/StatefulSet.
- Ajouter un label contenant un ID utilisateur/requête crée souvent une cardinalité explosive.
Comment valider
- Le Pod reste Ready sans nouveaux restarts et les probes reflètent la santé réelle.
- La cible Prometheus est UP et la requête attendue retourne des séries stables avec cardinalité maîtrisée.
Preuves et vérifications
CrashLoopBackOff est un backoff de redémarrage : la cause réelle se trouve dans exit code, events, logs --previous, probes ou limites de ressources. Prometheus scrape une cible ; UP=1 prouve le scrape, pas que chaque métrique est sémantiquement correcte.
Contrôle de résultat
Le Pod reste Ready sans nouveaux restarts et les probes reflètent la santé réelle. La cible Prometheus est UP et la requête attendue retourne des séries stables avec cardinalité maîtrisée.
Point d’attention
Supprimer le Pod en boucle ne corrige pas la configuration du Deployment/StatefulSet. Une forte cardinalité de labels peut augmenter fortement mémoire et stockage sans augmenter la valeur des métriques.
Concepts liés
Référence primaire : Kubernetes Documentation — Pod lifecycle.