Das Problem

Du hast eine Anwendung in Kubernetes deployed. Irgendetwas funktioniert nicht. Du führst kubectl get pods aus – der Pod ist da. Du schaust dir ReplicaSets an – auch vorhanden. Aber welches ReplicaSet gehört zu welchem Deployment? Was wird gelöscht, wenn du diese Ressource entfernst?

Ohne das richtige Tool jagst du ownerReferences manuell durch YAML-Output – langsam und fehleranfällig. Besonders nervig, wenn mehrere Apps einen Namespace teilen oder alte ReplicaSets von früheren Rollouts noch herumliegen.

kubectl tree

kubectl tree ist ein kubectl-Plugin (Ahmet Alp Balkan), das die Ownership-Hierarchie zwischen Kubernetes-Objekten als ASCII-Baum darstellt. Es folgt dem ownerReferences-Feld auf API-Objekten und zeigt dir Eltern-Kind-Beziehungen auf einen Blick.

Statt mehrerer Befehle:

kubectl get replicaset
kubectl get pods
kubectl describe replicaset my-app-7d9f8b6c4

bekommst du das:

kubectl tree deployment/web -n shop-staging

NAMESPACE  NAME                    READY  REASON
shop-staging
└─ Deployment/web
   ├─ ReplicaSet/web-7f9c8d4b5
   │  └─ Pod/web-7f9c8d4b5-xk2j9
   └─ ReplicaSet/web-6a1b2c3d4
      └─ Pod/web-6a1b2c3d4-m9p0q

Der alte ReplicaSet kann noch einen Pod haben, wenn ein Rollout hängt oder gerade läuft. Der Baum macht das sichtbar, ohne drei YAML-Dateien zu öffnen.

Was ownerReferences sind

Kubernetes setzt Owner, wenn ein Objekt ein anderes erzeugt oder steuert. Ein Deployment besitzt seine ReplicaSets; ein ReplicaSet seine Pods. Viele höher liegende Objekte folgen dem Muster (Jobs → Pods, CronJobs → Jobs, manche CRDs → Kinder).

kubectl tree zeigt nur, was die API in ownerReferences speichert — keine Beziehungen allein aus Labels. Wenn dein Operator nur über Labels verknüpft, wirkt der Baum flach oder unvollständig. Das ist ein Hinweis auf das Modell der App, kein Plugin-Fehler.

Plugin installieren (Krew)

Der übliche Weg ist Krew, der Plugin-Manager für kubectl:

kubectl krew version
kubectl krew install tree
kubectl tree --help

Ist Krew noch nicht installiert, die offizielle Anleitung für dein OS nutzen und den Krew-Pfad in der Shell setzen wie dokumentiert. Auf gemeinsamen Maschinen lieber user-lokal installieren als heimlich Binaries nach /usr/local/bin zu kopieren.

Grundlegende Nutzung

Das Plugin braucht ein Objekt, das du schon identifiziert hast — oft ein Deployment oder ein hängender Pod:

kubectl tree deployment/web -n shop-staging
kubectl tree pod/web-7f9c8d4b5-xk2j9 -n shop-staging

Alle Namespaces, wenn du nur den Namen kennst:

kubectl tree deployment/web -A

Mit Label-Selector, wenn die App über mehrere Deployments mit gemeinsamen Labels verteilt ist:

kubectl tree --selector app=web -n shop-staging

Kontext und Namespace zuerst prüfen — gleiche Gewohnheit wie bei kubectl get. Ein perfekter Baum im falschen Cluster ist trotzdem falsch.

Wann ich es nutze

Vor dem Löschen. „Was verschwindet mit diesem Deployment?“ Der Baum zeigt owned ReplicaSets und Pods. Unabhängige Objekte mit demselben Image oder ConfigMap sind keine Kinder — die bleiben.

Bei Rollout-Verwirrung. Mehrere ReplicaSets, Pods in Terminating, ein Service mit Labels ohne ready Pod — der Baum beantwortet „was gehört zu diesem Controller?“ schneller als manuelles Sortieren von kubectl get rs.

In Tickets und für Erklärungen. Ein kleiner Baum im Incident ist oft klarer als drei Screenshots von kubectl get.

Es ersetzt nicht kubectl describe (Events, Conditions), kubectl logs oder Metriken. Ein gesunder Baum kann trotzdem einen crashenden Container oder eine kaputte Probe verbergen.

Grenzen

  • Nur Owner-Ketten. Geschwister über Labels, Services oder Ingress-Backends erscheinen nicht als Kinder.
  • CRDs und Operatoren sind uneinheitlich. Manche setzen ownerReferences korrekt, manche nicht. Stoppt der Baum früh, Kinder trotzdem mit get und describe prüfen.
  • Große Namespaces → breite Ausgabe. Mit -n, einem bekannten Wurzelobjekt oder --selector eingrenzen.
  • RBAC wie bei kubectl. Kein get auf einen Typ — kein Baum dafür.

Ergänzung zur üblichen Reihenfolge

Meine Debugging-Reihenfolge bleibt: Kontext und Namespace, dann get, describe, logs. kubectl tree kommt dazu, wenn die Frage Besitz ist — nach Helm-Upgrades, GitOps-Syncs oder manuellen Eingriffen mit extra ReplicaSets.

Wer kubectl-Gewohnheiten aufbaut, findet auf dieser Site zuerst kubectl-Grundlagen für Einsteiger. Tree ist ein kleines Plugin darauf.

Schluss

Du brauchst nicht dutzende kubectl-Plugins. kubectl tree lohnt sich, weil Besitz leicht vergessen wird und sich aus YAML mühsam rekonstruiert. Einmal installieren, nutzen wenn Beziehungen zählen — und Pods weiter mit describe lesen, wenn sie sich falsch verhalten. Der Baum zeigt Struktur; Events und Logs zeigen Verhalten.