CrashLoopBackOff

CrashLoopBackOff est l’état affiché par un pod dont le conteneur redémarre de façon répétée, avec un délai croissant entre chaque tentative (backoff exponentiel : 10 secondes, puis 20, 40, jusqu’à un plafond de 5 minutes). Ce n’est pas une erreur en soi : c’est le kubelet qui applique la politique de redémarrage (restartPolicy) définie sur le pod, en espaçant les tentatives pour ne pas marteler un système déjà en échec.

Ce que l’état ne dit pas

CrashLoopBackOff décrit un symptôme, jamais une cause. Le conteneur peut planter au démarrage (erreur de configuration, dépendance absente), être tué par le kernel pour dépassement de mémoire (OOMKilled), ou être redémarré par une sonde liveness qui juge à tort le processus mort. Trois causes radicalement différentes, un seul état affiché ; la cause réelle se trouve dans les événements du pod (kubectl describe pod) et les logs du conteneur précédent (kubectl logs --previous), jamais dans l’état lui-même.

Le piège du redémarrage en cascade

Une sonde liveness mal réglée sur une dépendance lente peut mettre en CrashLoopBackOff toutes les replicas d’un service en même temps : chacune surveille le même endpoint lent, chacune redémarre au même moment, et le service entier disparaît pendant que la dépendance, elle, n’a jamais été réellement en panne. Le backoff exponentiel ralentit la fréquence des redémarrages sans jamais résoudre la cause. Il protège le cluster d’un martèlement, pas le service d’une indisponibilité.