CrashLoopBackOff ist ein Zustand eines Kubernetes-Pods, bei dem ein Container wiederholt startet, sofort abstürzt und vom Kubelet neu gestartet wird. kubectl get pods zeigt dann in der Status-Spalte CrashLoopBackOff.
Backoff-Verzögerung
Das Kubelet wartet zwischen den Neustartversuchen mit exponentiell wachsender Verzögerung: 10, 20, 40 Sekunden und so weiter, gedeckelt bei fünf Minuten. Nach etwa zehn Minuten fehlerfreien Laufs wird der Zähler zurückgesetzt. Die Neustarts folgen der Restart Policy — Standard ist Always, dann versucht das Kubelet es auch nach einem Fehler erneut. Der Backoff gilt für alle Container des Pods.
Typische Ursachen
- Konfigurationsfehler: fehlende Secrets oder ConfigMaps, falsche Argumente oder Umgebungsvariablen
- Abhängigkeiten nicht erreichbar: Datenbank oder anderer Dienst antwortet beim Start noch nicht
- Ressourcen: der Container wird wegen seines Limits per
OOMKilledbeendet (Exit-Code 137) - Probleme im Anwendungscode, die einen sofortigen Absturz verursachen
- Eine Liveness-Probe schlägt dauerhaft fehl
Diagnose
kubectl logs <pod> --previous
kubectl describe pod <pod>Die Logs des letzten Laufs zeigen die Absturzursache; kubectl describe listet Events und den letzten Zustand (Last State: Terminated mit Exit-Code und Grund). Weitere Hilfen stehen unter kubectl-Befehle. Der Lebenslauf eines Pods ist im Artikel Kubernetes Pod Lifecycle erklärt.
Verwandte Grundlagen: Kubernetes Termination Grace Period, Kubernetes Image Pull Policy.