Kubernetes CrashLoopBackOff : la méthode de diagnostic
Les commandes essentielles pour comprendre un pod en CrashLoopBackOff, retrouver les logs précédents et vérifier probes, ressources et configuration.
Ce que signifie CrashLoopBackOff
CrashLoopBackOff n’est pas la cause de l’incident. Kubernetes indique qu’un conteneur démarre, s’arrête, puis subit un délai croissant avant une nouvelle tentative. La cause se trouve dans l’état précédent, les événements ou la configuration du workload.
Commence par confirmer le namespace, le nombre de redémarrages et l’âge du pod.
kubectl get pods -A
kubectl get pod checkout-7c49d -n shop -o wideRécupérer les preuves avant le prochain redémarrage
La commande describe expose les événements de scheduling, les erreurs de montage, les échecs de probes et les limites de ressources. Les logs avec --previous sont indispensables lorsque le conteneur courant vient juste de redémarrer.
Si le pod contient plusieurs conteneurs, précise le nom avec -c afin de ne pas lire le sidecar par erreur.
kubectl describe pod checkout-7c49d -n shop
kubectl logs checkout-7c49d -n shop --previous
kubectl logs checkout-7c49d -n shop -c checkout --previousVérifier configuration, probes et ressources
Compare les variables attendues par l’application avec le Deployment, les ConfigMaps et les Secrets. Vérifie ensuite que la liveness probe ne tue pas un service encore en initialisation et que les limites mémoire ne provoquent pas OOMKilled.
Une startupProbe est souvent plus adaptée qu’une augmentation arbitraire du délai de liveness pour une application lente à démarrer.
kubectl get deploy checkout -n shop -o yaml
kubectl get configmap checkout-config -n shop -o yaml
kubectl get pod checkout-7c49d -n shop -o jsonpath='{.status.containerStatuses[*].lastState}'Déployer la correction avec contrôle
Modifie la source déclarative dans Git ou dans ton outil de déploiement, puis suis le rollout. Une édition manuelle directe peut dépanner, mais elle crée une dérive qui sera écrasée à la prochaine livraison.
Valide les endpoints et une requête fonctionnelle après le retour des pods Ready.
kubectl rollout restart deployment/checkout -n shop
kubectl rollout status deployment/checkout -n shop
kubectl get endpoints checkout -n shop