Kommandoreferenz: Kubernetes

Stand: 13. Juni 2026
Zielgruppe: Kubernetes-Workshop, Betrieb, Troubleshooting, Reviews und Abschlussprojekte

Diese Referenz sammelt die wichtigsten Kubernetes-Kommandos und beschreibt, wann du sie verwendest, welche Ausgabe du erwarten kannst und worauf du achten musst. Der Schwerpunkt liegt auf kubectl, kubeadm und den Werkzeugen, die du im realen Betrieb um Kubernetes herum regelmäßig brauchst: kubelet, Control-Plane-Binaries, crictl, ctr, nerdctl, etcdctl, etcdutl, Helm, Kustomize, CNI-Tools, Cluster-Tools und Linux-Hilfsbefehle.

Wichtig: Kubernetes-Kommandos sind stark versions-, Distributions-, Cloud- und Add-on-abhängig. Diese Datei ist deshalb als ausführliche Workshop- und Betriebsreferenz aufgebaut. Die vollständige Flag-Referenz einer konkreten Installation prüfst du immer zusätzlich mit <kommando> --help, <kommando> <unterkommando> --help und der Dokumentation deiner Kubernetes-Version.

1. Grundregeln für sicheres Arbeiten

Kubernetes-Kommandos wirken oft unmittelbar auf produktive Workloads. Arbeite deshalb mit klarer Reihenfolge:

Kontext prüfen: Du prüfst zuerst Cluster, Namespace und Identität.
Lesen vor Schreiben: Du verwendest zuerst get, describe, diff, dry-run und auth can-i.
Änderung begrenzen: Du arbeitest mit Namespace, Label-Selector oder konkretem Objekt statt mit -A oder --all.
Auswirkung verstehen: Du bewertest, ob ein Kommando Pods neu startet, Traffic umleitet, Daten löscht oder Nodes entleert.
Rollback vorbereiten: Du sicherst vorher Manifest, Werte, Revision, Backup oder Snapshot.
Nachher validieren: Du prüfst Status, Events, Logs, Endpoints und Metriken.

Gefährliche Kommandoklassen

Kommandoklasse	Risiko	Sicherer Umgang
`kubectl delete`	Entfernt Ressourcen oder löst Re-Creation aus.	Erst `kubectl get`, dann gezielt löschen. Keine unkontrollierten Wildcards.
`kubectl replace --force`	Löscht und erstellt neu. Das verursacht Downtime.	Nur verwenden, wenn du den Re-Creation-Effekt willst.
`kubectl drain`	Evicted Pods auf einem Node.	PDBs, DaemonSets, lokale Daten und Kapazität prüfen.
`kubeadm reset`	Entfernt lokale Cluster-Artefakte eines Nodes.	Nur auf dem richtigen Host ausführen. Danach CNI-, iptables- und Datenreste prüfen.
`etcdctl snapshot restore` / `etcdutl snapshot restore`	Erzeugt einen neuen logischen etcd-Clusterzustand.	Nur nach dokumentiertem Restore-Plan und Backup verwenden.
`kubectl patch`	Kann Felder unbemerkt überschreiben.	Patch klein halten und Ergebnis mit `get -o yaml` prüfen.
`kubectl apply --prune`	Kann nicht mehr deklarierte Ressourcen entfernen.	Nur mit engem Selector und Testumgebung einsetzen.

2. Notation und Platzhalter

In dieser Datei werden Platzhalter einheitlich verwendet:

Platzhalter	Bedeutung	Beispiel
`<namespace>`	Namespace	`demo`
`<pod>`	Pod-Name	`web-785d9c9d8f-abc12`
`<deployment>`	Deployment-Name	`web`
`<service>`	Service-Name	`web`
`<node>`	Node-Name	`worker-01`
`<container>`	Container-Name in einem Pod	`app`
`<context>`	kubeconfig-Kontext	`dev-cluster`
`<image>`	Container-Image	`ghcr.io/example/app:1.2.3`
`<file>`	Manifest, Values-Datei oder Snapshot	`deployment.yaml`

Konventionen:

# Namespace explizit setzen
kubectl get pods -n <namespace>

# Alle Namespaces anzeigen
kubectl get pods -A
kubectl get pods --all-namespaces

# Kurze Schreibweise für Ressourcentypen
kubectl get po,svc,deploy -n <namespace>

# Lange Schreibweise ist in Dokumentation und Workshops oft besser lesbar
kubectl get pods,services,deployments -n <namespace>

3. Shell, Autocomplete und Aliasse

Versionen prüfen

kubectl version --client
kubectl version
kubectl version -o yaml
kubeadm version
helm version
crictl --version
ctr version
etcdctl version

kubectl version --client prüft nur dein lokales CLI. kubectl version spricht zusätzlich mit dem API Server. Wenn du keinen Zugriff hast, siehst du hier Authentifizierungs-, Netzwerk- oder Zertifikatsfehler.

Autocomplete für Bash

source <(kubectl completion bash)
echo 'source <(kubectl completion bash)' >> ~/.bashrc

alias k=kubectl
complete -o default -F __start_kubectl k

Autocomplete für Zsh

source <(kubectl completion zsh)
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc

Autocomplete für Fish

mkdir -p ~/.config/fish/completions
kubectl completion fish > ~/.config/fish/completions/kubectl.fish

Nützliche Aliasse

alias k='kubectl'
alias kgp='kubectl get pods'
alias kgn='kubectl get nodes -o wide'
alias kga='kubectl get all'
alias kaf='kubectl apply -f'
alias kdf='kubectl diff -f'
alias kdel='kubectl delete'
alias kctx='kubectl config current-context'
alias kns='kubectl config set-context --current --namespace'

Verwende Aliasse nur interaktiv. In Dokumentation, Runbooks und CI-Pipelines sind ausgeschriebene Kommandos robuster.

4. kubectl: Syntax und globale Optionen

kubectl ist das Standard-CLI für die Kommunikation mit der Kubernetes Control Plane. Die Grundform lautet:

kubectl [global options] <verb> <resource> [name] [flags]

Beispiele:

kubectl get pods -n demo
kubectl describe deployment web -n demo
kubectl apply -f deployment.yaml
kubectl delete service web -n demo

Globale Optionen

Option	Zweck	Beispiel
`--kubeconfig <file>`	Nutzt eine bestimmte kubeconfig-Datei.	`kubectl --kubeconfig ./kubeconfig get nodes`
`--context <context>`	Nutzt einen bestimmten Kontext.	`kubectl --context prod get pods -A`
`-n`, `--namespace`	Setzt den Namespace für namespaced Ressourcen.	`kubectl get pods -n demo`
`-A`, `--all-namespaces`	Zeigt Ressourcen in allen Namespaces.	`kubectl get pods -A`
`-o <format>`	Ausgabeformat.	`kubectl get pods -o wide`
`-l`, `--selector`	Filtert per Label-Selector.	`kubectl get pods -l app=web`
`--field-selector`	Filtert per Feld.	`kubectl get pods --field-selector=status.phase=Pending`
`--as <user>`	Impersonation als Benutzer.	`kubectl auth can-i get pods --as alice`
`--as-group <group>`	Impersonation als Gruppe.	`kubectl auth can-i list pods --as-group devs`
`--request-timeout <dauer>`	Timeout für API-Anfragen.	`kubectl get pods --request-timeout=10s`
`--v <level>`	Erhöht Verbosity für Debugging.	`kubectl get pods --v=8`
`--dry-run=client`	Validiert/generiert lokal ohne API-Persistenz.	`kubectl create ns demo --dry-run=client -o yaml`
`--dry-run=server`	Validiert über den API Server, inklusive Admission.	`kubectl apply --dry-run=server -f app.yaml`

Ausgabeformate

kubectl get pods -o wide
kubectl get pods -o yaml
kubectl get pods -o json
kubectl get pods -o name
kubectl get pods -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase'
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

Typische Ressourcenkurzformen

Kurzform	Langform
`po`	`pods`
`svc`	`services`
`deploy`	`deployments`
`rs`	`replicasets`
`sts`	`statefulsets`
`ds`	`daemonsets`
`cm`	`configmaps`
`sa`	`serviceaccounts`
`ns`	`namespaces`
`ep`	`endpoints`
`pvc`	`persistentvolumeclaims`
`pv`	`persistentvolumes`
`sc`	`storageclasses`
`ing`	`ingresses`
`netpol`	`networkpolicies`
`cj`	`cronjobs`

5. kubeconfig, Kontext und Zugriff

Aktuellen Kontext prüfen

kubectl config current-context
kubectl config get-contexts
kubectl cluster-info
kubectl get nodes -o wide

Du führst diese Kommandos vor jeder Änderung aus. Ein falscher Kontext ist einer der häufigsten Betriebsfehler.

Kontext wechseln

kubectl config use-context <context>
kubectl config current-context

Namespace im aktuellen Kontext setzen

kubectl config set-context --current --namespace=<namespace>
kubectl config view --minify | grep namespace

Das ist komfortabel, kann aber gefährlich sein. In Runbooks ist -n <namespace> expliziter.

kubeconfig anzeigen und prüfen

kubectl config view
kubectl config view --raw
kubectl config view --minify
kubectl config get-clusters
kubectl config get-users
kubectl config get-contexts

--raw kann sensible Daten wie Zertifikate oder Tokens ausgeben. Teile diese Ausgabe nicht ungeprüft.

Cluster, User und Kontext setzen

kubectl config set-cluster <cluster> --server=https://<api-server>:6443 --certificate-authority=<ca.crt>
kubectl config set-credentials <user> --client-certificate=<user.crt> --client-key=<user.key>
kubectl config set-context <context> --cluster=<cluster> --user=<user> --namespace=<namespace>
kubectl config use-context <context>

Kontext umbenennen oder löschen

kubectl config rename-context <old-context> <new-context>
kubectl config delete-context <context>
kubectl config delete-cluster <cluster>
kubectl config delete-user <user>

Temporäre kubeconfig verwenden

KUBECONFIG=./kubeconfig kubectl get nodes
kubectl --kubeconfig ./kubeconfig get pods -A

Mehrere kubeconfig-Dateien zusammenführen

export KUBECONFIG=$HOME/.kube/config:./cluster-a.yaml:./cluster-b.yaml
kubectl config view --merge --flatten > ./merged-kubeconfig.yaml

6. API-Erkundung und Ressourcenmodell

API-Versionen und Ressourcen anzeigen

kubectl api-versions
kubectl api-resources
kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
kubectl api-resources --verbs=list
kubectl api-resources --api-group=apps
kubectl api-resources -o wide

Damit erkennst du, welche Ressourcentypen im Cluster verfügbar sind. CRDs von Add-ons erscheinen ebenfalls hier.

Ressourcenschema erklären

kubectl explain pod
kubectl explain pod.spec
kubectl explain pod.spec.containers
kubectl explain deployment.spec.strategy
kubectl explain networkpolicy.spec.ingress
kubectl explain gateway.spec.listeners
kubectl explain --recursive deployment.spec.template.spec

kubectl explain ist die schnellste Methode, um Felder direkt aus dem API-Schema zu verstehen.

API-Rohzugriff

kubectl get --raw /api
kubectl get --raw /apis
kubectl get --raw /version
kubectl get --raw /healthz
kubectl get --raw /readyz?verbose
kubectl get --raw /livez?verbose
kubectl get --raw /metrics | head

/metrics, /readyz und /livez können abhängig von RBAC und API-Server-Konfiguration geschützt sein.

Subresources

Einige Ressourcen besitzen Subresources wie status, scale oder versionsabhängig resize.

kubectl get deployment web -n demo --subresource=scale -o yaml
kubectl patch deployment web -n demo --subresource=scale --type=merge -p '{"spec":{"replicas":3}}'
kubectl get pod <pod> -n demo --subresource=status -o yaml

Nutze Subresources gezielt, wenn du nur Status, Skalierung oder ein spezielles Teilobjekt bearbeiten willst.

7. Ressourcen anzeigen, filtern und formatieren

Grundkommandos

kubectl get namespaces
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get all -n <namespace>
kubectl get deployments,replicasets,pods -n <namespace>
kubectl get services,endpoints,endpointslices -n <namespace>
kubectl describe pod <pod> -n <namespace>
kubectl describe node <node>

Watch-Modus

kubectl get pods -n <namespace> -w
kubectl get events -n <namespace> --watch
watch -n 2 'kubectl get pods -n <namespace>'

kubectl -w folgt API-Events. watch ruft ein Kommando wiederholt auf und ist nützlich, wenn du mehrere Objekttypen zusammen anzeigen willst.

Label-Selector

kubectl get pods -n demo -l app=web
kubectl get pods -n demo -l 'app in (web,api)'
kubectl get pods -n demo -l 'app=web,environment=dev'
kubectl get pods -A -l 'app.kubernetes.io/name=nginx'

Field-Selector

kubectl get pods -A --field-selector=status.phase=Pending
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --field-selector=type=Warning
kubectl get pods -A --field-selector=spec.nodeName=<node>

Field-Selectoren sind begrenzter als Label-Selectoren, aber für Status- und Node-bezogene Abfragen sehr hilfreich.

Sortieren

kubectl get pods -A --sort-by=.metadata.creationTimestamp
kubectl get events -A --sort-by=.lastTimestamp
kubectl get pv --sort-by=.spec.capacity.storage
kubectl get pods -A --sort-by=.status.containerStatuses[0].restartCount

Ausgabe als Namen

kubectl get pods -n demo -o name
kubectl get deploy -n demo -o name
kubectl get pods -n demo -l app=web -o name | xargs -r -n1 kubectl describe -n demo

YAML und JSON gezielt speichern

kubectl get deployment web -n demo -o yaml > deployment.web.yaml
kubectl get service web -n demo -o json > service.web.json

Mehrere Ressourcen kombiniert prüfen

kubectl get deploy,rs,po,svc,ep,endpointslice -n demo -o wide
kubectl get ingress,svc,ep,endpointslice -n demo -o wide
kubectl get pvc,pv,storageclass -A

8. Ressourcen erstellen, anwenden und validieren

Deklarativ mit apply

kubectl apply -f manifest.yaml
kubectl apply -f ./manifests/
kubectl apply -f https://example.invalid/manifest.yaml
kubectl apply -k overlays/dev

apply ist Standard für deklarative Arbeit. Die Manifestdatei bleibt der autoritative Zielzustand.

Server-Side Dry Run

kubectl apply --dry-run=server -f manifest.yaml
kubectl apply --dry-run=server -k overlays/dev

Server-Side Dry Run validiert gegen den API Server und berücksichtigt Admission Controller. Das ist aussagekräftiger als rein lokale YAML-Prüfung.

Client-Side Dry Run und YAML-Generierung

kubectl create namespace demo --dry-run=client -o yaml
kubectl create deployment web --image=nginx:1.27 --replicas=2 --dry-run=client -o yaml
kubectl create service clusterip web --tcp=80:8080 --dry-run=client -o yaml
kubectl run debug --image=busybox --restart=Never --dry-run=client -o yaml -- sleep 3600

Diese Form nutzt du, um Startmanifeste zu erzeugen und danach sauber zu versionieren.

Diff vor Änderung

kubectl diff -f manifest.yaml
kubectl diff -k overlays/dev
kubectl diff -f ./manifests/ --server-side

diff zeigt dir, welche Felder sich im Cluster ändern würden.

Server-Side Apply

kubectl apply --server-side -f manifest.yaml
kubectl apply --server-side --field-manager=workshop -f manifest.yaml
kubectl apply --server-side --force-conflicts -f manifest.yaml

Server-Side Apply ist hilfreich, wenn mehrere Controller oder Teams Felder verwalten. --force-conflicts nur verwenden, wenn du bewusst Feldbesitz überschreiben willst.

Replace

kubectl replace -f manifest.yaml
kubectl replace --force -f manifest.yaml

replace ersetzt die Ressource anhand des gelieferten Objekts. replace --force löscht und erstellt neu; das kann Downtime verursachen.

Validierung mit Schema und Admission

kubectl apply --dry-run=server -f manifest.yaml
kubectl explain deployment.spec.template.spec.containers.resources
kubectl get events -n demo --sort-by=.lastTimestamp

Wenn Admission Controller wie Policy Engines aktiv sind, kann ein Manifest syntaktisch korrekt sein und trotzdem abgelehnt werden.

9. Ressourcen ändern: edit, patch, label, annotate und set

Interaktiv editieren

kubectl edit deployment web -n demo
kubectl edit service web -n demo
kubectl edit configmap app-config -n demo
kubectl edit node <node>

edit ist für Notfälle nützlich, aber schlecht reproduzierbar. Übertrage dauerhafte Änderungen anschließend in dein Git-Repository.

Patch mit Merge Patch

kubectl patch deployment web -n demo --type=merge -p '{"spec":{"replicas":3}}'
kubectl patch service web -n demo --type=merge -p '{"spec":{"type":"ClusterIP"}}'

Patch mit JSON Patch

kubectl patch deployment web -n demo --type=json -p='[
  {"op":"replace","path":"/spec/replicas","value":3}
]'

JSON Patch ist präzise, aber empfindlich gegenüber Pfaden.

Patch einer Annotation

kubectl patch deployment web -n demo --type=merge -p '{
  "metadata": {
    "annotations": {
      "workshop.example/change-reason": "manual-test"
    }
  }
}'

Labels setzen und entfernen

kubectl label namespace demo environment=dev
kubectl label pod <pod> -n demo debug=true
kubectl label deployment web -n demo app.kubernetes.io/version=1.2.3 --overwrite
kubectl label namespace demo environment-

Labels steuern Selektoren, Policies, Metrikaggregation und häufig auch GitOps-/Deployment-Logik. Ändere sie kontrolliert.

Annotationen setzen und entfernen

kubectl annotate deployment web -n demo kubernetes.io/change-cause='image update to 1.2.3'
kubectl annotate pod <pod> -n demo workshop.example/owner='team-a' --overwrite
kubectl annotate deployment web -n demo kubernetes.io/change-cause-

Images ändern

kubectl set image deployment/web app=<image> -n demo
kubectl set image deployment/web app=ghcr.io/example/app:1.2.3 -n demo --record=false
kubectl set image daemonset/node-agent agent=ghcr.io/example/agent:2.0.0 -n kube-system

Umgebungsvariablen ändern

kubectl set env deployment/web LOG_LEVEL=debug -n demo
kubectl set env deployment/web LOG_LEVEL- -n demo
kubectl set env deployment/web --from=configmap/app-config -n demo
kubectl set env deployment/web --list -n demo

Ressourcen ändern

kubectl set resources deployment/web -n demo --requests=cpu=100m,memory=128Mi --limits=cpu=500m,memory=512Mi
kubectl set resources deployment/web -n demo -c app --requests=cpu=200m,memory=256Mi

ServiceAccount setzen

kubectl set serviceaccount deployment/web app-sa -n demo

Selector setzen

kubectl set selector service/web app=web -n demo

Bei Selektoren musst du besonders vorsichtig sein. Ein falscher Service-Selector führt schnell zu Services ohne Endpoints oder zu Traffic auf falsche Pods.

10. Ressourcen löschen, warten und aufräumen

Gezielt löschen

kubectl delete pod <pod> -n demo
kubectl delete deployment web -n demo
kubectl delete service web -n demo
kubectl delete -f manifest.yaml
kubectl delete -k overlays/dev

Per Label löschen

kubectl delete pods -n demo -l app=web
kubectl delete jobs -n demo -l cleanup=true

Alle Ressourcen eines Typs löschen

kubectl delete pods --all -n demo
kubectl delete jobs --all -n demo

Verwende --all nur in bewusst abgegrenzten Namespaces.

Grace Period und Force Delete

kubectl delete pod <pod> -n demo --grace-period=30
kubectl delete pod <pod> -n demo --grace-period=0 --force

--force entfernt das API-Objekt aggressiv. Das bedeutet nicht automatisch, dass der Prozess auf dem Node sauber beendet wurde.

Finalizer prüfen und entfernen

kubectl get <resource> <name> -n demo -o jsonpath='{.metadata.finalizers}'
kubectl patch <resource> <name> -n demo --type=merge -p '{"metadata":{"finalizers":null}}'

Finalizer nur entfernen, wenn du verstanden hast, welcher Controller die Ressource blockiert. Sonst bleiben externe Artefakte zurück.

Auf Zustand warten

kubectl wait --for=condition=Available deployment/web -n demo --timeout=120s
kubectl wait --for=condition=Ready pod/<pod> -n demo --timeout=60s
kubectl wait --for=delete pod/<pod> -n demo --timeout=60s
kubectl wait --for=jsonpath='{.status.phase}'=Running pod/<pod> -n demo --timeout=60s

Prune vorsichtig verwenden

kubectl apply -f ./manifests/ --prune -l app.kubernetes.io/part-of=demo

--prune kann Ressourcen löschen, die nicht mehr im angewendeten Set enthalten sind. Nutze einen engen, eindeutigen Label-Selector.

11. Pods

Pods anzeigen

kubectl get pods -n demo
kubectl get pods -n demo -o wide
kubectl get pod <pod> -n demo -o yaml
kubectl describe pod <pod> -n demo

Pods nach Status finden

kubectl get pods -A --field-selector=status.phase=Pending
kubectl get pods -A --field-selector=status.phase=Failed
kubectl get pods -A --field-selector=status.phase=Succeeded
kubectl get pods -A --field-selector=spec.nodeName=<node>

Container eines Pods anzeigen

kubectl get pod <pod> -n demo -o jsonpath='{.spec.containers[*].name}'
kubectl get pod <pod> -n demo -o jsonpath='{.spec.initContainers[*].name}'
kubectl get pod <pod> -n demo -o jsonpath='{.status.containerStatuses[*].restartCount}'

Temporären Pod starten

kubectl run tmp-shell -n demo --rm -it --image=busybox:1.36 --restart=Never -- sh
kubectl run curl -n demo --rm -it --image=curlimages/curl:8.8.0 --restart=Never -- sh
kubectl run dns-test -n demo --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default.svc.cluster.local

Pod-Manifest generieren

kubectl run app -n demo --image=nginx:1.27 --restart=Never --dry-run=client -o yaml > pod.yaml

Pod löschen, damit Controller neu erstellt

kubectl delete pod <pod> -n demo
kubectl get replicaset,deployment -n demo

Wenn der Pod von einem Deployment, ReplicaSet, StatefulSet oder DaemonSet verwaltet wird, erstellt der Controller meist Ersatz. Wenn der Pod manuell erstellt wurde, ist er danach weg.

12. Deployments, ReplicaSets und Rollouts

Deployment erstellen

kubectl create deployment web -n demo --image=nginx:1.27 --replicas=2
kubectl create deployment web -n demo --image=nginx:1.27 --replicas=2 --dry-run=client -o yaml > deployment.yaml

Deployment prüfen

kubectl get deployment web -n demo
kubectl describe deployment web -n demo
kubectl get replicaset -n demo -l app=web
kubectl get pods -n demo -l app=web -o wide

Rollout starten und beobachten

kubectl set image deployment/web nginx=nginx:1.28 -n demo
kubectl rollout status deployment/web -n demo --timeout=120s
kubectl rollout history deployment/web -n demo

Rollout-Historie und Revision prüfen

kubectl rollout history deployment/web -n demo
kubectl rollout history deployment/web -n demo --revision=2
kubectl describe deployment web -n demo

Rollback

kubectl rollout undo deployment/web -n demo
kubectl rollout undo deployment/web -n demo --to-revision=2
kubectl rollout status deployment/web -n demo

Rollout pausieren und fortsetzen

kubectl rollout pause deployment/web -n demo
kubectl set image deployment/web app=ghcr.io/example/app:1.2.4 -n demo
kubectl set env deployment/web FEATURE_X=true -n demo
kubectl rollout resume deployment/web -n demo
kubectl rollout status deployment/web -n demo

Deployment neu starten

kubectl rollout restart deployment/web -n demo
kubectl rollout status deployment/web -n demo

rollout restart setzt eine Annotation im Pod-Template und erzeugt dadurch neue Pods.

ReplicaSets prüfen

kubectl get rs -n demo
kubectl describe rs <replicaset> -n demo
kubectl get pods -n demo --show-labels

ReplicaSets werden normalerweise nicht direkt geändert. Du änderst das Deployment.

13. StatefulSets, DaemonSets, Jobs und CronJobs

StatefulSets

kubectl get statefulsets -n demo
kubectl describe statefulset db -n demo
kubectl rollout status statefulset/db -n demo
kubectl rollout restart statefulset/db -n demo
kubectl scale statefulset/db -n demo --replicas=3
kubectl get pods -n demo -l app=db -o wide
kubectl get pvc -n demo -l app=db

StatefulSets erzeugen stabile Pod-Namen und nutzen häufig PVCs. Beim Löschen des StatefulSets bleiben PVCs je nach Storage-Policy bestehen.

DaemonSets

kubectl get daemonsets -A
kubectl describe daemonset <daemonset> -n <namespace>
kubectl rollout status daemonset/<daemonset> -n <namespace>
kubectl rollout restart daemonset/<daemonset> -n <namespace>
kubectl get pods -n <namespace> -l <label-key>=<label-value> -o wide

DaemonSets laufen typischerweise für Node-nahe Agenten: CNI, CSI, Logging, Monitoring, Security.

Jobs

kubectl create job migrate -n demo --image=ghcr.io/example/app:1.2.3 -- ./migrate.sh
kubectl create job migrate -n demo --image=ghcr.io/example/app:1.2.3 --dry-run=client -o yaml > job.yaml
kubectl get jobs -n demo
kubectl describe job migrate -n demo
kubectl logs job/migrate -n demo
kubectl delete job migrate -n demo

Job aus CronJob erzeugen

kubectl create job manual-backup -n demo --from=cronjob/backup
kubectl logs job/manual-backup -n demo

CronJobs

kubectl create cronjob backup -n demo --image=busybox:1.36 --schedule='*/15 * * * *' -- /bin/sh -c 'date; echo backup'
kubectl get cronjobs -n demo
kubectl describe cronjob backup -n demo
kubectl get jobs -n demo --sort-by=.metadata.creationTimestamp
kubectl delete cronjob backup -n demo

Fehlgeschlagene Jobs bereinigen

kubectl get jobs -n demo
kubectl delete job -n demo --field-selector=status.successful=1
kubectl delete job -n demo -l cleanup=true

14. Skalierung, Autoscaling und Verfügbarkeit

Manuell skalieren

kubectl scale deployment/web -n demo --replicas=3
kubectl scale statefulset/db -n demo --replicas=3
kubectl get deployment web -n demo

HorizontalPodAutoscaler erzeugen

kubectl autoscale deployment web -n demo --min=2 --max=10 --cpu-percent=70
kubectl get hpa -n demo
kubectl describe hpa web -n demo

HPA benötigt Metriken, meistens über den Metrics Server. Ohne Metriken bleibt der HPA wirkungslos oder zeigt Fehler.

HPA prüfen

kubectl get hpa -A
kubectl describe hpa <hpa> -n <namespace>
kubectl top pods -n <namespace>
kubectl top pods -n <namespace> --containers

PodDisruptionBudget

kubectl get poddisruptionbudgets -A
kubectl describe pdb web -n demo
kubectl create poddisruptionbudget web -n demo --selector=app=web --min-available=1 --dry-run=client -o yaml

PDBs schützen gegen freiwillige Unterbrechungen, etwa bei kubectl drain. Sie verhindern keine Node-Ausfälle.

Availability eines Deployments prüfen

kubectl get deployment web -n demo -o jsonpath='{.status.availableReplicas}'
kubectl get deployment web -n demo -o jsonpath='{.status.conditions}'
kubectl describe deployment web -n demo

15. Logs, Exec, Attach, Copy und Debug

Logs anzeigen

kubectl logs pod/<pod> -n demo
kubectl logs pod/<pod> -n demo -c <container>
kubectl logs pod/<pod> -n demo --all-containers
kubectl logs deployment/web -n demo
kubectl logs deployment/web -n demo --tail=100
kubectl logs deployment/web -n demo --since=10m
kubectl logs deployment/web -n demo -f
kubectl logs pod/<pod> -n demo -c <container> --previous

--previous ist wichtig bei CrashLoopBackOff, weil der aktuelle Container oft sofort wieder beendet wird.

Logs per Label

kubectl logs -n demo -l app=web --all-containers=true --tail=100
kubectl logs -n demo -l app=web --prefix=true --since=30m

Exec in Container

kubectl exec -it pod/<pod> -n demo -- sh
kubectl exec -it pod/<pod> -n demo -c <container> -- bash
kubectl exec pod/<pod> -n demo -- printenv
kubectl exec pod/<pod> -n demo -- cat /etc/resolv.conf

Bei minimalen Images gibt es oft kein bash, curl, nslookup oder Paketmanager. Nutze dann Debug-Container.

Attach

kubectl attach pod/<pod> -n demo -c <container>
kubectl attach -it pod/<pod> -n demo -c <container>

attach verbindet sich mit einem laufenden Prozess. Für Shells ist exec meist geeigneter.

Dateien kopieren

kubectl cp demo/<pod>:/path/in/container ./local-file -c <container>
kubectl cp ./local-file demo/<pod>:/tmp/local-file -c <container>

kubectl cp benötigt häufig tar im Container. Wenn tar fehlt, verwende kubectl exec mit Streams oder ein Debug-Image.

Ephemeral Debug Container

kubectl debug -it pod/<pod> -n demo --image=busybox:1.36 --target=<container> -- sh
kubectl debug -it pod/<pod> -n demo --image=nicolaka/netshoot --target=<container> -- bash

Ephemeral Containers verändern den Pod zu Debug-Zwecken. Sie sind nicht für dauerhafte Änderungen gedacht.

Debug-Kopie eines Pods erstellen

kubectl debug pod/<pod> -n demo -it --copy-to=<pod>-debug --container=debug --image=busybox:1.36 -- sh

Node debuggen

kubectl debug node/<node> -it --image=ubuntu:24.04

In der Debug-Shell findest du das Host-Dateisystem typischerweise unter /host. Nutze das nur mit klarer Absicht.

16. Port-Forwarding, Proxy und lokale Tests

Port-Forward auf Pod

kubectl port-forward pod/<pod> -n demo 8080:80

Port-Forward auf Service

kubectl port-forward service/web -n demo 8080:80
curl http://127.0.0.1:8080

Port-Forward auf Deployment

kubectl port-forward deployment/web -n demo 8080:8080

API Proxy

kubectl proxy --port=8001
curl http://127.0.0.1:8001/api/
curl http://127.0.0.1:8001/apis/apps/v1/namespaces/demo/deployments

kubectl proxy ist für lokale Entwicklung und API-Erkundung nützlich. Setze es nicht ungeschützt auf gemeinsam genutzten Systemen ein.

Lokale Service-Tests

kubectl run curl -n demo --rm -it --image=curlimages/curl:8.8.0 --restart=Never -- http://web.demo.svc.cluster.local
kubectl run netshoot -n demo --rm -it --image=nicolaka/netshoot --restart=Never -- bash

17. Services, DNS, Endpoints und EndpointSlices

Services anzeigen

kubectl get services -n demo
kubectl get svc -n demo -o wide
kubectl describe service web -n demo
kubectl get service web -n demo -o yaml

Service erstellen

kubectl expose deployment web -n demo --port=80 --target-port=8080 --type=ClusterIP
kubectl create service clusterip web -n demo --tcp=80:8080 --dry-run=client -o yaml
kubectl create service nodeport web -n demo --tcp=80:8080 --dry-run=client -o yaml
kubectl create service loadbalancer web -n demo --tcp=80:8080 --dry-run=client -o yaml

Endpoints prüfen

kubectl get endpoints web -n demo -o wide
kubectl get endpointslices -n demo -l kubernetes.io/service-name=web
kubectl describe endpointslice -n demo -l kubernetes.io/service-name=web

Wenn ein Service keine Endpoints hat, stimmen meist Selector und Pod-Labels nicht überein oder die Pods sind nicht Ready.

DNS im Cluster testen

kubectl run dns-test -n demo --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default.svc.cluster.local
kubectl run dns-test -n demo --rm -it --image=busybox:1.36 --restart=Never -- nslookup web.demo.svc.cluster.local
kubectl run dns-test -n demo --rm -it --image=busybox:1.36 --restart=Never -- cat /etc/resolv.conf

CoreDNS prüfen

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100
kubectl get configmap coredns -n kube-system -o yaml

Service-Traffic prüfen

kubectl run curl -n demo --rm -it --image=curlimages/curl:8.8.0 --restart=Never -- curl -sv http://web.demo.svc.cluster.local
kubectl run netshoot -n demo --rm -it --image=nicolaka/netshoot --restart=Never -- curl -sv http://web.demo.svc.cluster.local

18. Ingress und Gateway API

Ingress anzeigen

kubectl get ingress -A
kubectl describe ingress web -n demo
kubectl get ingress web -n demo -o yaml

IngressClass prüfen

kubectl get ingressclass
kubectl describe ingressclass <ingressclass>

Ingress-Controller prüfen

kubectl get pods -A | grep -i ingress
kubectl get svc -A | grep -i ingress
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=100

Namespace und Labels hängen vom konkreten Controller ab.

Gateway API anzeigen

kubectl get gatewayclasses
kubectl get gateways -A
kubectl get httproutes -A
kubectl get grpcroutes -A
kubectl get tlsroutes -A
kubectl get referencegrants -A

Gateway API beschreiben

kubectl describe gateway <gateway> -n <namespace>
kubectl describe httproute <route> -n <namespace>
kubectl get httproute <route> -n <namespace> -o yaml

Typische Ingress-/Gateway-Triage

kubectl get ingress,svc,ep,endpointslice -n demo -o wide
kubectl describe ingress web -n demo
kubectl get events -n demo --sort-by=.lastTimestamp
kubectl get pods -A -o wide | grep -i ingress
kubectl logs -n <ingress-namespace> <ingress-controller-pod> --tail=200

19. NetworkPolicies und Netzwerktests

NetworkPolicies anzeigen

kubectl get networkpolicy -A
kubectl describe networkpolicy <policy> -n <namespace>
kubectl get networkpolicy <policy> -n <namespace> -o yaml

Netzwerktest-Pods

kubectl run netshoot -n demo --rm -it --image=nicolaka/netshoot --restart=Never -- bash
kubectl run busybox -n demo --rm -it --image=busybox:1.36 --restart=Never -- sh
kubectl run curl -n demo --rm -it --image=curlimages/curl:8.8.0 --restart=Never -- sh

DNS und HTTP testen

nslookup web.demo.svc.cluster.local
curl -sv http://web.demo.svc.cluster.local
wget -qO- http://web.demo.svc.cluster.local
nc -vz web.demo.svc.cluster.local 80

Pod-zu-Pod-Test

kubectl get pods -n demo -o wide
kubectl exec -it <pod> -n demo -- sh
ip addr
ip route
cat /etc/resolv.conf

CNI-Grundprüfung

kubectl get pods -n kube-system -o wide
kubectl get daemonsets -n kube-system
kubectl get nodes -o wide
kubectl describe node <node>

Wenn NetworkPolicies nicht wirken, prüfst du zuerst, ob dein CNI NetworkPolicies überhaupt durchsetzt.

20. ConfigMaps, Secrets und ServiceAccounts

ConfigMap erstellen

kubectl create configmap app-config -n demo --from-literal=LOG_LEVEL=info
kubectl create configmap app-config -n demo --from-file=application.yaml
kubectl create configmap app-config -n demo --from-env-file=.env
kubectl create configmap app-config -n demo --from-literal=LOG_LEVEL=info --dry-run=client -o yaml > configmap.yaml

ConfigMap prüfen

kubectl get configmap app-config -n demo
kubectl describe configmap app-config -n demo
kubectl get configmap app-config -n demo -o yaml

Secret erstellen

kubectl create secret generic app-secret -n demo --from-literal=password='dummy'
kubectl create secret generic app-secret -n demo --from-file=credentials.json
kubectl create secret tls web-tls -n demo --cert=tls.crt --key=tls.key
kubectl create secret docker-registry regcred -n demo \
  --docker-server=<registry> \
  --docker-username=<user> \
  --docker-password=<password> \
  --docker-email=<email>

Secret manifestieren, ohne echte Werte zu committen

kubectl create secret generic app-secret -n demo --from-literal=password='dummy' --dry-run=client -o yaml > secret.example.yaml

Echte Secrets gehören nicht in Workshop-Dateien. Nutze externe Secret-Systeme, Sealed Secrets, External Secrets oder die Secret-Lösung deiner Plattform.

Secret lesen

kubectl get secret app-secret -n demo -o yaml
kubectl get secret app-secret -n demo -o jsonpath='{.data.password}' | base64 -d; echo

Base64 ist keine Verschlüsselung. Es ist nur eine Kodierung.

ServiceAccount erstellen und Token prüfen

kubectl create serviceaccount app-sa -n demo
kubectl get serviceaccount app-sa -n demo -o yaml
kubectl create token app-sa -n demo

ImagePullSecrets setzen

kubectl patch serviceaccount default -n demo -p '{"imagePullSecrets":[{"name":"regcred"}]}'
kubectl get serviceaccount default -n demo -o yaml

21. RBAC, Authentifizierung und Autorisierung

Eigene Berechtigung prüfen

kubectl auth can-i get pods -n demo
kubectl auth can-i list secrets -n demo
kubectl auth can-i create deployments -n demo
kubectl auth can-i '*' '*' -n demo
kubectl auth whoami

Berechtigung für ServiceAccount prüfen

kubectl auth can-i get pods -n demo --as system:serviceaccount:demo:app-sa
kubectl auth can-i list secrets -n demo --as system:serviceaccount:demo:app-sa
kubectl auth can-i '*' '*' --as system:serviceaccount:demo:app-sa

Rollen und Bindings anzeigen

kubectl get roles,rolebindings -n demo
kubectl get clusterroles,clusterrolebindings
kubectl describe role <role> -n demo
kubectl describe rolebinding <rolebinding> -n demo
kubectl describe clusterrole <clusterrole>
kubectl describe clusterrolebinding <clusterrolebinding>

Role erstellen

kubectl create role pod-reader -n demo --verb=get,list,watch --resource=pods
kubectl create role deployment-editor -n demo --verb=get,list,watch,update,patch --resource=deployments.apps

RoleBinding erstellen

kubectl create rolebinding read-pods -n demo --role=pod-reader --serviceaccount=demo:app-sa
kubectl create rolebinding read-pods-user -n demo --role=pod-reader --user=alice@example.com
kubectl create rolebinding read-pods-group -n demo --role=pod-reader --group=developers

ClusterRole und ClusterRoleBinding

kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes
kubectl create clusterrolebinding node-reader-binding --clusterrole=node-reader --user=alice@example.com

Cluster-weite Rechte sind hochsensibel. Erstelle sie nur, wenn Namespace-Rollen nicht ausreichen.

RBAC aus Manifesten abgleichen

kubectl auth reconcile -f rbac.yaml --dry-run=server
kubectl auth reconcile -f rbac.yaml

Alle ServiceAccounts in Pods anzeigen

kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

22. Pod- und Container-Security

SecurityContext prüfen

kubectl get pod <pod> -n demo -o jsonpath='{.spec.securityContext}'
kubectl get pod <pod> -n demo -o jsonpath='{.spec.containers[*].securityContext}'
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

Privilegierte Pods finden

kubectl get pods -A -o json | jq -r '
  .items[] |
  select(any(.spec.containers[]?; .securityContext.privileged == true)) |
  [.metadata.namespace, .metadata.name] | @tsv'

Pods mit Host-Network, Host-PID oder Host-IPC finden

kubectl get pods -A -o json | jq -r '
  .items[] |
  select(.spec.hostNetwork == true or .spec.hostPID == true or .spec.hostIPC == true) |
  [.metadata.namespace, .metadata.name, "host-level"] | @tsv'

Pod Security Admission per Namespace-Label

kubectl label namespace demo pod-security.kubernetes.io/enforce=baseline --overwrite
kubectl label namespace demo pod-security.kubernetes.io/audit=restricted --overwrite
kubectl label namespace demo pod-security.kubernetes.io/warn=restricted --overwrite
kubectl get namespace demo --show-labels

Admission-Fehler prüfen

kubectl apply --dry-run=server -f pod.yaml
kubectl get events -n demo --sort-by=.lastTimestamp

Images und Pull Policy prüfen

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{.imagePullPolicy}{";"}{end}{"\n"}{end}'

Vermeide unkontrollierte :latest-Tags in produktionsnahen Umgebungen.

23. Ressourcenmanagement: Requests, Limits, Quotas und LimitRanges

Requests und Limits anzeigen

kubectl get pod <pod> -n demo -o jsonpath='{.spec.containers[*].resources}'
kubectl describe pod <pod> -n demo
kubectl get pods -n demo -o custom-columns='POD:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory,CPU_LIM:.spec.containers[*].resources.limits.cpu,MEM_LIM:.spec.containers[*].resources.limits.memory'

Ressourcen setzen

kubectl set resources deployment/web -n demo --requests=cpu=100m,memory=128Mi --limits=cpu=500m,memory=512Mi
kubectl set resources deployment/web -n demo -c app --requests=cpu=200m,memory=256Mi --limits=cpu=1,memory=1Gi

ResourceQuota

kubectl get resourcequota -n demo
kubectl describe resourcequota -n demo
kubectl create quota demo-quota -n demo \
  --hard=pods=20,requests.cpu=4,requests.memory=8Gi,limits.cpu=8,limits.memory=16Gi

LimitRange

kubectl get limitrange -n demo
kubectl describe limitrange -n demo

LimitRanges werden in der Regel als Manifest gepflegt, weil die imperativen Generatoren begrenzt sind.

Metrics Server prüfen

kubectl top nodes
kubectl top pods -A
kubectl top pods -n demo --containers
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl describe apiservice v1beta1.metrics.k8s.io

Wenn kubectl top nicht funktioniert, prüfe den Metrics Server und dessen APIService.

24. Storage: StorageClasses, PVs, PVCs, CSI und VolumeAttachments

StorageClasses anzeigen

kubectl get storageclass
kubectl describe storageclass <storageclass>
kubectl get storageclass -o yaml

PVCs und PVs anzeigen

kubectl get pvc -A
kubectl get pv
kubectl describe pvc <pvc> -n demo
kubectl describe pv <pv>

PVC erzeugen

cat <<'YAML' | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
  namespace: demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard
YAML

PVC an Debug-Pod mounten

cat <<'YAML' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: pvc-debug
  namespace: demo
spec:
  restartPolicy: Never
  containers:
    - name: shell
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data
YAML

CSI prüfen

kubectl get csidrivers
kubectl get csinodes
kubectl get volumeattachments
kubectl describe volumeattachment <volumeattachment>
kubectl get pods -A | grep -i csi

Storage-Triage

kubectl describe pvc <pvc> -n demo
kubectl describe pod <pod> -n demo
kubectl get events -n demo --sort-by=.lastTimestamp
kubectl get pv,pvc -A
kubectl get storageclass
kubectl get volumeattachments

25. Nodes, Scheduling, Taints, Drain und Maintenance

Nodes anzeigen

kubectl get nodes
kubectl get nodes -o wide
kubectl describe node <node>
kubectl get node <node> -o yaml

Pods auf einem Node anzeigen

kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide

Node labels

kubectl get nodes --show-labels
kubectl label node <node> disktype=ssd
kubectl label node <node> disktype-

Taints setzen und entfernen

kubectl taint nodes <node> dedicated=gpu:NoSchedule
kubectl taint nodes <node> dedicated=gpu:NoSchedule-
kubectl describe node <node> | grep -i taints -A2

Node cordon und uncordon

kubectl cordon <node>
kubectl get node <node>
kubectl uncordon <node>

cordon verhindert neue Scheduling-Entscheidungen auf dem Node. Laufende Pods bleiben bestehen.

Node drain

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --timeout=10m
kubectl uncordon <node>

Prüfe vor drain:

kubectl get pdb -A
kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide
kubectl describe node <node>

Scheduling-Probleme analysieren

kubectl describe pod <pod> -n demo
kubectl get events -n demo --sort-by=.lastTimestamp
kubectl describe node <node>
kubectl get resourcequota,limitrange -n demo
kubectl get pods -A --field-selector=status.phase=Pending

Node-Pressure prüfen

kubectl describe node <node> | grep -E 'Pressure|Allocatable|Capacity' -A5
kubectl get events -A --field-selector=reason=Evicted
kubectl top node <node>
kubectl top pods -A --sort-by=memory

26. Events, Metriken und Beobachtbarkeit

Events anzeigen

kubectl get events -n demo
kubectl get events -n demo --sort-by=.lastTimestamp
kubectl get events -A --sort-by=.lastTimestamp | tail -50
kubectl get events -A --field-selector=type=Warning

Neueres events-Kommando, falls unterstützt

kubectl events -n demo
kubectl events -n demo --for pod/<pod>
kubectl events -A --types=Warning

Nicht jede ältere kubectl-Version unterstützt kubectl events gleich.

Metriken anzeigen

kubectl top nodes
kubectl top pods -A
kubectl top pod <pod> -n demo
kubectl top pods -n demo --containers

API Server Health und Readiness

kubectl get --raw /readyz?verbose
kubectl get --raw /livez?verbose
kubectl get --raw /healthz

Cluster-Info dump

kubectl cluster-info
kubectl cluster-info dump
kubectl cluster-info dump --namespaces demo --output-directory ./cluster-dump

cluster-info dump kann sensible Daten enthalten. Nicht ungeprüft teilen.

27. kubectl-Top-Level-Kommandos im Überblick

Kommando	Zweck	Typischer Einsatz
`kubectl annotate`	Annotationen setzen, ändern oder entfernen.	Metadaten, Change-Cause, Controller-Hinweise.
`kubectl api-resources`	Verfügbare Ressourcentypen anzeigen.	API-Erkundung, CRD-Prüfung.
`kubectl api-versions`	Verfügbare API-Versionen anzeigen.	Manifest-Kompatibilität prüfen.
`kubectl apply`	Deklarative Konfiguration anwenden.	Standard für GitOps-nahe Änderungen.
`kubectl attach`	An laufenden Container-Prozess anhängen.	Interaktive Diagnose.
`kubectl auth`	Autorisierung prüfen und RBAC abgleichen.	`can-i`, `whoami`, `reconcile`.
`kubectl autoscale`	HPA erzeugen.	CPU-basiertes Autoscaling starten.
`kubectl certificate`	CertificateSigningRequests verwalten.	CSR genehmigen oder ablehnen.
`kubectl cluster-info`	Cluster-Endpunkte anzeigen.	Erste Clusterdiagnose.
`kubectl completion`	Shell-Autocomplete erzeugen.	Produktiveres Arbeiten.
`kubectl config`	kubeconfig verwalten.	Kontext, Cluster, User, Namespace.
`kubectl cordon`	Node für neues Scheduling sperren.	Wartung vorbereiten.
`kubectl cp`	Dateien zwischen Container und lokalem System kopieren.	Diagnose, Export kleiner Dateien.
`kubectl create`	Ressourcen imperativ erzeugen.	Schnelle Tests, YAML-Generator.
`kubectl debug`	Debug-Container oder Node-Debug starten.	Laufzeitdiagnose.
`kubectl delete`	Ressourcen löschen.	Rückbau, Cleanup, Neuaufbau durch Controller.
`kubectl describe`	Detailbeschreibung mit Events anzeigen.	Fehlersuche.
`kubectl diff`	Unterschiede zwischen Manifest und Cluster anzeigen.	Review vor `apply`.
`kubectl drain`	Node für Wartung leeren.	Node-Patching, Hardware-Wartung.
`kubectl edit`	Ressource interaktiv ändern.	Notfalländerung.
`kubectl events`	Events anzeigen, falls Version unterstützt.	Schnelle Eventdiagnose.
`kubectl exec`	Kommando im Container ausführen.	Shell, Prozess- und Netzwerktests.
`kubectl explain`	API-Felder erklären.	Manifest-Entwicklung.
`kubectl expose`	Service für Ressource erzeugen.	Schnelle Service-Erstellung.
`kubectl get`	Ressourcen listen oder abrufen.	Standard-Leseoperation.
`kubectl kustomize`	Kustomization rendern.	Manifest-Generierung.
`kubectl label`	Labels setzen, ändern oder entfernen.	Selektoren, Organisation, Policies.
`kubectl logs`	Containerlogs anzeigen.	Applikationsdiagnose.
`kubectl options`	Globale Optionen anzeigen.	CLI-Hilfe.
`kubectl patch`	Teiländerung anwenden.	Präzise Änderung einzelner Felder.
`kubectl plugin`	Plugins anzeigen.	CLI-Erweiterungen.
`kubectl port-forward`	Lokalen Port zu Pod/Service weiterleiten.	Lokale Tests.
`kubectl proxy`	Lokalen Proxy zur Kubernetes API starten.	API-Erkundung.
`kubectl replace`	Ressource ersetzen.	Vollständiger Austausch.
`kubectl rollout`	Rollouts verwalten.	Status, History, Undo, Restart.
`kubectl run`	Pod starten oder Manifest generieren.	Debugging, schnelle Tests.
`kubectl scale`	Replica-Anzahl ändern.	Manuelle Skalierung.
`kubectl set`	Teilbereiche setzen.	Image, Env, Ressourcen, ServiceAccount.
`kubectl taint`	Taints auf Nodes verwalten.	Scheduling-Steuerung.
`kubectl top`	Metriken anzeigen.	CPU-/Memory-Sicht.
`kubectl uncordon`	Node wieder schedulable machen.	Wartung abschließen.
`kubectl version`	Client- und Serverversion anzeigen.	Kompatibilität prüfen.
`kubectl wait`	Auf Bedingung warten.	Skripte, CI, Rollout-Validierung.

Hilfe zu jedem Kommando

kubectl --help
kubectl get --help
kubectl create --help
kubectl create secret --help
kubectl rollout --help
kubectl rollout history --help
kubectl options

28. kubeadm: Überblick

kubeadm ist ein Bootstrapping-Werkzeug für Kubernetes-Cluster. Es richtet einen minimal funktionsfähigen Cluster ein, führt aber nicht automatisch Machine-Provisioning, Cloud-Integration, Monitoring, Dashboard oder vollständige Add-on-Installation aus.

Typische Aufgaben:

Kommando	Zweck
`kubeadm init`	Control-Plane-Node initialisieren.
`kubeadm join`	Worker oder weitere Control-Plane dem Cluster hinzufügen.
`kubeadm upgrade`	Cluster-Upgrade planen und ausführen.
`kubeadm config`	kubeadm-Konfiguration anzeigen, migrieren, validieren und Images verwalten.
`kubeadm token`	Bootstrap-Tokens verwalten.
`kubeadm reset`	kubeadm-Artefakte eines Nodes entfernen.
`kubeadm certs`	Kubernetes-Zertifikate prüfen und erneuern.
`kubeadm kubeconfig`	kubeconfig-Dateien verwalten.
`kubeadm version`	kubeadm-Version anzeigen.
`kubeadm completion`	Shell-Completion erzeugen.
`kubeadm alpha`	experimentelle Funktionen; nicht als stabile Betriebsbasis verwenden.

Hilfe

kubeadm --help
kubeadm init --help
kubeadm join --help
kubeadm upgrade --help
kubeadm certs --help

29. kubeadm init

Minimaler Control-Plane-Start

sudo kubeadm init

Das nutzt Defaults und ist für Labore ausreichend, aber für reproduzierbare Setups zu unpräzise.

Initialisierung mit Pod-CIDR

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Der Pod-CIDR muss zu deinem CNI passen. Flannel nutzt in vielen Beispielen 10.244.0.0/16; andere CNIs haben andere Defaults.

Initialisierung mit API-Server-Advertise-Adresse

sudo kubeadm init --apiserver-advertise-address=<ip-adresse>

Das ist relevant bei Hosts mit mehreren Interfaces.

Initialisierung mit Control-Plane-Endpoint

sudo kubeadm init \
  --control-plane-endpoint=<dns-name-oder-loadbalancer>:6443 \
  --upload-certs

--control-plane-endpoint ist wichtig für HA-Control-Planes. --upload-certs erleichtert das spätere Joinen weiterer Control-Plane-Nodes.

Initialisierung mit Konfigurationsdatei

sudo kubeadm init --config kubeadm-init.yaml

Beispiel:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 192.0.2.10
  bindPort: 6443
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.36.0
controlPlaneEndpoint: k8s-api.example.internal:6443
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12

Nach init: kubeconfig einrichten

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes

Nach init: CNI installieren

kubectl get nodes
kubectl get pods -n kube-system
kubectl apply -f <cni-manifest.yaml>
kubectl get nodes -w

Ohne CNI bleiben Nodes häufig NotReady, und CoreDNS-Pods können nicht korrekt laufen.

init mit Phasen untersuchen

sudo kubeadm init phase --help
sudo kubeadm init phase preflight --config kubeadm-init.yaml
sudo kubeadm init phase certs all --config kubeadm-init.yaml
sudo kubeadm init phase kubeconfig all --config kubeadm-init.yaml
sudo kubeadm init phase control-plane all --config kubeadm-init.yaml
sudo kubeadm init phase etcd local --config kubeadm-init.yaml
sudo kubeadm init phase upload-config all --config kubeadm-init.yaml
sudo kubeadm init phase bootstrap-token --config kubeadm-init.yaml
sudo kubeadm init phase addon all --config kubeadm-init.yaml

Phasen sind für Debugging und Spezialfälle nützlich. Für Standardinstallationen nutzt du in der Regel kubeadm init --config ....

30. kubeadm join

Join-Kommando anzeigen lassen

Auf einem bestehenden Control-Plane-Node:

kubeadm token create --print-join-command

Worker joinen

Auf dem neuen Worker:

sudo kubeadm join <api-server>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Join mit Konfigurationsdatei

sudo kubeadm join --config kubeadm-join.yaml

Beispiel:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: k8s-api.example.internal:6443
    token: abcdef.0123456789abcdef
    caCertHashes:
      - sha256:<hash>
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock

Weitere Control-Plane joinen

sudo kubeadm join <api-server>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <certificate-key>

Den Certificate Key erzeugst oder erneuerst du mit:

sudo kubeadm init phase upload-certs --upload-certs

Join-Phasen

sudo kubeadm join phase --help
sudo kubeadm join phase preflight --config kubeadm-join.yaml
sudo kubeadm join phase kubelet-start --config kubeadm-join.yaml
sudo kubeadm join phase control-plane-prepare all --config kubeadm-join.yaml
sudo kubeadm join phase control-plane-join all --config kubeadm-join.yaml

31. kubeadm reset

Node zurücksetzen

sudo kubeadm reset
sudo kubeadm reset -f

kubeadm reset entfernt lokale kubeadm-Artefakte. Es ist kein vollständiger Betriebssystem-Reset.

Reset mit CRI-Socket

sudo kubeadm reset -f --cri-socket unix:///var/run/containerd/containerd.sock

Nach Reset prüfen

sudo systemctl status kubelet
sudo ls -la /etc/kubernetes/
sudo ls -la /var/lib/kubelet/
sudo iptables-save | grep -i kube || true
ip link

Je nach CNI musst du Netzwerkschnittstellen, iptables/nftables-Regeln oder CNI-Verzeichnisse separat bereinigen.

CNI-Reste vorsichtig entfernen

sudo rm -rf /etc/cni/net.d
sudo rm -rf /var/lib/cni

Nur ausführen, wenn der Node wirklich aus dem Cluster entfernt oder neu aufgebaut wird.

32. kubeadm upgrade

Aktuelle Versionen prüfen

kubectl get nodes
kubectl version
kubeadm version

Upgrade-Plan anzeigen

sudo kubeadm upgrade plan

Control-Plane upgraden

sudo kubeadm upgrade apply v1.36.0

Passe die Version an deine Zielversion an. In der Praxis installierst du vorher die passende kubeadm-Paketversion.

Node-Upgrade-Schritt

Auf weiteren Control-Plane-Nodes und Workern:

sudo kubeadm upgrade node

Difference anzeigen

sudo kubeadm upgrade diff v1.36.0

Typischer Ablauf pro Node

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# kubeadm/kubelet/kubectl über Paketmanager aktualisieren
sudo kubeadm upgrade node
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl uncordon <node>
kubectl get nodes

Für Control-Plane-Nodes prüfst du zusätzlich API Server, Controller Manager, Scheduler und etcd.

33. kubeadm config und Images

Defaults anzeigen

kubeadm config print init-defaults
kubeadm config print join-defaults

Konfiguration migrieren

kubeadm config migrate --old-config old.yaml --new-config new.yaml

Konfiguration validieren

kubeadm config validate --config kubeadm-init.yaml

Cluster-Konfiguration aus ConfigMap lesen

kubectl get configmap kubeadm-config -n kube-system -o yaml
kubectl get configmap kubeadm-config -n kube-system -o jsonpath='{.data.ClusterConfiguration}'

Images listen und vorziehen

kubeadm config images list
kubeadm config images list --kubernetes-version v1.36.0
sudo kubeadm config images pull
sudo kubeadm config images pull --kubernetes-version v1.36.0
sudo kubeadm config images pull --cri-socket unix:///var/run/containerd/containerd.sock

Das ist wichtig für Air-Gap-Umgebungen oder kontrollierte Registry-Spiegel.

34. kubeadm token, certs und kubeconfig

Bootstrap-Tokens anzeigen und erzeugen

kubeadm token list
kubeadm token generate
kubeadm token create
kubeadm token create --ttl 2h
kubeadm token create --print-join-command
kubeadm token delete <token-id>

Zertifikatsablauf prüfen

sudo kubeadm certs check-expiration

Zertifikate erneuern

sudo kubeadm certs renew all
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew apiserver-kubelet-client
sudo kubeadm certs renew front-proxy-client
sudo kubeadm certs renew etcd-server
sudo kubeadm certs renew etcd-peer
sudo kubeadm certs renew etcd-healthcheck-client
sudo kubeadm certs renew apiserver-etcd-client

Nach Zertifikatserneuerung musst du statische Pods oder relevante Komponenten neu starten lassen, häufig durch Neustart des kubelet oder durch erneutes Schreiben/Bewegen der Manifeste.

Certificate Key erzeugen

sudo kubeadm certs certificate-key
sudo kubeadm init phase upload-certs --upload-certs

CSRs erzeugen

sudo kubeadm certs generate-csr

kubeconfig-Dateien verwalten

sudo kubeadm kubeconfig --help
sudo kubeadm kubeconfig user --client-name <name>
sudo kubeadm init phase kubeconfig admin
sudo kubeadm init phase kubeconfig kubelet
sudo kubeadm init phase kubeconfig controller-manager
sudo kubeadm init phase kubeconfig scheduler

Typische kubeadm-kubeconfigs liegen unter:

ls -la /etc/kubernetes/*.conf

35. kubeadm phases, completion, version und alpha

Version

kubeadm version
kubeadm version -o yaml
kubeadm version -o json

Completion

source <(kubeadm completion bash)
kubeadm completion zsh
kubeadm completion fish

Phasen anzeigen

kubeadm init phase --help
kubeadm join phase --help
kubeadm reset phase --help

Alpha-Funktionen

kubeadm alpha --help

Alpha-Funktionen können sich ändern oder verschwinden. Nutze sie nicht als stabile Grundlage für produktive Runbooks.

36. kubelet und systemd

kubelet ist der Node-Agent. In kubeadm-Setups läuft er meistens als systemd-Service und startet statische Pods aus /etc/kubernetes/manifests.

Service prüfen

sudo systemctl status kubelet
sudo systemctl is-enabled kubelet
sudo systemctl cat kubelet
sudo journalctl -u kubelet -n 200 --no-pager
sudo journalctl -u kubelet -f

Service steuern

sudo systemctl daemon-reload
sudo systemctl restart kubelet
sudo systemctl stop kubelet
sudo systemctl start kubelet

kubelet-Konfiguration prüfen

sudo cat /var/lib/kubelet/config.yaml
sudo cat /var/lib/kubelet/kubeadm-flags.env
sudo cat /etc/default/kubelet 2>/dev/null || true
sudo cat /etc/sysconfig/kubelet 2>/dev/null || true

kubelet direkt aufrufen

kubelet --help
kubelet --version

Direkte kubelet-Starts sind im Betrieb unüblich. Du prüfst und steuerst kubelet normalerweise über systemd.

Häufige kubelet-Fehler prüfen

sudo journalctl -u kubelet -n 300 --no-pager | grep -Ei 'error|failed|certificate|cni|runtime|eviction'
crictl info
crictl ps -a
kubectl describe node <node>

37. Control-Plane-Komponenten: kube-apiserver, scheduler, controller-manager

In kubeadm-Clustern laufen Control-Plane-Komponenten meist als statische Pods.

Statische Pod-Manifeste anzeigen

sudo ls -la /etc/kubernetes/manifests
sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml
sudo cat /etc/kubernetes/manifests/kube-controller-manager.yaml
sudo cat /etc/kubernetes/manifests/kube-scheduler.yaml
sudo cat /etc/kubernetes/manifests/etcd.yaml

Control-Plane-Pods prüfen

kubectl get pods -n kube-system -o wide
kubectl describe pod -n kube-system kube-apiserver-<node>
kubectl logs -n kube-system kube-apiserver-<node> --tail=100
kubectl logs -n kube-system kube-controller-manager-<node> --tail=100
kubectl logs -n kube-system kube-scheduler-<node> --tail=100

kube-apiserver

kube-apiserver --help
kubectl get --raw /readyz?verbose
kubectl get --raw /livez?verbose
kubectl get --raw /metrics | head

Wichtige Themen beim API Server: Zertifikate, Admission Controller, Authentifizierung, Autorisierung, Audit Logging, etcd-Verbindung, Feature Gates.

kube-controller-manager

kube-controller-manager --help
kubectl logs -n kube-system kube-controller-manager-<node> --tail=200

Der Controller Manager enthält zentrale Control Loops, die den Ist-Zustand auf den gewünschten Zustand hin korrigieren.

kube-scheduler

kube-scheduler --help
kubectl logs -n kube-system kube-scheduler-<node> --tail=200

Der Scheduler wählt Nodes für Pods aus. Scheduling-Fehler findest du häufig in Pod-Events, nicht nur im Scheduler-Log.

38. kube-proxy

kube-proxy implementiert Service-Netzwerkregeln, je nach Modus über iptables, IPVS oder nftables/andere Mechanismen der Distribution.

kube-proxy prüfen

kubectl get daemonset kube-proxy -n kube-system
kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=100
kubectl get configmap kube-proxy -n kube-system -o yaml

Direktes Binary

kube-proxy --help
kube-proxy --version

Service-Regeln auf Node prüfen

sudo iptables-save | grep KUBE-SVC | head
sudo iptables-save | grep KUBE-SEP | head
sudo ipvsadm -Ln 2>/dev/null | head || true
sudo nft list ruleset 2>/dev/null | grep -i kube | head || true

Welche Kommandos funktionieren, hängt vom kube-proxy-Modus und Betriebssystem ab.

39. Container Runtime: crictl, ctr, nerdctl und Docker

crictl: Standardwerkzeug für CRI-Debugging

crictl spricht die Kubernetes Container Runtime Interface API. Für Node-Debugging ist crictl meistens das passendste Werkzeug.

Endpoint konfigurieren

sudo crictl config runtime-endpoint unix:///var/run/containerd/containerd.sock
sudo crictl config image-endpoint unix:///var/run/containerd/containerd.sock
sudo cat /etc/crictl.yaml

Für CRI-O:

sudo crictl --runtime-endpoint unix:///var/run/crio/crio.sock ps

Runtime-Info

sudo crictl info
sudo crictl version

Pods und Container anzeigen

sudo crictl pods
sudo crictl pods -a
sudo crictl ps
sudo crictl ps -a
sudo crictl inspect <container-id>
sudo crictl inspectp <pod-id>

Logs und Exec

sudo crictl logs <container-id>
sudo crictl logs --tail=100 <container-id>
sudo crictl exec -it <container-id> sh

Images

sudo crictl images
sudo crictl pull <image>
sudo crictl rmi <image-id>
sudo crictl inspecti <image-id>

Container stoppen und entfernen

sudo crictl stop <container-id>
sudo crictl rm <container-id>
sudo crictl rmp <pod-id>

Nutze Stop/Remove auf Kubernetes-Containern nur zur Diagnose. kubelet erstellt verwaltete Container wieder neu.

ctr: containerd-nahes Werkzeug

ctr spricht direkt mit containerd und ist niedriger angesiedelt als crictl.

sudo ctr version
sudo ctr namespaces list
sudo ctr -n k8s.io containers list
sudo ctr -n k8s.io tasks list
sudo ctr -n k8s.io images list
sudo ctr -n k8s.io snapshots list
sudo ctr -n k8s.io content ls

Kubernetes-Objekte liegen bei containerd üblicherweise im Namespace k8s.io.

nerdctl

nerdctl bietet eine Docker-ähnliche Bedienung für containerd. Für Kubernetes-Runtime-Debugging bleibt crictl meist korrekter, weil es die CRI-Sicht zeigt.

sudo nerdctl version
sudo nerdctl -n k8s.io ps
sudo nerdctl -n k8s.io images
sudo nerdctl -n k8s.io logs <container>
sudo nerdctl -n k8s.io inspect <container>

Docker

In modernen Kubernetes-Clustern ist Docker nicht mehr die direkte Kubernetes-Runtime. Docker-Kommandos sind trotzdem relevant, wenn du Images lokal baust.

docker build -t <image> .
docker tag <image> <registry>/<image>:<tag>
docker push <registry>/<image>:<tag>
docker run --rm -it <image> sh
docker logs <container>
docker inspect <container>

Für Container, die kubelet über containerd oder CRI-O startet, nutzt du nicht docker ps, sondern crictl ps.

40. etcd, etcdctl und etcdutl

etcd speichert den Clusterzustand. Arbeiten an etcd sind kritisch. Vor Änderungen brauchst du Backups, Change-Fenster und einen Restore-Plan.

etcd-Pod in kubeadm prüfen

kubectl get pods -n kube-system -l component=etcd -o wide
kubectl logs -n kube-system etcd-<node> --tail=100
sudo cat /etc/kubernetes/manifests/etcd.yaml

etcdctl-Umgebung für kubeadm

export ETCDCTL_API=3
export ETCDCTL_ENDPOINTS=https://127.0.0.1:2379
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/healthcheck-client.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/healthcheck-client.key

Endpoint Health und Status

sudo -E etcdctl endpoint health
sudo -E etcdctl endpoint status -w table
sudo -E etcdctl member list -w table

Snapshot erstellen

sudo -E etcdctl snapshot save /var/backups/etcd-snapshot.db
sudo -E etcdctl snapshot status /var/backups/etcd-snapshot.db -w table

Snapshot mit etcdutl prüfen

etcdutl snapshot status /var/backups/etcd-snapshot.db -w table

Snapshot wiederherstellen

etcdutl snapshot restore /var/backups/etcd-snapshot.db --data-dir /var/lib/etcd-restore

Für Kubernetes-Restore-Szenarien sind Revisionssprünge wichtig, damit Informer-Caches nicht mit zurückspringenden Revisionen arbeiten:

etcdutl snapshot restore /var/backups/etcd-snapshot.db \
  --bump-revision 1000000000 \
  --mark-compacted \
  --data-dir /var/lib/etcd-restore

Keys inspizieren

sudo -E etcdctl get / --prefix --keys-only | head
sudo -E etcdctl get /registry/namespaces --prefix --keys-only

Im Normalbetrieb liest du Kubernetes-Zustand über die API, nicht direkt aus etcd. Direkte etcd-Abfragen sind Diagnose- und Disaster-Recovery-Werkzeuge.

41. Helm

Helm verwaltet Kubernetes-Anwendungen als Charts und Releases.

Repositorys

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo list
helm repo update
helm search repo nginx
helm repo remove bitnami

Chart ansehen

helm show chart bitnami/nginx
helm show values bitnami/nginx
helm show readme bitnami/nginx
helm show crds <chart>
helm pull bitnami/nginx --untar

Chart prüfen und rendern

helm lint ./chart
helm template web ./chart -f values.yaml
helm template web ./chart -f values.yaml --debug
helm template web ./chart -n demo --include-crds

Installieren und aktualisieren

helm install web ./chart -n demo --create-namespace
helm upgrade web ./chart -n demo -f values.yaml
helm upgrade --install web ./chart -n demo --create-namespace -f values.yaml
helm upgrade --install web ./chart -n demo --atomic --wait --timeout 5m
helm upgrade --install web ./chart -n demo --dry-run --debug

--atomic rollt bei Fehlern zurück. --wait wartet auf Kubernetes-Readiness-Bedingungen, soweit Helm sie bewerten kann.

Releases anzeigen

helm list -n demo
helm list -A
helm status web -n demo
helm history web -n demo

Release-Inhalte abrufen

helm get values web -n demo
helm get values web -n demo --all
helm get manifest web -n demo
helm get hooks web -n demo
helm get notes web -n demo
helm get all web -n demo

Rollback und Uninstall

helm rollback web 1 -n demo
helm uninstall web -n demo
helm uninstall web -n demo --keep-history

Dependencies

helm dependency list ./chart
helm dependency update ./chart
helm dependency build ./chart

Paketieren und OCI Registry

helm package ./chart
helm registry login <registry>
helm push ./chart-0.1.0.tgz oci://<registry>/<repo>
helm pull oci://<registry>/<repo>/<chart> --version 0.1.0

Helm-Plugins

helm plugin list
helm plugin install <plugin-url>
helm plugin update <plugin-name>
helm plugin uninstall <plugin-name>

42. Kustomize

Kustomize rendert Kubernetes-Manifeste aus Bases und Overlays.

Mit kubectl integriertes Kustomize

kubectl kustomize overlays/dev
kubectl apply -k overlays/dev
kubectl diff -k overlays/dev
kubectl delete -k overlays/dev

Eigenständiges kustomize-Binary

kustomize build overlays/dev
kustomize build overlays/prod > rendered.yaml
kustomize edit set image app=ghcr.io/example/app:1.2.3
kustomize edit set namespace demo
kustomize edit add resource deployment.yaml

Typisches Overlay prüfen

find overlays/dev -maxdepth 2 -type f -name 'kustomization.yaml' -print
kubectl kustomize overlays/dev | kubectl apply --dry-run=server -f -
kubectl kustomize overlays/dev | kubectl diff -f -

ConfigMap- und Secret-Generatoren

kustomize edit add configmap app-config --from-literal=LOG_LEVEL=info
kustomize edit add secret app-secret --from-literal=password=dummy

Auch hier gilt: echte Secrets nicht in Git speichern.

43. Lokale und leichtgewichtige Cluster: kind, minikube, k3d, k3s, k0s und Talos

Diese Tools sind nicht Kubernetes-Core, aber im Workshop und bei Labs häufig relevant.

kind

kind version
kind create cluster
kind create cluster --name workshop
kind get clusters
kind get kubeconfig --name workshop
kind load docker-image <image> --name workshop
kind export logs ./kind-logs --name workshop
kind delete cluster --name workshop

minikube

minikube version
minikube start
minikube start --driver=docker
minikube status
minikube kubectl -- get pods -A
minikube addons list
minikube addons enable ingress
minikube service <service> -n <namespace>
minikube tunnel
minikube logs
minikube delete

k3d

k3d version
k3d cluster create workshop
k3d cluster list
k3d kubeconfig get workshop
k3d image import <image> -c workshop
k3d cluster delete workshop

k3s

sudo systemctl status k3s
sudo journalctl -u k3s -f
sudo k3s kubectl get nodes
sudo cat /etc/rancher/k3s/k3s.yaml

k0s

k0s version
sudo k0s status
sudo k0s kubectl get nodes
sudo k0s kubeconfig admin
sudo systemctl status k0scontroller
sudo systemctl status k0sworker

Talos

talosctl version
talosctl config endpoint <node-ip>
talosctl config node <node-ip>
talosctl health
talosctl kubeconfig .
talosctl service kubelet
talosctl logs kubelet
talosctl dmesg
talosctl dashboard

Talos hat kein klassisches SSH-/Shell-Modell. Du arbeitest über talosctl.

44. Cloud-Cluster: EKS, GKE und AKS

Cloud-CLIs erzeugen oft kubeconfig-Einträge. Danach arbeitest du wieder mit kubectl.

AWS EKS

aws eks list-clusters --region <region>
aws eks describe-cluster --name <cluster> --region <region>
aws eks update-kubeconfig --name <cluster> --region <region>
kubectl get nodes

Google GKE

gcloud container clusters list --region <region>
gcloud container clusters get-credentials <cluster> --region <region> --project <project>
kubectl get nodes

Azure AKS

az aks list -o table
az aks get-credentials --resource-group <resource-group> --name <cluster>
az aks get-credentials --resource-group <resource-group> --name <cluster> --overwrite-existing
kubectl get nodes

Cloud-spezifische Rechte, Netzwerkmodelle, LoadBalancer, StorageClasses und Managed Add-ons unterscheiden sich erheblich. Prüfe immer die Provider-Dokumentation.

45. CNI-, Service-Mesh- und Add-on-Kommandos

Diese Kommandos hängen von installierten Add-ons ab.

Cilium

cilium status
cilium version
cilium connectivity test
cilium sysdump
cilium config view
cilium policy get
hubble status
hubble observe
hubble observe --namespace demo

Calico

calicoctl version
calicoctl get nodes
calicoctl get ippools
calicoctl get networkpolicy -A
calicoctl get globalnetworkpolicy
calicoctl get felixconfiguration default -o yaml

Istio

istioctl version
istioctl proxy-status
istioctl analyze
istioctl x describe pod <pod> -n <namespace>
istioctl proxy-config clusters <pod> -n <namespace>
istioctl proxy-config listeners <pod> -n <namespace>
istioctl proxy-config routes <pod> -n <namespace>
istioctl proxy-config endpoints <pod> -n <namespace>

cert-manager

kubectl get certificates -A
kubectl get certificaterequests -A
kubectl get issuers -A
kubectl get clusterissuers
kubectl describe certificate <certificate> -n <namespace>
kubectl describe certificaterequest <request> -n <namespace>
kubectl get challenges,orders -A

Argo CD CLI und kubectl-Sicht

argocd version
argocd login <server>
argocd app list
argocd app get <app>
argocd app sync <app>
argocd app diff <app>
argocd app history <app>

kubectl get applications -n argocd
kubectl describe application <app> -n argocd

Flux CLI

flux version
flux check
flux get sources all -A
flux get kustomizations -A
flux get helmreleases -A
flux reconcile kustomization <name> -n <namespace>
flux reconcile source git <name> -n <namespace>

Krew und kubectl-Plugins

kubectl plugin list
kubectl krew version
kubectl krew search
kubectl krew install ctx
kubectl krew install ns
kubectl krew install neat
kubectl krew update
kubectl krew upgrade

Plugins sind hilfreich, aber nicht in jedem Cluster oder auf jedem Admin-Rechner vorhanden. Runbooks sollten ohne nicht zwingende Plugins verständlich bleiben.

46. Linux-Hilfsbefehle für Kubernetes-Betrieb

Diese Kommandos laufen auf Nodes oder Admin-Maschinen.

systemd und Logs

sudo systemctl status kubelet
sudo systemctl status containerd
sudo systemctl status crio
sudo journalctl -u kubelet -n 200 --no-pager
sudo journalctl -u containerd -n 200 --no-pager
sudo journalctl -u crio -n 200 --no-pager

Netzwerk

ip addr
ip route
ss -lntup
ss -antp | grep 6443
sudo iptables-save | grep -i kube
sudo nft list ruleset | grep -i kube
sudo ipvsadm -Ln
conntrack -L 2>/dev/null | head

DNS

resolvectl status 2>/dev/null || true
cat /etc/resolv.conf
nslookup kubernetes.default.svc.cluster.local <cluster-dns-ip>
dig kubernetes.default.svc.cluster.local @<cluster-dns-ip>

Dateien und Mounts

df -h
df -ih
mount | grep kubelet
findmnt | grep kubelet
sudo du -sh /var/lib/kubelet/* 2>/dev/null | sort -h
sudo du -sh /var/lib/containerd/* 2>/dev/null | sort -h

Zertifikate

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | less
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -subject -issuer

Prozesse

ps aux | grep kubelet
ps aux | grep containerd
ps aux | grep kube-apiserver
sudo crictl ps -a

47. JSONPath, jq, yq, custom-columns und Templates

JSONPath-Beispiele

kubectl get pods -n demo -o jsonpath='{.items[*].metadata.name}'
kubectl get pod <pod> -n demo -o jsonpath='{.status.phase}'
kubectl get pod <pod> -n demo -o jsonpath='{.spec.nodeName}'
kubectl get secret app-secret -n demo -o jsonpath='{.data.password}' | base64 -d; echo

Liste mit Zeilenumbrüchen

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.status.phase}{"\n"}{end}'

custom-columns

kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase'
kubectl get nodes -o custom-columns='NODE:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

jq

kubectl get pods -A -o json | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, phase: .status.phase}'
kubectl get pods -A -o json | jq -r '.items[] | [.metadata.namespace, .metadata.name, .status.phase] | @tsv'

yq

yq '.spec.template.spec.containers[].image' deployment.yaml
kubectl get deployment web -n demo -o yaml | yq '.spec.template.spec.containers[].image'

Go Template

kubectl get pods -A -o go-template='{{range .items}}{{.metadata.namespace}}{{"\t"}}{{.metadata.name}}{{"\n"}}{{end}}'

48. Troubleshooting-Rezepte

Schnelle Cluster-Triage

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -100
kubectl get componentstatuses 2>/dev/null || true
kubectl get --raw /readyz?verbose

Pod Pending

kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl get nodes -o wide
kubectl describe nodes | grep -E 'Taints:|Allocatable:|Allocated resources:' -A10
kubectl get resourcequota,limitrange -n <namespace>

Typische Ursachen: zu wenig Ressourcen, Taints ohne Tolerations, NodeSelector/Affinity passt nicht, PVC nicht gebunden, Quota erreicht.

CrashLoopBackOff

kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --all-containers --previous
kubectl logs <pod> -n <namespace> --all-containers --tail=200
kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses}'

Typische Ursachen: Prozess beendet sich, falsche Config, Secret fehlt, Probe zu aggressiv, Berechtigungsproblem, Image startet nicht.

ImagePullBackOff oder ErrImagePull

kubectl describe pod <pod> -n <namespace>
kubectl get secret -n <namespace>
kubectl get serviceaccount -n <namespace> <serviceaccount> -o yaml
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Typische Ursachen: falscher Image-Name, Tag fehlt, Registry nicht erreichbar, ImagePullSecret fehlt, Rate-Limit.

Service ohne Endpoints

kubectl get svc <service> -n <namespace> -o yaml
kubectl get endpoints <service> -n <namespace> -o wide
kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<service>
kubectl get pods -n <namespace> --show-labels
kubectl describe pod -n <namespace> -l <selector>

Typische Ursachen: falscher Selector, Pods nicht Ready, falscher Portname, Pods in anderem Namespace.

DNS defekt

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100
kubectl get configmap coredns -n kube-system -o yaml
kubectl run dns-test -n <namespace> --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default.svc.cluster.local

Ingress routet nicht

kubectl get ingress -A
kubectl describe ingress <ingress> -n <namespace>
kubectl get ingressclass
kubectl get svc,ep,endpointslice -n <namespace>
kubectl get pods -A | grep -i ingress
kubectl logs -n <ingress-namespace> <ingress-controller-pod> --tail=200

Gateway Route funktioniert nicht

kubectl get gatewayclasses,gateway,httproute -A
kubectl describe gateway <gateway> -n <namespace>
kubectl describe httproute <route> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

PVC Pending

kubectl describe pvc <pvc> -n <namespace>
kubectl get storageclass
kubectl get pv
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl get pods -A | grep -i csi

Node NotReady

kubectl describe node <node>
kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide
sudo systemctl status kubelet
sudo journalctl -u kubelet -n 300 --no-pager
sudo crictl info
sudo crictl ps -a

RBAC Forbidden

kubectl auth can-i <verb> <resource> -n <namespace>
kubectl auth can-i <verb> <resource> -n <namespace> --as system:serviceaccount:<namespace>:<serviceaccount>
kubectl get role,rolebinding -n <namespace>
kubectl get clusterrole,clusterrolebinding | grep <name>

OOMKilled

kubectl describe pod <pod> -n <namespace>
kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'
kubectl top pod <pod> -n <namespace> --containers
kubectl get pod <pod> -n <namespace> -o jsonpath='{.spec.containers[*].resources}'

Rollout hängt

kubectl rollout status deployment/<deployment> -n <namespace> --timeout=60s
kubectl describe deployment <deployment> -n <namespace>
kubectl get rs,pods -n <namespace> -l app=<app>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl logs deployment/<deployment> -n <namespace> --all-containers --tail=100

API Server nicht erreichbar

kubectl cluster-info
kubectl get --raw /readyz?verbose
curl -k https://<api-server>:6443/readyz
sudo crictl ps -a | grep kube-apiserver
sudo crictl logs <apiserver-container-id>
sudo journalctl -u kubelet -n 300 --no-pager

49. Betriebs-Checklisten

Vor einer Änderung

kubectl config current-context
kubectl get namespace <namespace>
kubectl auth can-i patch deployments -n <namespace>
kubectl diff -f manifest.yaml
kubectl apply --dry-run=server -f manifest.yaml

Prüfe zusätzlich:

Ist der Cluster korrekt?
Ist der Namespace korrekt?
Gibt es ein Rollback?
Gibt es ein Backup, falls Daten betroffen sind?
Sind echte Secrets ausgeschlossen?
Sind PDBs und Kapazität ausreichend?

Nach einer Änderung

kubectl rollout status deployment/<deployment> -n <namespace> --timeout=120s
kubectl get pods -n <namespace> -o wide
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -50
kubectl logs deployment/<deployment> -n <namespace> --all-containers --tail=100
kubectl get svc,ep,endpointslice -n <namespace>

Vor Node-Wartung

kubectl get node <node> -o wide
kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide
kubectl get pdb -A
kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --timeout=10m

Nach Node-Wartung

sudo systemctl restart kubelet
kubectl uncordon <node>
kubectl get node <node> -o wide
kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -50

Vor kubeadm-Upgrade

kubectl get nodes
kubectl get pods -A
kubectl get pdb -A
sudo kubeadm upgrade plan
sudo kubeadm certs check-expiration
sudo -E etcdctl endpoint health
sudo -E etcdctl snapshot save /var/backups/etcd-before-upgrade.db

Nach kubeadm-Upgrade

kubectl get nodes -o wide
kubectl get pods -A
kubectl get --raw /readyz?verbose
kubectl top nodes
kubectl get events -A --sort-by=.lastTimestamp | tail -100

50. Quellen und weiterführende Referenzen

Kubernetes kubectl Reference: https://kubernetes.io/docs/reference/kubectl/
Kubernetes kubectl Quick Reference: https://kubernetes.io/docs/reference/kubectl/quick-reference/
Kubernetes kubeadm Reference: https://kubernetes.io/docs/reference/setup-tools/kubeadm/
Kubernetes kubelet Reference: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
Kubernetes Component Tools Reference: https://kubernetes.io/docs/reference/command-line-tools-reference/
Kubernetes crictl Debugging: https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/
Helm Commands: https://helm.sh/docs/helm/
etcd Disaster Recovery: https://etcd.io/docs/v3.5/op-guide/recovery/