Un pod est coincé en CrashLoopBackOff. Comment le triez-vous ?

Commencez par kubectl describe pod pour les événements et le dernier code de sortie, puis kubectl logs avec --previous pour lire la sortie du conteneur qui a planté. Le code de sortie 137 signifie en général un OOM kill, donc vérifiez les limites mémoire ; un code 1 ou 2 signifie en général que l'application a échoué au démarrage, souvent à cause d'une configuration ou d'un secret manquant, ou d'une dépendance injoignable. Confirmez que le tag de l'image existe vraiment et vérifiez si une sonde de liveness trop agressive provoque la boucle.

kubectl describe pod d'abord, parce que la section des événements vous dit en général tout de suite s'il s'agit d'un échec de pull d'image, d'un secret manquant ou d'un OOM kill, et elle vous donne le dernier état de terminaison avec le code de sortie. Ensuite kubectl logs avec --previous, puisque le conteneur en cours a déjà été remplacé et que ses logs ont disparu. Le code 137 est un SIGKILL et neuf fois sur dix c'est la limite mémoire, donc je compare la limite à l'usage réel plutôt que de deviner. Un code 1 avec une pile d'appels est un échec de démarrage applicatif, généralement de la configuration. Je vérifie aussi la sonde de liveness, parce que j'ai vu un service Java parfaitement sain partir en boucle de crash uniquement parce qu'il lui fallait 40 secondes de préchauffage et que la sonde lui en accordait 10. Pour déboguer calmement, je vais scaler le déploiement, entrer dans une copie dont la commande est remplacée par un sleep, et reproduire là plutôt que de me battre avec le minuteur de redémarrage.