Lektion 8 — Debug-Werkzeugkasten

Du kennst die Diagnose-Leiter (Lektion 2): get → describe → logs. Jetzt lernst du, was die Befunde bedeuten — eine Landkarte der typischen Krankheiten.

1. Die Fehler-Landkarte

Symptom	Ursache meist	Schnellster Check
ImagePullBackOff	Image-Name/Tag falsch oder Registry-Login fehlt	`describe` → Events
CrashLoopBackOff	App startet, stürzt dann ab	`logs --previous`
Pending	kein Node-Platz / unerfüllbare Requests / Volume fehlt	`describe` → Events
OOMKilled	Memory-Limit zu klein / Leak	`describe` → „Last State“
0/1 Running, nie ready	Readiness-Probe schlägt fehl	`describe` → Conditions/Probe

Symptom

Ursache meist

Schnellster Check

ImagePullBackOff

Image-Name/Tag falsch oder Registry-Login fehlt

describe → Events

CrashLoopBackOff

App startet, stürzt dann ab

logs --previous

Pending

kein Node-Platz / unerfüllbare Requests / Volume fehlt

describe → Events

OOMKilled

Memory-Limit zu klein / Leak

describe → „Last State“

0/1 Running, nie ready

Readiness-Probe schlägt fehl

describe → Conditions/Probe

Eselsbrücke: Pull/Crash trennen

„Image-Probleme stehen in den Events, App-Probleme stehen in den Logs.“ Kommt der Pod gar nicht erst hoch → describe. Kommt er hoch und fällt um → logs.

2. Reingehen, wenn Lesen nicht reicht

# Shell im laufenden Container (z.B. DNS/Dateien prüfen) kubectl exec -it -n lernen deploy/web -- sh # Einzelnen Befehl ausführen, ohne Shell kubectl exec -n lernen deploy/web -- cat /etc/resolv.conf # App testen, ohne sie nach außen zu öffnen kubectl port-forward -n lernen svc/web 8080:80

3. Wenn der Container keine Shell hat

Schlanke Images (z. B. distroless) haben keine sh. Dann hängst du einen Ephemeral Debug Container mit Werkzeugen daneben — ohne den Pod neu zu starten:

Warum das sicher ist

kubectl debug verändert die laufende App nicht — es fügt nur einen temporären Helfer-Container hinzu, der mit verschwindet. Ideal für „warum erreicht der Pod den Service nicht?“.

4. Cluster-weite Sicht

# Alle jüngsten Events, chronologisch (oft die schnellste Spur) kubectl get events -A --sort-by=.lastTimestamp | tail -20 # Ressourcen-Hunger (Node/Pod) — braucht metrics-server kubectl top nodes kubectl top pods -n lernen

5. Der Debug-Entscheidungsbaum

Pod nicht "Running"? ├─ Pending → describe: Scheduling/Requests/Volume ├─ ImagePullBackOff → describe: Image-Name/Tag/Registry └─ ContainerCreating(dauerhaft) → describe: Volume/Secret-Mount Pod "Running" aber Probleme? ├─ CrashLoopBackOff → logs --previous ├─ 0/1 ready → describe: Readiness-Probe └─ OOMKilled → describe "Last State" → Limit erhöhen

Selbsttest

1. ImagePullBackOff — wo findest du die Ursache am schnellsten?

2. Der Container ist distroless und hat keine Shell. Was tust du?

3. Ein Pod ist OOMKilled. Was ist die typische Ursache?

Frag deinen Lehrer: „Mein Pod hängt in Pending — gehen wir es zusammen durch?“, „Wie lese ich eine Readiness-Probe im describe?“ oder „Was zeigt kubectl top genau?“