Kubernetes Pod Lifecycle: Vom Pending bis zum Terminated – einfach erklärt

Der Kubernetes Pod Lifecycle beschreibt, welche Zustände ein Pod von der Erstellung bis zum Löschen durchläuft. Der aktuelle Zustand steht in status.phase; zusätzlich führt Kubernetes für jeden Container einen eigenen Container-Zustand. Wer Pods debuggt, muss beide Ebenen auseinanderhalten.

Die fünf Pod-Phasen

  • Pending: Der Pod ist vom Scheduler angenommen, aber noch nicht lauffähig — Images werden gezogen, Volumes gemountet, Init-Container laufen.
  • Running: Der Pod wurde einem Knoten zugewiesen und mindestens ein Container läuft oder startet gerade.
  • Succeeded: Alle Container sind erfolgreich beendet (Exit-Code 0) und werden nicht neu gestartet — der Normalfall bei Jobs und Batch-Aufgaben.
  • Failed: Mindestens ein Container ist mit Fehler beendet und wird nicht neu gestartet.
  • Unknown: Der Zustand ist nicht ermittelbar, weil das Kubelet auf dem Knoten nicht mehr mit der Control Plane kommuniziert.

Container-Zustände

Jeder Container kennt die Zustände Waiting, Running und Terminated. Ein abgeschlossener Container bleibt mit seinem Exit-Code in state.terminated sichtbar, der letzte Zustand davor in lastState.

  • Waiting: Der Container startet noch nicht. Der Grund steht im Feld reason, etwa ContainerCreating, ImagePullBackOff oder CrashLoopBackOff.
  • Running: Der Container-Prozess läuft; ein Hook oder Probe-Fehler kann ihn jederzeit beenden.
  • Terminated: Der Container ist beendet, mit exitCode und reason (Completed bei 0, Error sonst).

Diagnose mit kubectl

kubectl get pod web-1
kubectl describe pod web-1
kubectl get pod web-1 -o jsonpath='{.status.phase}'

Wichtig: Die STATUS-Spalte von kubectl get pods mischt beides. Pending und Running sind Phasen, CrashLoopBackOff, ImagePullBackOff oder Init:0/2 sind Gründe einzelner Container. Ein Filter auf --field-selector=status.phase!=Running findet diese Fälle deshalb nicht — sie stehen als Running in der Phase, obwohl der Container längst scheitert.

Abgrenzung

Wann ein beendeter Container neu startet, regelt nicht der Lifecycle selbst, sondern die restartPolicy. Aktionen beim Start und unmittelbar vor dem Beenden führen Lifecycle Hooks aus; der geordnete Ablauf beim Herunterfahren ist im Artikel Graceful Shutdown beschrieben.

Verwandte Grundlagen: Liveness Probe, Readiness Probe, PodSpec.