Eine Unternehmensanwendung läuft in Kubernetes. Plötzlich treten wiederholt Fehler auf: Mitarbeiter können Aufträge zeitweise nicht bearbeiten, ein interner Dienst reagiert unzuverlässig oder eine Schnittstelle verarbeitet Daten nicht mehr wie erwartet. Im Cluster fällt auf, dass ein Pod ständig neu startet. Die IT-Abteilung sieht möglicherweise den Status CrashLoopBackOff. Doch was bedeutet er, und liegt das Problem am Anwendungscode, an fehlenden Ressourcen oder an der Kubernetes-Konfiguration? Entscheidend ist, die tatsächliche Ursache zu finden, statt den betroffenen Pod einfach immer wieder neu zu starten.
1. Was bedeutet CrashLoopBackOff in Kubernetes?
Kubernetes überwacht Container entsprechend ihrer Konfiguration und versucht, ausgefallene Container bei entsprechender Restart-Policy erneut zu starten.
Wenn ein Container wiederholt beendet wird und Kubernetes zwischen den Startversuchen wartet, kann der Status CrashLoopBackOff erscheinen.
Wichtig ist die Unterscheidung: CrashLoopBackOff ist ein Hinweis auf wiederholte Startprobleme, aber keine vollständige Fehlerdiagnose.
Der Status allein sagt nicht, ob der Anwendungscode fehlerhaft ist, eine benötigte Verbindung fehlt oder der Container wegen einer Ressourcenbegrenzung beendet wurde.
Auch die Auswirkungen auf den Betrieb können unterschiedlich sein. Bei mehreren funktionsfähigen Replikaten bleibt eine Anwendung möglicherweise weiterhin erreichbar. Bei einem einzelnen betroffenen Dienst können dagegen wichtige Funktionen ausfallen.
Die offizielle Kubernetes-Dokumentation zum Pod-Lebenszyklus beschreibt diese Zustände und mögliche Ursachen.
2. Warum starten Kubernetes Pods ständig neu?
Mehrere technische Probleme können zu einem ähnlichen Verhalten führen. Deshalb sollten Fehlermeldungen nicht isoliert betrachtet werden.
| Mögliche Ursache | Woran sie erkennbar sein kann | Was untersucht werden sollte |
|---|---|---|
| Anwendungsfehler | Der Prozess beendet sich nach dem Start mit einem Fehler. | Container-Logs, Exit-Code und Änderungen an der Anwendung. |
| Speicherbegrenzung | Der Container wird beispielsweise mit OOMKilled beendet. | Speicherverbrauch, Limits und Verhalten der Anwendung. |
| Fehlende Konfiguration | Die Anwendung kann erforderliche Einstellungen oder Secrets nicht verwenden. | Freigegebene Konfiguration, Referenzen und vorhandene Berechtigungen. |
| Nicht erreichbare Abhängigkeit | Die Anwendung beendet sich, weil eine erforderliche Verbindung beim Start fehlschlägt. | Datenbank, API, Netzwerkzugriff und Fehlerbehandlung beim Start. |
| Fehlgeschlagene Liveness Probe | Kubernetes startet den Container nach wiederholten fehlgeschlagenen Prüfungen neu. | Prüfpfad, Zeitgrenzen, Anwendungslaufzeit und tatsächliches Antwortverhalten. |
Nicht jede fehlgeschlagene Zustandsprüfung führt zu einem Neustart. Eine fehlgeschlagene Readiness Probe kennzeichnet den Container zunächst als nicht bereit und beeinflusst die Weiterleitung von Anfragen. Eine fehlgeschlagene Liveness Probe kann dagegen einen Neustart auslösen.
Die Unterschiede erläutert die offizielle Dokumentation zu Liveness, Readiness und Startup Probes.
3. Welche Informationen helfen bei der Fehlersuche?
Wenn eine produktive Anwendung unzuverlässig wird, sollte zuerst der betroffene Bereich eingegrenzt werden.
Dafür sind insbesondere fünf Informationen hilfreich:
- Betroffene Anwendung: Welcher Dienst startet neu, und welche Geschäftsprozesse verwenden ihn?
- Zeitpunkt: Seit wann tritt das Problem auf? Gab es unmittelbar zuvor ein Deployment oder eine Konfigurationsänderung?
- Container-Zustand: Welcher Container ist betroffen, wie häufig wurde er neu gestartet und welcher Beendigungsgrund wird angezeigt?
- Logs und Ereignisse: Welche Fehlermeldungen erscheinen unmittelbar vor dem Neustart?
- Umgebung: Sind Ressourcen, Abhängigkeiten, Secrets und erforderliche Verbindungen verfügbar?
Warum die vorherigen Container-Logs wichtig sind
Nach einem Neustart zeigen aktuelle Logs möglicherweise nur den neuen Startversuch. Die eigentliche Fehlermeldung kann in den Protokollen der zuvor beendeten Containerinstanz stehen.
Kubernetes bietet dafür unter anderem die Möglichkeit, vorherige Container-Logs abzurufen. Auch die Beschreibung des Pods und seine Ereignisse helfen bei der Eingrenzung.
Die offizielle Anleitung Debug Running Pods beschreibt die entsprechenden Diagnosemöglichkeiten.
Bei der Weitergabe von Protokollen sollten vertrauliche Daten, Tokens und andere Zugangsinformationen geschützt werden.
Für einen externen Dienstleister ist nicht der größtmögliche Log-Auszug entscheidend, sondern eine nachvollziehbare Beschreibung des Fehlers und der betroffenen Umgebung.
4. Praxisbeispiel: Eine Anwendung zur Auftragsbearbeitung startet ständig neu
Angenommen, ein mittelständisches Unternehmen betreibt eine Anwendung zur Auftragsbearbeitung in einem Kubernetes-Cluster.
Die Anwendung überträgt freigegebene Bestellungen an das ERP-System. Nach einem Software-Update treten wiederholt Fehler auf.
Die Mitarbeiter können sich weiterhin anmelden. Bei der Übergabe von Aufträgen kommt es jedoch zu Unterbrechungen.
Was zeigt die technische Untersuchung?
Der betroffene Container startet wiederholt neu. In den Protokollen wird sichtbar, dass die Anwendung beim Start eine Verbindung zu einer benötigten Datenbank aufbauen möchte.
Nach dem Update verwendet die neue Anwendungsversion eine geänderte Konfigurationsreferenz. Der erwartete Wert wird deshalb nicht korrekt bereitgestellt.
Die Anwendung beendet sich, weil sie die erforderliche Verbindung nicht herstellen kann.
In diesem angenommenen Fall liegt die Ursache nicht an einer allgemein fehlerhaften Kubernetes-Installation. Entscheidend ist die Kombination aus Anwendungsversion, Konfiguration und benötigter Datenbankverbindung.
Was wird geändert?
Das zuständige Team prüft die freigegebene Konfiguration und stellt die korrekte Zuordnung wieder her.
Anschließend wird die betroffene Anwendung kontrolliert neu bereitgestellt.
Die Ursache wäre nicht behoben, wenn lediglich die Anzahl erlaubter Neustarts verändert oder eine Zustandsprüfung ohne Prüfung der Anwendung abgeschaltet würde.
Wann gilt das Problem als gelöst?
Es reicht nicht aus, dass der Pod wieder den Status Running zeigt.
Nach der technischen Prüfung wird ein geeigneter Testauftrag durch den vereinbarten Prozess geführt:
- Der Auftrag wird in der Anwendung erfasst.
- Die Daten werden an das ERP übertragen.
- Die Verarbeitung wird im Zielsystem bestätigt.
- Während des Tests treten keine erneuten unerwarteten Container-Neustarts auf.
Damit wird nicht nur der technische Zustand des Containers geprüft, sondern auch die ursprünglich betroffene Geschäftsfunktion.
5. Wie lässt sich die Störung gezielt beheben?
Die richtige Maßnahme richtet sich nach der festgestellten Ursache.
Ein Speicherproblem erfordert möglicherweise die Untersuchung der Ressourcennutzung oder des Anwendungscodes. Eine fehlerhafte Liveness Probe muss gegen das tatsächliche Start- und Antwortverhalten geprüft werden. Bei einer falschen Konfiguration sind dagegen die betroffenen Werte und ihre Bereitstellung zu untersuchen.
Ein pauschales Erhöhen der Ressourcen oder Abschalten von Prüfungen ist keine verlässliche Fehlerbehebung.
Bei produktiven Anwendungen sollten Änderungen kontrolliert erfolgen:
- Ursache und betroffene Komponenten dokumentieren.
- Vorgesehene Änderung fachlich und technisch abstimmen.
- Mögliche Auswirkungen auf laufende Anwendungen berücksichtigen.
- Änderung in der vorgesehenen Umgebung umsetzen.
- Containerzustand, Logs und relevante Geschäftsprozesse prüfen.
- Ergebnis und verbleibende Risiken an das zuständige Team übergeben.
Wenn der Fehler unmittelbar nach einem Update aufgetreten ist, muss außerdem geklärt werden, ob eine Rückkehr zum vorherigen Anwendungsstand sinnvoll und technisch möglich ist.
Die Rückkehr zu einer älteren Container-Version setzt nicht automatisch Datenbankänderungen oder bereits verarbeitete Geschäftsdaten zurück.
Wie sich umfangreichere Änderungen am Cluster kontrolliert vorbereiten lassen, beschreibt unser Beitrag Kubernetes-Update planen.
6. Wann ist externe Kubernetes-Unterstützung sinnvoll?
Externe Unterstützung kann sinnvoll sein, wenn die Anwendung geschäftskritisch ist, wiederholte Neustarts nicht eindeutig erklärt werden können oder internes Wissen über Deployment und Cluster-Konfiguration fehlt.
Wichtig ist dabei, nicht nur einen Kubernetes-Status zu übergeben. Ein Dienstleister sollte verstehen, welche Anwendung betroffen ist und welches Ergebnis das Unternehmen benötigt.
Für die erste Abstimmung reichen häufig diese Angaben:
- Welche Anwendung oder welcher Dienst ist betroffen?
- Welche geschäftliche Funktion ist beeinträchtigt?
- Seit wann tritt der Fehler auf?
- Welche Änderungen wurden zuletzt durchgeführt?
- Welche Cluster- und Deployment-Technologie wird verwendet?
- Welche Prüfungen müssen nach der Behebung erfolgreich sein?
Kubertino unterstützt Unternehmen bei der Untersuchung von Störungen in bestehenden Kubernetes-Umgebungen. Dabei werden Anwendung, Deployment, Ressourcen und Cluster-Konfiguration gemeinsam betrachtet.
Je nach festgestellter Ursache können Konfigurationen angepasst, technische Fehler behoben und die vereinbarten Anwendungen anschließend geprüft werden.
Die Leistung Kubernetes-Management beschreibt die Unterstützung bei solchen Aufgaben, einschließlich abgestimmter Änderungen und Dokumentation.
Wenn das Problem bereits beim Erstellen oder Ausliefern einer neuen Version entsteht, kann auch die vorgelagerte CI/CD-Pipeline betroffen sein. Dazu passt unser Beitrag CI/CD-Pipeline schlägt fehl.
Der nächste sinnvolle Schritt ist eine klar abgegrenzte technische Untersuchung mit einem vereinbarten Ziel: die Ursache nachvollziehbar eingrenzen und festlegen, wie die betroffene Anwendung wieder zuverlässig für ihren vorgesehenen Geschäftsprozess eingesetzt werden kann.
7. Häufige Fragen zu Kubernetes Pod-Neustarts
Warum startet ein Kubernetes Pod immer wieder neu?
Wiederholte Neustarts können unter anderem durch Anwendungsfehler, Speicherbegrenzungen, fehlerhafte Konfigurationen oder fehlgeschlagene Liveness Probes entstehen. Der konkrete Grund muss anhand von Container-Zustand, Logs und Ereignissen ermittelt werden.
Was bedeutet CrashLoopBackOff?
CrashLoopBackOff zeigt an, dass Kubernetes nach wiederholten Container-Startproblemen vor weiteren Versuchen wartet. Der Status beschreibt das Verhalten, nicht die eigentliche technische Ursache.
Hilft es, den betroffenen Pod einfach zu löschen?
Nicht unbedingt. Wird der Pod von einem Controller verwaltet, kann ein Ersatz erstellt werden. Bleibt die eigentliche Ursache bestehen, tritt der Fehler möglicherweise erneut auf. Vor Eingriffen sollten auch mögliche Auswirkungen auf den laufenden Betrieb berücksichtigt werden.
Kann eine falsch konfigurierte Liveness Probe Neustarts verursachen?
Ja. Wenn eine Liveness Probe wiederholt fehlschlägt, kann Kubernetes den Container neu starten. Vor einer Änderung sollte geprüft werden, ob die Anwendung tatsächlich nicht mehr funktionsfähig ist oder ob Prüfpfad und Zeitgrenzen unpassend konfiguriert wurden.
Wann sollte ein externer Kubernetes-Spezialist hinzugezogen werden?
Wenn eine wichtige Anwendung instabil bleibt, die Ursache nicht eindeutig erkennbar ist oder für eine sichere Änderung spezielles Wissen über die vorhandene Umgebung benötigt wird. Für die Abstimmung sind betroffene Anwendungen, Fehlermeldungen und das gewünschte Ergebnis besonders hilfreich.