Erwartetes Verhalten und der CrashLoopBackOff Fehler

Bei der Bereitstellung einer Anwendung in Kubernetes (K8s) wird erwartet, dass der Pod von Pending direkt zu Running wechselt und die darin befindlichen Container aktiv bleiben. Einer der häufigsten und berüchtigtsten Fehler, auf den Administratoren jedoch stoßen, ist der Status CrashLoopBackOff.

Dieser Status bedeutet, dass ein Container innerhalb des Pods gestartet wird, sofort abstürzt, und Kubernetes kontinuierlich versucht, ihn neu zu starten – mit zunehmenden Verzögerungszeiten (Backoffs) zwischen jedem Versuch (10s, 20s, 40s, bis zu 5 Minuten).

Im Gegensatz zu einem Pending-Status (der auf ein Infrastruktur- oder Scheduling-Problem hinweist), sagt ein CrashLoopBackOff explizit aus, dass der Node den Pod geplant, das Image heruntergeladen und den Container ausgeführt hat, aber die Anwendung darin freiwillig beendet wurde oder vom Kernel gewaltsam gekillt werden musste.

Voraussetzungen

Bevor Sie mit den Problembehandlungsschritten beginnen, stellen Sie sicher, dass Sie Folgendes haben:

  • Einen laufenden Kubernetes Cluster (Minikube, EKS, GKE, AKS oder Bare-Metal).
  • Das Befehlszeilenwerkzeug kubectl ist installiert und auf Ihren Cluster konfiguriert.
  • Den exakten Namen des Pods, der den Fehler zeigt, sowie seinen Namespace.

Ursache des Problems: CrashLoopBackOff

Da CrashLoopBackOff eher ein Symptom als die exakte Ursache ist, müssen wir nach dem zugrundeliegenden Grund suchen. Zu den häufigsten Verursachern gehören:

  1. Anwendungs-Panik / Fataler Fehler: Der Code stößt unmittelbar nach dem Start auf eine unbehandelte Ausnahme oder eine fehlende Abhängigkeit (z. B. der Fehler bei der Verbindung zu einer Datenbank) und wird abgebrochen.
  2. Fehlende Konfiguration / Secrets: Die Anwendung erwartet eine Umgebungsvariable, die aus einer ConfigMap oder einem Secret gemappt wird, welches nicht existiert oder einen Tippfehler aufweist.
  3. Fehler bei der Liveness-Probe: Ihre livenessProbe schlägt dauerhaft fehl, was Kubernetes dazu veranlasst, den Container als “ungesund” zu interpretieren und ihn wiederholt zu töten, um ihn neu zu starten.
  4. OOMKilled (Out of Memory): Der Container versucht, mehr Speicher zuzuweisen, als sein limits.memory zulässt, was den Linux-Kernel zwingt, den Prozess sofort zu beenden.
  5. Ungültiger Entrypoint / Befehl: Der Befehl im YAML oder der CMD/ENTRYPOINT in Ihrem Dockerfile ist syntaktisch falsch, es fehlen Berechtigungen oder er wird sofort beendet, weil er kein Vordergrund-Prozess ist.

Schritt-für-Schritt-Lösung

1. Beschreibung des Pods anzeigen

Der erste Befehl, den Sie ausführen sollten, ist immer describe um den exakten Exit Code abzurufen.

kubectl describe pod <pod-name> -n <namespace>

Scrollen Sie im Ausgabeprotokoll nach unten zum Abschnitt Containers und schauen Sie sich den Bereich Last State an:

    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 27 Feb 2026 10:00:00 GMT
      Finished:     Fri, 27 Feb 2026 10:00:02 GMT

Häufige Exit Codes:

  • Exit Code 1: Allgemeiner Anwendungsfehler (sehen Sie sich Ihre Code-Logs an).
  • Exit Code 2: Missbrauch von Shell Built-ins (überprüfen Sie Ihren Dockerfile-Befehl).
  • Exit Code 126: Der aufgerufene Befehl kann nicht ausgeführt werden (Berechtigungsfehler).
  • Exit Code 128: Ungültiges Exit-Argument.
  • Exit Code 137: OOMKilled (Out of Memory - der Container hat sein Limit erreicht).
  • Exit Code 255: Exit-Status außerhalb der normalen Spezifikation (normalerweise ein fataler Initialisierungsfehler).

2. Vorherige Logs prüfen

Da der Container aktiv abstürzt und neu startet, kann der normale Befehl kubectl logs ein leeres Ergebnis liefern, wenn der Container genau in dem Moment hochfährt. Nutzen Sie stattdessen die Flagge --previous, um die Logs der toten Instanz unmittelbar vor der Tötung einzusehen:

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

Dies ist enorm effektiv, um schnelle Stack-Traces oder Fehler bezüglich “Datei Nicht Gefunden” zu entdecken, welche intern zur fatalen Panik geführt haben.

3. Auf OOMKilled prüfen

Sollte der Fehlercode 137 sein oder Ihre Ausgabe wörtlich OOMKilled rufen, so bedeutet das, dass das maximale Memory-Limit des Containers erreicht wurde. Gehen sie in Ihre YAML-Deployment Einstellungen und skalieren Sie sofort Ihre Ressourcen:

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"  # <-- Erhöhen Sie diesen Wert!
    cpu: "500m"

Implementieren Sie im Nachhinein die Ausweitung über Befehl kubectl apply -f deployment.yaml.

4. Entrypoint für die Fehlerbehebung überschreiben (Alternative Lösung)

Falls unklare Probleme durch interne Verzeichnisberechtigungen herrühren die in Logs nicht existieren, ist das manuelle “Einschlafen-Lassen” die stärkste Fehlerbehebung. Dies erzwingt, dass Kubernetes den Container stoppt zu Tode-Rebooten und erlaubt Ihnen eine Terminal-Aktivität anzusteuern:

Ändern Sie vorrübergehend Ihr internes Deployment Manifest der Container-Bereitstellung:

containers:
  - name: my-crashing-app
    image: my-registry/my-app:v1
    command: ["sleep", "3600"] # Hält den Container künstlich am Leben

Nehmen Sie die Implementierung dieses Manifestes vor. Der Container wird sich beruhigen und den Status Running dauerhaft betreten. Interagieren Sie nun händisch über exec Modus:

kubectl exec -it <pod-name> -- /bin/sh

Während dieser manuellen Terminal Phase innerhalb des Hosts können sie Ihre primäre Startup Logik manuell (npm start, python app.py oder andere Routinen) per Input testen, um somit jegliche direkten Panikausnahmen live vor Ort zu sichten um Ursachen klar aufzudecken.

Prävention

Um das wiederholte Auftreten von CrashLoopBackOff in all ihren Entwicklungsclustern massgeblich zu reduzieren, wird empohlen diese Best Practices strikt einzuhalten:

  • Korrekte Implementierung der Liveness / Readiness Probes: Stellen Sie sicher, dass Ihre livenessProbe der Webanwendung stets ausreichend initialDelaySeconds gibt, damit der Lade-Boost komplett abgeschlossen wird, bevor Ping Signale abgesetzt werden.
  • Init Containers (Start-Modus Module): Benötigt Ihr Programm die zwingende Startsynchronisation extern verbundener Server (zB Datenbank), benutzen sie Init Containers um den initialen Ladeprozess Kubernetes ausbremsen zu lassen.
  • CI/CD Pipeline-Datenprüfung: Setzen Sie den Verifikationstest für die korrekte Definition und Verfügbarkeit geforderter Secret Keys / Config Map Elemente während CI/CD Operationen explizit ein um Konfigurationsexport auf fehlerhafte Pfade zu verwehren.

Zusammenfassung

  • Der CrashLoopBackOff deutet den sofortigen Abbruch der Container-Ausführung an.
  • Führen Sie Kommandozeile kubectl describe pod ein um den exakten fehlerhaften Code (Exit Code) abzulesen.
  • Rufen Sie sich vergangene Aufzeichnungen intern abgestorbener Module mit dem kubectl logs --previous Kommando wieder hervor.
  • Ist der Ausgabe-Code versehen mit 137 handelt es sich um Limit-Tod durch RAM-Unterversorgung (OOMKilled).
  • Manipulieren Sie fehlerhafte Instanzen per sleep command in YAML, um so sicheren Halt in Konsole über SSH zu erkämpfen und interne Berechtigungen manuell nachstellen.

Verwandte Artikel