etis GmbHAlle Artikel
IT-Service Hands-on

CrashLoopBackOff in fünf Minuten eingrenzen

Ein Kubernetes-Pod steckt im CrashLoopBackOff? Mit diesen fünf kubectl-Befehlen findet man die Ursache in fast allen Fällen – systematisch statt ratend.

etis GmbH2 Min. Lesezeit

CrashLoopBackOff ist keine Fehlermeldung, sondern ein Symptom: Der Container startet, stirbt, und Kubernetes wartet mit jedem Neustart länger. Die eigentliche Ursache steht woanders – und lässt sich mit fünf Befehlen fast immer eingrenzen.

1. Überblick verschaffen

kubectl get pods -n <namespace>

Interessant ist die Spalte RESTARTS und das Alter des Pods. Ein Pod, der seit Wochen lief und jetzt crasht, deutet auf eine externe Änderung hin (Config, Secret, abhängiger Dienst). Ein neuer Pod, der nie hochkam, deutet auf das letzte Deployment.

2. Events lesen

kubectl describe pod <pod> -n <namespace>

Im Abschnitt Events stehen die Klassiker: OOMKilled (Memory-Limit zu knapp), ImagePullBackOff-Vorgeschichte, fehlgeschlagene Probes oder fehlende Volumes. Last State: Terminated mit Exit Code ist der wichtigste Einzelwert: Exit-Code 137 ist ein Kill (meist OOM), Exit-Code 1 ein Anwendungsfehler.

3. Logs des abgestürzten Containers

kubectl logs <pod> -n <namespace> --previous

Der Flag --previous ist entscheidend: Er zeigt die Logs der letzten Instanz – also der, die gecrasht ist. Ohne ihn sieht man nur den aktuellen Startversuch, der oft noch gar nichts geloggt hat.

4. Konfiguration gegenprüfen

kubectl get pod <pod> -n <namespace> -o yaml

Stimmen Image-Tag, Env-Variablen, gemountete Secrets und ConfigMaps? Ein häufiges Muster: Das Deployment referenziert einen Secret-Key, der umbenannt wurde – der Container startet und beendet sich sofort, weil eine Pflicht-Variable leer ist.

5. Abhängigkeiten testen

kubectl run debug --rm -it --image=busybox -n <namespace> -- sh

Aus einem Wegwerf-Pod heraus lässt sich prüfen, ob Datenbank, Message-Broker oder externe API überhaupt erreichbar sind. Viele Anwendungen beenden sich absichtlich, wenn beim Start eine Abhängigkeit fehlt – aus Kubernetes-Sicht sieht das aus wie ein Crash.

Merksatz

Erst describe (was sagt Kubernetes?), dann logs --previous (was sagt die Anwendung?), dann Konfiguration und Abhängigkeiten. Wer diese Reihenfolge einhält, braucht für die meisten CrashLoops keine fünf Minuten.

#kubernetes#troubleshooting#kubectl