Ein Pod hängt in CrashLoopBackOff. Wie gehst du bei der Triage vor?

Fang mit kubectl describe pod an für Events und den letzten Exit Code, dann kubectl logs mit --previous, um die Ausgabe des abgestürzten Containers zu lesen. Exit Code 137 heißt meist OOM Kill, prüf also die Memory Limits. Exit 1 oder 2 heißt meist, dass die App beim Start gescheitert ist, oft wegen fehlender Config, fehlendem Secret oder einer nicht erreichbaren Dependency. Bestätige, dass das Image-Tag wirklich existiert, und prüf, ob eine zu aggressive Liveness Probe die Schleife verursacht.

Zuerst kubectl describe pod, denn der Events-Abschnitt sagt dir meist direkt, ob es ein fehlgeschlagener Image Pull, ein fehlendes Secret oder ein OOM Kill ist, und er gibt dir den letzten Terminated State mit dem Exit Code. Dann kubectl logs mit --previous, denn der laufende Container wurde bereits ersetzt und seine Logs sind weg. Exit 137 ist ein SIGKILL, und in neun von zehn Fällen ist das das Memory Limit, ich vergleiche also das Limit mit dem tatsächlichen Verbrauch, statt zu raten. Exit 1 mit einem Stacktrace ist ein Startfehler der Anwendung, meist Config. Ich prüfe außerdem die Liveness Probe, denn ich habe einen völlig gesunden Java-Service in einer Crash-Schleife gesehen, schlicht weil er 40 Sekunden zum Warmlaufen brauchte und die Probe ihm 10 gab. Um in Ruhe zu debuggen, skaliere ich das Deployment, exece in eine Kopie mit auf sleep überschriebenem Command und reproduziere dort, statt gegen den Restart-Timer zu kämpfen.