kubectl neat: Kubernetes YAML Output aufräumen

Das Problem

Du willst ein Deployment inspizieren. Du führst aus:

kubectl get deployment my-app -o yaml

Und bekommst so etwas:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "3"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment", ... 300 weitere Zeilen JSON ...}
  creationTimestamp: "2026-04-12T08:23:11Z"
  generation: 5
  managedFields:
  - apiVersion: apps/v1
    fieldsType: FieldsManager
    fieldsV1:
      ... 80 Zeilen Field-Manager-Daten die niemand gebraucht hat ...
  resourceVersion: "4829103"
  uid: a3f2c891-bc12-4d7e-9f1a-003b22e81cc4
spec:
  ...

Der eigentliche Spec den du brauchst ist begraben unter Schichten von auto-generiertem Metadata, Managed Fields, Last-Applied-Configurations und Status-Blöcken.

Das ist der rohe Kubernetes API-Output. Er ist vollständig. Er ist für die meisten Zwecke auch vollständig unlesbar.

kubectl neat

kubectl neat entfernt das gesamte Kubernetes-generierte Rauschen und gibt dir das saubere, menschenlesbare YAML zurück – so wie du es selbst schreiben würdest.

Dasselbe Deployment, nach neat:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.4.2
        ports:
        - containerPort: 8080

Das ist alles. Sauber, lesbar, verwendbar.

Es ändert nichts am laufenden Cluster – nur, was du auf stdout oder in einer Datei siehst.

Installation

Via krew:

kubectl krew install neat

Via Homebrew:

brew install kubectl-neat

Mit kubectx & kubens vom richtigen Cluster exportieren; kubectl tree für Ownership, neat für das Manifest selbst.

Grundlegende Verwendung

# Deployment aufräumen
kubectl get deployment my-app -o yaml | kubectl neat

# Pod aufräumen
kubectl get pod my-app-7d9f8b6c4-xk2p9 -o yaml | kubectl neat

# Beliebige Ressource aufräumen
kubectl get <ressource> <name> -o yaml | kubectl neat

# Sauberes YAML in Datei speichern
kubectl get deployment my-app -o yaml | kubectl neat > my-app-clean.yaml

# Kurzschreibweise als Subcommand
kubectl neat get deployment my-app

Was wird entfernt?

kubectl neat entfernt Felder, die Kubernetes automatisch hinzufügt und die du beim Lesen oder Kopieren eines Manifests fast nie brauchst:

• managedFields – internes Field-Tracking für Server-Side Apply
• creationTimestamp – Erstellungszeitpunkt der Ressource
• resourceVersion – interne Versionierung
• uid – von Kubernetes zugewiesener eindeutiger Identifier
• generation – Revisionszähler
• annotations mit kubectl.kubernetes.io/last-applied-configuration – der vollständige JSON-Blob des zuletzt angewendeten Zustands
• status-Block – der aktuelle Laufzeitstatus (kein Teil des gewünschten Specs)

Was bleibt: alles was du selbst geschrieben hast – deine Labels, dein Spec, deine Container-Definitionen, deine Resource Requests.

Wann ist das wirklich nützlich?

Manifests auf einen neuen Cluster kopieren: Ressource exportieren, mit neat aufräumen, anderswo anwenden. Kein manuelles Bearbeiten von 15 auto-generierten Feldern.

Code Reviews: Einen sauberen YAML-Diff teilen statt einer Wand von auto-generiertem Rauschen.

Dokumentation: Runbooks oder interne Docs mit echten lesbaren Manifests schreiben.

Lernen: Beim Erkunden eines unbekannten Clusters zeigt neat-Output was wichtig ist – nicht was Kubernetes intern hinzugefügt hat.

Spec-Probleme debuggen: Bei einer Fehlkonfiguration ist das Lesen des sauberen Specs viel schneller als das Scrollen durch Managed Fields.

Live-Debugging bleiben stern und k9s; neat ist fürs Manifest.

kubectl neat vs kubectl get -o yaml

Zusammenfassung

Kleines Tool. Massive Verbesserung der Lebensqualität. Innerhalb einer Woche nach der Installation wirst du alles durch neat pipen.