- Authors

- Name
- Phillip Pham
- @ddppham
Kubernetes Pod Pending - Kompletter Troubleshooting Guide
Ihr Pod hängt im Status Pending und startet nicht? Dieses Problem ist einer der häufigsten Kubernetes-Fehler. In diesem Guide zeigen wir alle Ursachen und die konkreten Lösungen.
TL;DR - Schnelle Diagnose
# Schritt 1: Pod-Status prüfen
kubectl describe pod <pod-name> -n <namespace>
# Schritt 2: Events anschauen (ganz unten in der Ausgabe)
# Dort steht die Ursache!
Die Events-Sektion am Ende von kubectl describe zeigt fast immer die Ursache.
Die 7 häufigsten Ursachen
1. Insufficient CPU/Memory (häufigste Ursache)
Symptom:
Events:
Warning FailedScheduling 0/3 nodes are available:
3 Insufficient cpu, 3 Insufficient memory.
Ursache: Der Pod fordert mehr Ressourcen als verfügbar.
Lösung:
# Option A: Resource Requests reduzieren
spec:
containers:
- name: app
resources:
requests:
cpu: "100m" # Reduziert von z.B. "500m"
memory: "128Mi" # Reduziert von z.B. "512Mi"
limits:
cpu: "200m"
memory: "256Mi"
# Option B: Node-Kapazität prüfen
kubectl describe nodes | grep -A 5 "Allocated resources"
# Option C: Welche Pods verbrauchen am meisten?
kubectl top pods -A --sort-by=cpu
kubectl top pods -A --sort-by=memory
Pro-Tipp: Nutzen Sie requests für Scheduling und limits für Schutz vor Runaway-Prozessen.
2. No Matching Node (nodeSelector/Affinity)
Symptom:
Events:
Warning FailedScheduling 0/3 nodes are available:
3 node(s) didn't match Pod's node affinity/selector.
Ursache: Kein Node hat die geforderten Labels.
Diagnose:
# Welche Labels hat der Pod gefordert?
kubectl get pod <pod-name> -o yaml | grep -A 10 nodeSelector
# Welche Labels haben die Nodes?
kubectl get nodes --show-labels
Lösung:
# Option A: Node labeln
kubectl label nodes <node-name> disktype=ssd
# Option B: nodeSelector im Pod entfernen/anpassen
# Beispiel: Korrekter nodeSelector
spec:
nodeSelector:
disktype: ssd # Dieses Label muss auf einem Node existieren
3. PersistentVolumeClaim Pending
Symptom:
Events:
Warning FailedScheduling 0/3 nodes are available:
3 node(s) had volume node affinity conflict.
Oder der Pod wartet einfach und die PVC ist auch Pending:
kubectl get pvc
# NAME STATUS VOLUME CAPACITY ACCESS MODES
# my-pvc Pending
Diagnose:
# PVC-Status prüfen
kubectl describe pvc <pvc-name>
# StorageClass prüfen
kubectl get storageclass
Häufige Ursachen:
- Keine StorageClass: Keine Default-StorageClass definiert
- WaitForFirstConsumer: StorageClass wartet auf Pod
- Zone Mismatch: PV in anderer Zone als Node
Lösung:
# StorageClass mit WaitForFirstConsumer (empfohlen)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-storage
provisioner: kubernetes.io/aws-ebs
volumeBindingMode: WaitForFirstConsumer # Wichtig!
parameters:
type: gp3
# Default StorageClass setzen
kubectl patch storageclass <name> -p \
'{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
4. Taints und Tolerations
Symptom:
Events:
Warning FailedScheduling 0/3 nodes are available:
3 node(s) had taints that the pod didn't tolerate.
Diagnose:
# Welche Taints haben die Nodes?
kubectl describe nodes | grep Taints
# Beispiel-Output:
# Taints: node-role.kubernetes.io/control-plane:NoSchedule
Lösung:
# Toleration im Pod hinzufügen
spec:
tolerations:
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"
# Oder Taint vom Node entfernen
kubectl taint nodes <node-name> key:NoSchedule-
5. ImagePullBackOff / ErrImagePull
Symptom: Pod ist zwar Pending, aber der Grund ist ein Image-Problem:
Events:
Warning Failed Failed to pull image "myregistry/app:v1":
rpc error: code = Unknown desc = Error response from daemon:
pull access denied
Diagnose:
# Image-Name prüfen
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].image}'
# Secret für Registry prüfen
kubectl get secrets
Lösung:
# Docker Registry Secret erstellen
kubectl create secret docker-registry regcred \
--docker-server=<registry-url> \
--docker-username=<user> \
--docker-password=<password>
# Secret im Pod referenzieren
spec:
imagePullSecrets:
- name: regcred
containers:
- name: app
image: myregistry/app:v1
6. ResourceQuota überschritten
Symptom:
Events:
Warning FailedCreate Error creating: pods "app-xxx" is forbidden:
exceeded quota: compute-resources, requested: cpu=500m,
used: cpu=1900m, limited: cpu=2
Diagnose:
# ResourceQuotas im Namespace anzeigen
kubectl get resourcequota -n <namespace>
kubectl describe resourcequota -n <namespace>
Lösung:
# Option A: Quota erhöhen (wenn berechtigt)
kubectl edit resourcequota <quota-name> -n <namespace>
# Option B: Resource Requests im Pod reduzieren
# Option C: Andere Pods im Namespace reduzieren/löschen
kubectl get pods -n <namespace>
7. LimitRange Verletzung
Symptom:
Events:
Warning FailedCreate Error creating: pods "app-xxx" is forbidden:
minimum cpu usage per Container is 100m, but request is 50m
Diagnose:
# LimitRange prüfen
kubectl get limitrange -n <namespace>
kubectl describe limitrange -n <namespace>
Lösung:
# Pod-Resources an LimitRange anpassen
spec:
containers:
- name: app
resources:
requests:
cpu: "100m" # Mindestens so viel wie LimitRange fordert
memory: "64Mi"
Debugging-Checkliste
# 1. Pod-Details und Events
kubectl describe pod <pod-name> -n <namespace>
# 2. Alle Pods im Namespace
kubectl get pods -n <namespace> -o wide
# 3. Node-Status
kubectl get nodes
kubectl describe nodes
# 4. Cluster-Events (letzte 1 Stunde)
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
# 5. Scheduler-Logs (für tiefe Analyse)
kubectl logs -n kube-system -l component=kube-scheduler
Häufige Fehler nach Komponente
| Komponente | Typischer Fehler | Schnelle Lösung |
|---|---|---|
| Resources | Insufficient CPU/Memory | Requests reduzieren |
| Scheduler | No matching node | Labels/Affinity prüfen |
| Storage | PVC Pending | StorageClass prüfen |
| Network | CNI not ready | CNI Plugin installieren |
| Security | Pod Security Policy | PSP/PSS anpassen |
Automatisierte Diagnose-Skript
#!/bin/bash
# pending-pod-debug.sh
POD=$1
NS=${2:-default}
echo "=== Pod Status ==="
kubectl get pod $POD -n $NS
echo -e "\n=== Pod Events ==="
kubectl get events -n $NS --field-selector involvedObject.name=$POD
echo -e "\n=== Pod Conditions ==="
kubectl get pod $POD -n $NS -o jsonpath='{.status.conditions}' | jq .
echo -e "\n=== Node Resources ==="
kubectl describe nodes | grep -A 5 "Allocated resources"
echo -e "\n=== PVCs im Namespace ==="
kubectl get pvc -n $NS
Speichern und ausführen:
chmod +x pending-pod-debug.sh
./pending-pod-debug.sh my-pod my-namespace
CKA-Prüfungstipp
In der CKA-Prüfung ist Pod Troubleshooting ein wichtiges Thema (30% Gewichtung für Troubleshooting). Merken Sie sich:
- Immer zuerst:
kubectl describe pod - Events lesen: Die Antwort steht fast immer dort
- Node-Kapazität:
kubectl describe nodes - Schnelle Fixes: Resources reduzieren ist oft die Lösung
Mehr zur CKA-Vorbereitung: CKA Zertifizierung Guide
Zusammenfassung
| Problem | Diagnose-Befehl | Häufigste Lösung |
|---|---|---|
| Insufficient Resources | kubectl describe nodes | Requests reduzieren |
| Node Selector | kubectl get nodes --show-labels | Labels hinzufügen |
| PVC Pending | kubectl describe pvc | StorageClass prüfen |
| Taints | kubectl describe nodes | grep Taints | Toleration hinzufügen |
| Image Pull | kubectl describe pod | imagePullSecrets |
| ResourceQuota | kubectl get resourcequota | Quota erhöhen |
Der wichtigste Befehl: kubectl describe pod <name> - Die Events-Sektion zeigt fast immer die Ursache!
Dieser Troubleshooting-Guide wird regelmäßig aktualisiert. Letzte Aktualisierung: Januar 2026.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
CrashLoopBackOff debuggen: Ursachen und Lösungen
Kubernetes CrashLoopBackOff systematisch debuggen: Exit Codes verstehen, die 8 häufigsten Ursachen erkennen und mit kubectl logs und kubectl debug beheben.
CoreDNS Debugging: Kubernetes-DNS Probleme lösen
DNS-Probleme in Kubernetes systematisch debuggen: CoreDNS-Logs, ndots-Konfiguration, NXDOMAIN-Fehler und Corefile-Optimierung für schnellere Auflösung.
Ephemeral Containers: Live-Debugging in Kubernetes
Ephemeral Containers fuer Live-Debugging in Kubernetes nutzen. Mit kubectl debug laufende Pods analysieren, Distroless-Images debuggen und Netzwerkprobleme loesen.
Kubernetes Troubleshooting: Systematisch debuggen
Kubernetes-Probleme systematisch debuggen mit kubectl describe, logs und debug. Lösungen für ImagePullBackOff, CrashLoopBackOff, Pending Pods und DNS-Fehler.
ContainerCreating hängt: Ursachen finden und beheben
Kubernetes Pod bleibt im Status ContainerCreating? Die drei häufigsten Ursachen und Lösungen für Image Pull, Volume Mount und Init Container Probleme.