Einen Cluster lesen und verstehen — ohne irgendetwas anzufassen.
Du hast einen echten Cluster (admin@homelab-kube) und willst beruflich,
für die Zertifizierung und dein Homelab fit werden. Erste Regel für all das:
Bevor du etwas änderst, musst du sehen können, was da ist.
Diese Lektion gibt dir genau das — und alle Befehle hier sind read-only:
Du kannst damit nichts kaputtmachen.
Kubernetes funktioniert nicht wie ein Server, dem du Befehle gibst ("starte das, stoppe jenes"). Du beschreibst stattdessen einen Soll-Zustand ("ich will 3 Kopien dieser App"), und der Cluster vergleicht ihn unermüdlich mit dem Ist-Zustand und gleicht ihn an. Das nennt man Reconciliation.
Deshalb ist die wichtigste Frage beim Debuggen nie „was tut das Programm?“, sondern: „Wo weicht der Ist-Zustand vom Soll-Zustand ab — und warum?“
kubectlFast jeder kubectl-Befehl ist ein einfacher Satz:
kubectl <VERB> <RESSOURCE> <NAME> [flags]
kubectl get pods web-1 -o wideLässt du den Namen weg, bekommst du nicht „alle“ Pods, sondern nur die im
aktuellen Namespace (standardmäßig default). Ist der leer, siehst du
No resources found in default namespace. — der Namespace existiert, er ist nur leer.
Erst -A (alle Namespaces) zeigt dir wirklich alles im Cluster:
kubectl get pods # nur Namespace "default" (evtl. leer)
kubectl get pods -A # ALLE NamespacesDiese vier ändern nichts am Cluster. Mit ihnen darfst du frei herumstöbern. Sie bauen aufeinander auf — von der Vogelperspektive bis tief ins Innere:
| Verb | Sicht | Beantwortet |
|---|---|---|
get | Vogelperspektive | Was existiert? Welcher Status? |
describe | Lupe + Events | Warum hängt/crasht es? (Events!) |
logs | Ins Innere hören | Was sagt die App selbst? |
explain | Wörterbuch | Welche Felder hat dieses Objekt? |
Beim Debuggen kletterst du diese Leiter von außen nach innen hoch:
get → describe → logs — Liste, dann Events (Lupe),
dann die App-Ausgabe (Innere). explain ist dein Wörterbuch fürs spätere YAML-Schreiben.
get, describe, logs und explain lesen nur.
Gefährlich werden erst Verben wie delete, apply, edit oder scale —
die kommen in späteren Lektionen, mit Sicherheitsnetz (--dry-run).
Der häufigste Profi-Unfall: einen Befehl auf dem falschen Cluster absetzen (Produktion statt Test). Mach es dir zur Gewohnheit, vor jeder Aktion deinen Kontext zu prüfen:
# Auf welchem Cluster/Kontext bin ich gerade?
kubectl config current-context
# Alle verfügbaren Kontexte (der mit * ist aktiv)
kubectl config get-contextsKontext prüfen ist beim Cluster wie der Schulterblick beim Spurwechsel — kostet eine Sekunde, verhindert, dass du einen Befehl versehentlich auf der Produktion absetzt.
Tipp diese Befehle der Reihe nach. Alle sind read-only — nichts kann passieren.
# 1) Wo bin ich? (immer zuerst)
kubectl config current-context
# 2) Vogelperspektive: die Maschinen des Clusters
kubectl get nodes
# 3) Alle Pods, über ALLE Namespaces (-A)
kubectl get pods -A
# 4) Lupe auf einen Node — scrolle runter zu "Events"
kubectl describe node <node-name-aus-schritt-2>
# 5) Wörterbuch: welche Felder hat ein Pod?
kubectl explain pod
# 6) Mehr Spalten zu den System-Pods
kubectl get pods -n kube-system -o wide-A = Alle Namespaces · -n <name> = ein bestimmter
Namespace · -o wide = mehr Spalten (output).
Aus dem Gedächtnis — nicht hochscrollen. Aktives Abrufen ist das, was hängenbleibt.
get pods?“ oder
„Zeig mir das an einem echten kaputten Pod.“