Fehlerbehebung: Warum hängt mein Kubernetes-Pod im Status Pending oder CrashLoopBackOff?

Pending und CrashLoopBackOff sehen ähnlich aus, wenn Sie auf einen Rollout warten, bedeuten aber sehr unterschiedliche Dinge. Pending bedeutet normalerweise, dass Kubernetes den Pod nicht platzieren oder vorbereiten konnte. CrashLoopBackOff bedeutet, dass der Container gestartet ist, dann beendet wurde und Kubernetes den nächsten Neustart verzögert.

Dieser Unterschied ist wichtig. Ein ausstehender Pod ist oft ein Problem mit dem Scheduler, dem Image oder dem Speicher. Ein abstürzender Pod ist normalerweise ein Problem mit der Anwendung, dem Befehl, der Probe, den Berechtigungen oder dem Speicher. Beginnen Sie mit dieser Unterscheidung, und der Weg zur Fehlerbehebung wird viel kürzer.

Pod-Status verstehen: Pending vs. CrashLoopBackOff

Bevor Sie mit der Fehlerbehebung beginnen, ist es wichtig zu verstehen, was diese beiden Zustände bedeuten.

Pod-Status: Pending

Ein Pod im Status Pending bedeutet, dass Kubernetes das Pod-Objekt akzeptiert hat, es aber noch nicht vollständig in einen laufenden Containerzustand übergegangen ist. Manchmal wurde es noch nicht auf einen Knoten geplant. Manchmal hat es einen zugewiesenen Knoten, aber der Image-Pull, der Volume-Attach oder die Sandbox-Einrichtung wurde noch nicht abgeschlossen.

Pod-Status: CrashLoopBackOff

Ein Pod im Status CrashLoopBackOff bedeutet, dass ein Container innerhalb des Pods wiederholt startet, abstürzt und dann neu startet. Kubernetes implementiert eine exponentielle Backoff-Verzögerung zwischen Neustarts, um eine Überlastung des Knotens zu verhindern. Dieser Zustand weist fast immer auf ein Problem mit der Anwendung hin, die im Container selbst oder in seiner unmittelbaren Umgebung ausgeführt wird.

Ein subtiler Fall: Ein Container kann mit dem Exit-Code 0 beendet werden und dennoch in eine Neustartschleife geraten, wenn die Workload ein langlebiger Server sein soll. Dies passiert oft, wenn ein Deployment versehentlich einen einmaligen Befehl ausführt, wie z. B. ein Migrationsskript oder einen Shell-Befehl, der sofort beendet wird.

Fehlerbehebung bei Pods im Status Pending

Wenn ein Pod Pending ist, sollten Sie zuerst den Scheduler und den Knoten überprüfen, auf den er gelangen soll. Hier sind die häufigsten Ursachen und Diagnoseschritte.

1. Unzureichende Ressourcen auf Knoten

Einer der häufigsten Gründe für einen Pending-Pod ist, dass kein Knoten im Cluster über genügend verfügbare Ressourcen (CPU, Arbeitsspeicher) verfügt, um die requests des Pods zu erfüllen. Der Scheduler kann keinen geeigneten Knoten finden.

Diagnoseschritte:

Pod beschreiben: Der Befehl kubectl describe pod ist hier Ihr bester Freund. Er zeigt oft Ereignisse an, die erklären, warum der Pod nicht geplant werden kann.
```
kubectl describe pod <pod-name> -n <namespace>
```
Achten Sie auf Ereignisse wie "FailedScheduling" und Meldungen wie "0/3 nodes are available: 3 Insufficient cpu" oder "memory".
Knotenressourcen überprüfen: Sehen Sie sich die aktuelle Ressourcennutzung und -kapazität Ihrer Knoten an.
```
kubectl get nodes
kubectl top nodes # (erfordert metrics-server)
```

Lösung:

Cluster-Kapazität erhöhen: Fügen Sie Ihrem Kubernetes-Cluster weitere Knoten hinzu.
Pod-Ressourcenanforderungen anpassen: Reduzieren Sie die requests für CPU und Arbeitsspeicher in Ihrem Pod-Manifest, wenn sie zu hoch eingestellt sind.
```
resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
```
Andere Pods evakuieren: Entfernen Sie manuell Pods mit niedrigerer Priorität von Knoten, um Ressourcen freizugeben (mit Vorsicht verwenden).

2. Image-Pull-Fehler

Wenn Kubernetes den Pod auf einen Knoten planen kann, der Knoten jedoch das Container-Image nicht pullen kann, bleibt der Pod Pending.

Häufige Ursachen:

Falscher Image-Name/Tag: Tippfehler im Image-Namen oder Verwendung eines nicht existierenden Tags.
Authentifizierung für private Registry: Fehlende oder falsche ImagePullSecrets für private Registries.
Netzwerkprobleme: Knoten kann die Image-Registry nicht erreichen.

Diagnoseschritte:

Pod beschreiben: Auch hier ist kubectl describe pod der Schlüssel. Achten Sie auf Ereignisse wie "Failed" oder "ErrImagePull" oder "ImagePullBackOff".
```
kubectl describe pod <pod-name> -n <namespace>
```
Beispiel für ein Ausgabeereignis: Failed to pull image "my-private-registry/my-app:v1.0": rpc error: code = Unknown desc = Error response from daemon: pull access denied for my-private-registry/my-app, repository does not exist or may require 'docker login'
ImagePullSecrets überprüfen: Stellen Sie sicher, dass imagePullSecrets korrekt in Ihrem Pod oder ServiceAccount konfiguriert sind.
```
kubectl get secret <your-image-pull-secret> -o yaml -n <namespace>
```

Lösung:

Image-Name/Tag korrigieren: Überprüfen Sie den Image-Namen und das Tag in Ihrem Deployment-Manifest.

ImagePullSecrets konfigurieren: Stellen Sie sicher, dass Sie ein docker-registry-Secret erstellt und mit Ihrem Pod oder ServiceAccount verknüpft haben.

kubectl create secret docker-registry my-registry-secret \
  --docker-server=your-registry.com \
  --docker-username=your-username \
  --docker-password=your-password \
  --docker-email=your-email -n <namespace>

Fügen Sie es dann zu Ihrer Pod-Spezifikation hinzu:

spec:
  imagePullSecrets:
  - name: my-registry-secret
  containers:
  ...

Netzwerkkonnektivität: Überprüfen Sie die Netzwerkkonnektivität vom Knoten zur Image-Registry.

Wenn Sie eine private Registry verwenden, überprüfen Sie auch den ServiceAccount. Viele Teams hängen imagePullSecrets an den standardmäßigen ServiceAccount des Namespace an, anstatt an jedes Deployment:

kubectl get serviceaccount default -n <namespace> -o yaml

Wenn das Secret existiert, der Pull aber immer noch fehlschlägt, bestätigen Sie, dass der Registry-Hostname im Secret genau mit dem Hostnamen im Image-Verweis übereinstimmt. registry.example.com/app:v1 und https://registry.example.com/app:v1 sind nicht derselbe Verweis.

3. Volumenbezogene Probleme

Wenn Ihr Pod einen PersistentVolumeClaim (PVC) benötigt und das entsprechende PersistentVolume (PV) nicht bereitgestellt oder gebunden werden kann, bleibt der Pod Pending.

Diagnoseschritte:

Pod beschreiben: Achten Sie auf Ereignisse im Zusammenhang mit Volumes.
```
kubectl describe pod <pod-name> -n <namespace>
```
Ereignisse können FailedAttachVolume, FailedMount oder ähnliche Meldungen anzeigen.
PVC- und PV-Status überprüfen: Überprüfen Sie den Status des PVC und PV.
```
kubectl get pvc <pvc-name> -n <namespace>
kubectl get pv
```
Achten Sie auf PVCs, die in Pending feststecken, oder PVs, die nicht gebunden sind.

Lösung:

StorageClass sicherstellen: Stellen Sie sicher, dass eine StorageClass definiert und verfügbar ist, insbesondere bei dynamischer Bereitstellung.
PV-Verfügbarkeit prüfen: Stellen Sie bei statischer Bereitstellung sicher, dass das PV existiert und den PVC-Kriterien entspricht.
Zugriffsmodi überprüfen: Stellen Sie sicher, dass die Zugriffsmodi (z. B. ReadWriteOnce, ReadWriteMany) kompatibel sind.

Überprüfen Sie auch, ob der Pod in einer Zone geplant ist, in der das Volume angehängt werden kann. In Cloud-Clustern kann eine in einer Verfügbarkeitszone erstellte Festplatte möglicherweise nicht an einen Knoten in einer anderen Zone angehängt werden. Das Ereignis erwähnt normalerweise Volume-Node-Affinität oder Attach-Fehler. In diesem Fall kann die Lösung Planungsbeschränkungen, eine andere StorageClass oder das Neuerstellen des Volumes in der richtigen Zone sein.

4. Taints, Tolerations und Node Selectors

Ein Pod kann Pending bleiben, selbst wenn der Cluster reichlich CPU und Arbeitsspeicher hat. Der Scheduler muss auch Platzierungsregeln einhalten.

Häufige Beispiele:

Der Pod hat einen nodeSelector, der auf keinen Knoten passt.
Der Pod erfordert eine Node-Affinität, die zu streng ist.
Die einzigen passenden Knoten haben Taints, und der Pod hat keine passende Tolerierung.
Der Namespace hat ein Kontingent, das die angeforderten Ressourcen blockiert.

Überprüfen Sie zuerst die Planungsereignisse:

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

Vergleichen Sie dann die Platzierungsregeln des Pods mit den Knoten-Labels:

kubectl get pod <pod-name> -n <namespace> -o yaml
kubectl get nodes --show-labels
kubectl describe node <node-name>

Wenn das Ereignis besagt, dass ein Taint nicht toleriert wurde, planen Sie den Pod entweder woanders oder fügen Sie eine Tolerierung nur hinzu, wenn diese Workload wirklich zu diesen Knoten gehört. Tolerieren Sie nicht blind jeden Taint. Taints schützen oft spezielle Knoten, GPU-Knoten, Infrastrukturknoten oder Knoten unter Druck.

Fehlerbehebung bei Pods im Status CrashLoopBackOff

Ein CrashLoopBackOff-Status weist auf ein Problem auf Anwendungsebene hin. Der Container wurde erfolgreich gestartet, aber dann mit einem Fehler beendet, was Kubernetes dazu veranlasst, ihn wiederholt neu zu starten.

1. Anwendungsfehler

Die häufigste Ursache ist, dass die Anwendung selbst nicht startet oder kurz nach dem Start einen schwerwiegenden Fehler verursacht.

Häufige Ursachen:

Fehlende Abhängigkeiten/Konfiguration: Die Anwendung findet keine kritischen Konfigurationsdateien, Umgebungsvariablen oder externen Dienste, auf die sie angewiesen ist.
Falscher Befehl/Argumente: Der in der Container-Spezifikation angegebene command oder args ist falsch oder führt zu einem sofortigen Beenden.
Anwendungslogikfehler: Fehler im Anwendungscode, die beim Start zu einem Absturz führen.

Diagnoseschritte:

Pod-Logs anzeigen: Dies ist der wichtigste Schritt. Die Logs zeigen oft die genaue Fehlermeldung, die zum Absturz der Anwendung geführt hat.
```
kubectl logs <pod-name> -n <namespace>
```
Wenn der Pod wiederholt abstürzt, zeigen die Logs möglicherweise die Ausgabe des letzten fehlgeschlagenen Versuchs. Um Logs einer vorherigen Instanz eines abstürzenden Containers anzuzeigen, verwenden Sie das Flag -p (previous):
```
kubectl logs <pod-name> -p -n <namespace>
```
Pod beschreiben: Achten Sie im Abschnitt Containers auf Restart Count, der angibt, wie oft der Container abgestürzt ist. Überprüfen Sie auch Last State auf Exit Code.
```
kubectl describe pod <pod-name> -n <namespace>
```
Ein Exit-Code von 0 bedeutet normalerweise ein ordentliches Herunterfahren, aber jeder Exit-Code ungleich Null bedeutet einen Fehler. Häufige Exit-Codes ungleich Null sind 1 (allgemeiner Fehler), 137 (SIGKILL, oft OOMKilled), 139 (SIGSEGV, Speicherzugriffsfehler).

Lösung:

Anwendungslogs überprüfen: Debuggen Sie basierend auf den Logs Ihren Anwendungscode oder Ihre Konfiguration. Stellen Sie sicher, dass alle erforderlichen Umgebungsvariablen, ConfigMaps und Secrets korrekt eingebunden/injiziert sind.
Lokal testen: Versuchen Sie, das Container-Image lokal mit denselben Umgebungsvariablen und Befehlen auszuführen, um das Problem zu reproduzieren und zu debuggen.

Wenn der Pod mehrere Container hat, geben Sie immer den Containernamen an:

kubectl logs <pod-name> -c <container-name> -n <namespace>
kubectl logs <pod-name> -c <container-name> -p -n <namespace>

Ohne -c lesen Sie möglicherweise die Sidecar-Logs, während die Haupt-App diejenige ist, die abstürzt.

2. Fehlschlagen von Liveness- und Readiness-Probes

Kubernetes verwendet Liveness- und Readiness-Probes, um den Zustand und die Verfügbarkeit Ihrer Anwendung zu bestimmen. Wenn eine Liveness-Probe kontinuierlich fehlschlägt, startet Kubernetes den Container neu, was zu CrashLoopBackOff führt.

Diagnoseschritte:

Pod beschreiben: Überprüfen Sie die Definitionen der Liveness- und Readiness-Probes und deren Last State im Abschnitt Containers.
```
kubectl describe pod <pod-name> -n <namespace>
```
Achten Sie auf Meldungen, die auf Probe-Fehler hinweisen, wie z. B. "Liveness probe failed: HTTP probe failed with statuscode: 500".
Anwendungslogs überprüfen: Manchmal liefern die Anwendungslogs Kontext, warum der Probe-Endpunkt fehlschlägt.

Lösung:

Probe-Konfiguration anpassen: Korrigieren Sie den path, port, command, initialDelaySeconds, periodSeconds oder failureThreshold der Probe.
Zustand des Probe-Endpunkts sicherstellen: Stellen Sie sicher, dass der von der Probe anvisierte Anwendungsendpunkt tatsächlich gesund ist und wie erwartet antwortet. Die Anwendung benötigt möglicherweise zu lange zum Starten, was einen größeren initialDelaySeconds erfordert.

Erwägen Sie für langsam startende Anwendungen eine startupProbe. Sie gibt der Anwendung mehr Zeit zum Initialisieren, bevor die Liveness-Probe sie beurteilt. Dies ist sauberer, als für jeden Neustart einen großen Liveness-initialDelaySeconds festzulegen.

3. Ressourcenlimits überschritten

Wenn ein Container konsequent versucht, mehr Arbeitsspeicher als sein memory.limit zu verwenden oder aufgrund der Überschreitung seines cpu.limit CPU-gedrosselt wird, kann der Kernel den Prozess beenden, oft mit einem OOMKilled-Ereignis (Out Of Memory Killed).

Diagnoseschritte:

Pod beschreiben: Achten Sie im Abschnitt Last State oder Events auf OOMKilled. Ein Exit Code: 137 deutet oft auf ein OOMKilled-Ereignis hin.
```
kubectl describe pod <pod-name> -n <namespace>
```
kubectl top überprüfen: Wenn metrics-server installiert ist, verwenden Sie kubectl top pod, um die tatsächliche Ressourcennutzung Ihrer Pods zu sehen.
```
kubectl top pod <pod-name> -n <namespace>
```

Lösung:

Ressourcenlimits erhöhen: Wenn Ihre Anwendung tatsächlich mehr Ressourcen benötigt, erhöhen Sie die limits für memory und/oder cpu in Ihrem Pod-Manifest. Dies erfordert möglicherweise mehr Kapazität auf Ihren Knoten.
```
resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi" # Dies erhöhen
    cpu: "1000m"   # Dies erhöhen
```
Anwendung optimieren: Profilieren Sie Ihre Anwendung, um ihren Ressourcenverbrauch zu identifizieren und zu reduzieren.

4. Berechtigungsprobleme

Container können abstürzen, wenn ihnen die erforderlichen Berechtigungen für den Zugriff auf Dateien, Verzeichnisse oder Netzwerkressourcen fehlen.

Diagnoseschritte:

Logs überprüfen: Die Anwendungslogs zeigen möglicherweise Fehler wegen fehlender Berechtigungen an (EACCES).
Pod beschreiben: Überprüfen Sie den verwendeten ServiceAccount und alle eingebundenen securityContext-Einstellungen.

Lösung:

securityContext anpassen: Setzen Sie runAsUser, fsGroup oder allowPrivilegeEscalation nach Bedarf.
ServiceAccount-Berechtigungen: Stellen Sie sicher, dass der mit dem Pod verknüpfte ServiceAccount über die erforderlichen Roles und ClusterRoles verfügt, die über RoleBindings und ClusterRoleBindings gebunden sind.
Volume-Berechtigungen: Stellen Sie sicher, dass eingebundene Volumes (z. B. emptyDir, hostPath, ConfigMap, Secret) die korrekten Berechtigungen für den Benutzer des Containers haben.

Ein schneller Entscheidungsbaum

Wenn jemand sagt "der Pod ist kaputt", führen Sie diese in dieser Reihenfolge aus:

kubectl get pod <pod-name> -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --all-containers=true --tail=100
kubectl logs <pod-name> -n <namespace> --all-containers=true -p --tail=100

Verzweigen Sie dann:

Wenn in kubectl get pod -o wide kein Knoten vorhanden ist, konzentrieren Sie sich auf die Planung: requests, taints, affinity, quota und Knotenverfügbarkeit.
Wenn ein Knoten vorhanden ist, das Ereignis aber Image-Pull erwähnt, konzentrieren Sie sich auf Image-Name, Tag, Registry-Auth und Netzwerkzugriff zwischen Knoten und Registry.
Wenn das Ereignis Mount oder Attach erwähnt, konzentrieren Sie sich auf PVCs, PVs, StorageClass, Zugriffsmodi und Zonenplatzierung.
Wenn der Pod startet und dann neu startet, konzentrieren Sie sich auf Logs, Exit-Code, Probes, command/args, config, secrets und Speicherlimits.

Diese Reihenfolge vermeidet einen häufigen Fehler: das Lesen von Anwendungslogs für einen Pod, der nie einen Anwendungscontainer gestartet hat.

Exit-Codes lesen, ohne zu überreagieren

Exit-Codes sind Hinweise, keine vollständigen Erklärungen.

1 bedeutet normalerweise, dass die Anwendung einen allgemeinen Fehler zurückgegeben hat. Die Logs sind wichtiger als die Zahl.
2 kann auf Befehlszeilen-Nutzungsfehler in vielen Programmen hinweisen.
126 bedeutet oft, dass der Befehl existiert, aber nicht ausgeführt werden kann.
127 bedeutet oft, dass der Befehl nicht gefunden wurde.
137 tritt häufig auf, wenn der Prozess SIGKILL erhält; in Kubernetes ist dies oft, aber nicht immer, mit OOMKilled verbunden.
143 bedeutet, dass der Prozess SIGTERM erhalten hat, was während der normalen Beendigung passieren kann.

Wenn der Exit-Code 137 ist, überprüfen Sie den Last State des Pods und die Ereignisse, bevor Sie ein Speicherleck annehmen. Auch ein Node-Drain, eine Eviction oder ein manuelles Kill können einen Container beenden.

Allgemeine Diagnoseschritte und Werkzeuge

Hier ist eine kurze Checkliste mit Befehlen, die Sie ausführen sollten, wenn Sie auf Pod-Probleme stoßen:

Schnelle Übersicht erhalten: Überprüfen Sie den Status Ihrer Pods.

kubectl get pods -n <namespace>
kubectl get pods -n <namespace> -o wide

Detaillierte Pod-Informationen: Der wichtigste Befehl zum Verständnis von Pod-Ereignissen, -Status und -Bedingungen.
```
kubectl describe pod <pod-name> -n <namespace>
```

Container-Logs: Sehen Sie, was Ihre Anwendung meldet.

kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -p -n <namespace> # Vorherige Instanz
kubectl logs <pod-name> -f -n <namespace> # Logs verfolgen

Clusterweite Ereignisse: Manchmal liegt das Problem nicht bei einem bestimmten Pod, sondern bei einem clusterweiten Ereignis (z. B. Knotenauslastung).
```
kubectl get events -n <namespace>
```
Interaktives Debugging: Wenn Ihr Container startet, aber schnell abstürzt, können Sie möglicherweise für einen kurzen Moment mit exec in ihn einsteigen oder in einen separaten Debug-Container, falls konfiguriert.
```
kubectl exec -it <pod-name> -n <namespace> -- bash
```
(Hinweis: Dies funktioniert nur, wenn der Container lange genug am Leben bleibt, um sich zu verbinden.)

Bewährte Methoden zur Vermeidung von Pod-Problemen

Vorbeugung ist besser als Heilung. Die Befolgung dieser bewährten Methoden kann Pending- und CrashLoopBackOff-Vorfälle erheblich reduzieren:

Realistische Ressourcenanforderungen und -limits festlegen: Beginnen Sie mit angemessenen requests und limits und passen Sie sie dann basierend auf Anwendungsprofilierung und -überwachung an.
Spezifische Image-Tags verwenden: Vermeiden Sie latest-Tags in der Produktion. Verwenden Sie unveränderliche Tags (z. B. v1.2.3, commit-sha) für Reproduzierbarkeit.
Robuste Probes implementieren: Konfigurieren Sie liveness- und readiness-Probes, die den Zustand Ihrer Anwendung genau widerspiegeln. Berücksichtigen Sie Startzeiten mit initialDelaySeconds.
Zentralisierte Protokollierung und Überwachung: Verwenden Sie Tools wie Prometheus, Grafana, ELK-Stack oder cloud-native Protokollierungsdienste, um Pod-Logs und -Metriken zu sammeln und zu analysieren.
Versionskontrolle für Manifeste: Speichern Sie Ihre Kubernetes-Manifeste in einem Versionskontrollsystem (z. B. Git), um Änderungen zu verfolgen und Rollbacks zu erleichtern.
Gründliches Testen: Testen Sie Ihre Container-Images und Kubernetes-Bereitstellungen in Entwicklungs- und Staging-Umgebungen, bevor Sie sie in der Produktion bereitstellen.
Ordnungsgemäßes Herunterfahren: Stellen Sie sicher, dass Ihre Anwendungen SIGTERM-Signale für ein ordentliches Herunterfahren verarbeiten, damit sie Ressourcen vor der Beendigung freigeben können.

Was es normalerweise am schnellsten behebt

Für Pending ist kubectl describe pod normalerweise der schnellste Weg, da Scheduler- und Kubelet-Ereignisse erklären, was Kubernetes nicht tun konnte. Für CrashLoopBackOff sind vorherige Logs normalerweise der schnellste Weg, da der aktuelle Container möglicherweise zu neu ist, um den Absturz zu zeigen, der die Schleife verursacht hat.

Nachdem Sie das unmittelbare Problem behoben haben, suchen Sie nach dem Präventionsschritt: richtig dimensionierte requests, bessere Image-Tags, eine startupProbe, eine fehlende Secret-Überprüfung in CI oder ein klareres Runbook. Der beste Pod-Vorfall ist der, der beim nächsten Mal leichter zu erkennen ist.