Die Status-Spalten verstehen — und den ersten kaputten Pod diagnostizieren.
In Lektion 1 hast du kubectl get pods -A gesehen.
Jetzt lernst du, was die Spalten bedeuten — damit du auf einen Blick erkennst, ob alles gesund ist.
get podsNAME READY STATUS RESTARTS AGE
authentik-server-558… 1/1 Running 16 (22m ago) 2d5h| Spalte | Bedeutung |
|---|---|
READY | bereite / gesamte Container im Pod. 1/1 = gut, 0/1 = noch nicht bereit. |
STATUS | Phase des Pods (siehe Tabelle unten). |
RESTARTS | Wie oft ein Container neu gestartet wurde. Hohe Zahl = etwas stimmt nicht. |
AGE | Wie lange der Pod schon existiert. |
1/1 Running mit 16 RESTARTS heißt: läuft jetzt, ist aber schon 16× abgestürzt.
Grün auf den ersten Blick, krank auf den zweiten. RESTARTS ist das Fieberthermometer des Pods.
| Status | Heißt | Dein Verdacht |
|---|---|---|
| Running | Container läuft | Gesund (RESTARTS prüfen!) |
| Pending | Noch nicht platziert | Kein Node-Platz / Ressourcen / Volume |
| ContainerCreating | Wird gerade gestartet | Kurz normal; dauerhaft = Image/Volume |
| CrashLoopBackOff | Startet, stirbt, wartet, wiederholt | App-Fehler → logs |
| ImagePullBackOff | Image nicht ladbar | Falscher Name/Tag oder Registry-Auth |
| OOMKilled | Wegen RAM-Limit getötet | Limit zu klein / Memory-Leak |
| Completed | Sauber beendet | Normal bei Jobs, untypisch bei Apps |
Immer dieselbe Reihenfolge — von außen nach innen:
# 1) Überblick: welcher Pod ist auffällig?
kubectl get pods -n <ns>
# 2) Lupe: scrolle ganz nach unten zu "Events"
kubectl describe pod <name> -n <ns>
# 3) Ins Innere: was sagt die App selbst?
kubectl logs <name> -n <ns>
# 3b) Wenn der Pod gerade neu gestartet ist: Logs des Vorgängers!
kubectl logs <name> -n <ns> --previousdescribe beantwortet „warum kommt der Pod nicht hoch?“ (Scheduling, Image, Mounts — steht in Events).
logs beantwortet „warum stürzt die App ab, nachdem sie startete?“. Bei CrashLoopBackOff ist --previous oft der Schlüssel.
Du hast einen echten Patienten: authentik-server hatte 16 Restarts. Untersuche ihn — alles read-only.
# Finde Pods mit Restarts (in deinem Cluster: ns "authentik")
kubectl get pods -n authentik
# Lupe drauf — lies den Abschnitt "Events" und "Last State"
kubectl describe pod -n authentik -l app.kubernetes.io/name=authentik
# Was sagt die App? (ggf. Pod-Namen aus get einsetzen)
kubectl logs -n authentik <pod-name> --previousFrag dich: War es ein App-Fehler (logs) oder ein Plattform-Problem (Events im describe)?
0/1 Pending. Welcher Befehl bringt dich am schnellsten zur Ursache?CrashLoopBackOff. Wo liegt der Fehler am ehesten?2/3 in der Spalte READY?CrashLoopBackOff und Error?“ oder
„Zeig mir, wie ich gezielt nur kranke Pods finde.“