Pod-Lebenszyklus und -Zustände

Pods sind nicht statisch, sondern durchlaufen verschiedene Phasen – ähnlich wie auf einer Reise. Das Verständnis dieses „Lebenszyklus“ ist entscheidend, um Ihre Anwendungen in Kubernetes effektiv zu verwalten.

So können Sie erkennen, ob Ihre Anwendung gesund ist, gerade gestartet wird oder auf ein Problem gestoßen ist.

Kubernetes unterteilt Pods in fünf Hauptphasen. Diese Phasen geben einen Überblick über den aktuellen Zustand eines Pods:

• Pending: Der Pod wurde von Kubernetes akzeptiert, aber seine Container wurden noch nicht gestartet.
• Running: Mindestens ein Container im Pod läuft oder wird gerade gestartet.
• Succeeded: Alle Container im Pod wurden erfolgreich abgeschlossen und werden nicht neu gestartet.
• Failed: Alle Container wurden beendet, und mindestens einer ist fehlgeschlagen (z. B. mit einem Exit-Code ungleich null).
• Unknown: Der Zustand des Pods konnte nicht ermittelt werden, häufig aufgrund von Kommunikationsproblemen.

Ein Pod befindet sich in der Phase Pending, wenn er vom Kubernetes-API-Server akzeptiert wurde, aber einer oder mehrere seiner Container noch nicht erstellt oder konfiguriert wurden.

Häufige Gründe sind:

• Das Container-Image wird noch heruntergeladen.
• Der Cluster verfügt nicht über genügend Ressourcen (CPU/Speicher), um den Pod einzuplanen.
• Volumes werden noch bereitgestellt oder eingebunden.

Sehen wir uns ein Beispiel an. Wenn Sie versuchen, einen Pod mit einem nicht vorhandenen Image bereitzustellen, bleibt er möglicherweise im Status „Pending“ hängen oder zeigt einen Fehler beim Abrufen des Images an.

Hier ist eine beispielhafte Pod-Definition:

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

Um den Status zu überprüfen, würden Sie kubectl get pod verwenden. Die Ausgabe könnte etwa so aussehen:

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

ErrImagePull bedeutet, dass das Image nicht abgerufen werden konnte. Daher erreicht der Pod nicht den Status Running.

Die Phase Running bedeutet, dass der Pod einem Node zugewiesen wurde und alle seine Container erfolgreich erstellt wurden. Mindestens ein Container läuft oder wird gerade gestartet beziehungsweise neu gestartet.

Beachten Sie, dass ein Pod im Zustand „Running“ nicht automatisch bedeutet, dass die darin ausgeführte Anwendung fehlerfrei oder vollständig funktionsfähig ist. Es bedeutet lediglich, dass die Container aktiv sind.

Hier sehen Sie eine standardmäßige Pod-Definition für einen Nginx-Webserver. Nach ihrer Anwendung sollte der Pod schnell in den Zustand „Running“ wechseln.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Nach der Bereitstellung würde kubectl get pod Folgendes anzeigen:

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

Der Wert 1/1 in READY bestätigt, dass ein Container von einem definierten Container bereit ist.

Diese Phasen stellen die Beendigungszustände eines Pods dar:

• Succeeded: Ein Pod wechselt in diese Phase, wenn alle darin enthaltenen Container erfolgreich beendet wurden und nicht neu gestartet werden. Das ist typisch für Pods, die einmalige Aufgaben oder Batch-Jobs ausführen.
• Failed: Ein Pod befindet sich in der Phase Failed, wenn alle Container im Pod beendet wurden und mindestens ein Container aufgrund eines Fehlers beendet wurde (beispielsweise mit einem Statuscode ungleich null).

Wenn Sie diese Phasen verstehen, können Sie den Abschluss von Jobs oder Fehler in Anwendungen besser diagnostizieren.

Die Phase Unknown bedeutet, dass der Zustand des Pods nicht ermittelt werden konnte. Diese Phase ist selten, aber kritisch.

Sie tritt normalerweise auf, wenn der Kubelet (der Agent) auf dem Node, auf dem der Pod ausgeführt wird, die Kommunikation mit dem Kubernetes-API-Server einstellt. Ursache können ein Netzwerkproblem, ein abgestürztes Kubelet oder ein Problem mit dem Node selbst sein.

Pods haben zwar übergeordnete Phasen, aber auch die einzelnen Container in einem Pod besitzen eigene, detailliertere Zustände. Diese Zustände beeinflussen direkt die Gesamtphase des Pods:

• Waiting: Der Container wartet derzeit auf den Start. Mögliche Gründe sind das Herunterladen des Images, die Zuweisung von Ressourcen oder das Warten auf den Abschluss von Init-Containern.
• Running: Der Container wird aktiv und ohne Probleme ausgeführt.
• Terminated: Der Container hat seine Ausführung beendet. Sie kann erfolgreich oder fehlerhaft gewesen sein.

Stellen Sie sich vor, Sie haben gerade einen neuen Pod bereitgestellt. Sie führen kubectl get pod my-app aus und sehen folgende Ausgabe:

NAME      READY   STATUS     RESTARTS   AGE
my-app    0/1     Pending    0          12s

Was ist der wahrscheinlichste Grund dafür, dass sich der Pod my-app mit 0/1 bereiten Containern im Zustand Pending befindet?

Sie haben gelernt, dass Kubernetes-Pods verschiedene Phasen durchlaufen: Pending, Running, Succeeded, Failed und Unknown. Diese Phasen geben einen Überblick über den Betriebszustand eines Pods.

Außerdem haben wir die einzelnen Containerzustände (Waiting, Running, Terminated) behandelt, die zur Gesamtphase des Pods beitragen. Die Überwachung dieser Zustände mit kubectl get pod und kubectl describe pod (die Sie später noch genauer kennenlernen!) ist entscheidend, um den Zustand Ihrer Anwendung zu verstehen.

Als Nächstes sehen wir uns fortgeschrittene Pod-Muster an und untersuchen, wie Sie mithilfe des Sidecar-Musters mehrere gemeinsam angeordnete Container in einem einzelnen Pod ausführen.