Veröffentlicht am

Kubernetes Pod Pending lösen: Ursachen und Fixes

Teilen:
Authors

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:

  1. Keine StorageClass: Keine Default-StorageClass definiert
  2. WaitForFirstConsumer: StorageClass wartet auf Pod
  3. 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

KomponenteTypischer FehlerSchnelle Lösung
ResourcesInsufficient CPU/MemoryRequests reduzieren
SchedulerNo matching nodeLabels/Affinity prüfen
StoragePVC PendingStorageClass prüfen
NetworkCNI not readyCNI Plugin installieren
SecurityPod Security PolicyPSP/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:

  1. Immer zuerst: kubectl describe pod
  2. Events lesen: Die Antwort steht fast immer dort
  3. Node-Kapazität: kubectl describe nodes
  4. Schnelle Fixes: Resources reduzieren ist oft die Lösung

Mehr zur CKA-Vorbereitung: CKA Zertifizierung Guide


Zusammenfassung

ProblemDiagnose-BefehlHäufigste Lösung
Insufficient Resourceskubectl describe nodesRequests reduzieren
Node Selectorkubectl get nodes --show-labelsLabels hinzufügen
PVC Pendingkubectl describe pvcStorageClass prüfen
Taintskubectl describe nodes | grep TaintsToleration hinzufügen
Image Pullkubectl describe podimagePullSecrets
ResourceQuotakubectl get resourcequotaQuota 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