Claude Code Kubernetes: YAML generieren, Deployments verwalten, Fehler debuggen

Kubernetes ist mächtig — und aufwändig. Wer zum ersten Mal ein Deployment-Manifest schreibt, stößt sofort auf ein Problem: YAML ist fehleranfällig, die Struktur ist komplex, und ein falsch gesetzter Einzug kann den gesamten Apply-Vorgang zum Scheitern bringen. Selbst erfahrene Entwickler öffnen bei jedem neuen Manifest die Kubernetes-Dokumentation neu.

Claude Code Kubernetes-Workflows verändern das grundlegend. Statt Manifeste aus der Dokumentation zusammenzukopieren und dabei Tippfehler einzubauen, beschreibst du was du brauchst — und bekommst ein sauberes, produktionsreifes Manifest zurück. Dieser Artikel zeigt, wie das konkret aussieht: von kubectl-Grundbefehlen bis zum vollständigen Helm Chart.

1. Kubernetes verstehen: Pods, Services, Deployments

Kubernetes orchestriert Container über mehrere Maschinen hinweg. Das Grundprinzip: du beschreibst den gewünschten Zustand deiner Anwendung in YAML-Manifesten — Kubernetes sorgt dafür, dass die Realität diesem Zustand entspricht. Wird ein Container abgestürzt, startet Kubernetes ihn neu. Wird ein Node unerreichbar, verschiebt Kubernetes die Pods auf andere Nodes.

Die drei wichtigsten Abstraktionen:

• Pod: Die kleinste Einheit in Kubernetes. Ein Pod enthält einen oder mehrere Container, die sich Netzwerk und Storage teilen. Pods sind flüchtig — sie werden erstellt und gelöscht, nie "gepatcht".
• Deployment: Verwaltet Pods deklarativ. Du gibst an: dieses Container-Image, diese Anzahl Replicas, diese Ressourcen-Limits. Das Deployment sorgt dafür, dass immer genau diese Anzahl Pods läuft — auch nach Abstürzen oder Node-Ausfällen.
• Service: Gibt Pods eine stabile Netzwerkadresse. Da Pods kommen und gehen, braucht man eine feste IP oder einen DNS-Namen, hinter dem Kubernetes automatisch die aktuellen Pod-IPs balanciert.

Dazu kommen ConfigMaps für nicht-sensible Konfiguration (Umgebungsvariablen, Konfigurationsdateien) und Secrets für sensible Daten wie Passwörter und API-Keys — beide entkoppeln Konfiguration vom Container-Image.

2. kubectl-Grundbefehle im Alltag

Die wichtigsten kubectl-Befehle decken 90 % des Alltags ab. Claude Code kann nicht nur Manifeste schreiben, sondern auch erklären, welcher Befehl wann sinnvoll ist — und direkte kubectl-Befehle im Terminal ausführen, wenn du Claude Code mit Bash-Zugriff betreibst.

# Manifest anwenden (idempotent — kann mehrfach ausgeführt werden)
kubectl apply -f deployment.yaml

# Laufende Pods anzeigen
kubectl get pods -n mein-namespace

# Details zu einem einzelnen Pod
kubectl describe pod mein-pod-7d9f8b-xyz -n mein-namespace

# Logs eines laufenden Pods
kubectl logs mein-pod-7d9f8b-xyz -n mein-namespace

# Logs live mitlesen
kubectl logs -f mein-pod-7d9f8b-xyz -n mein-namespace

# Deployment-Status prüfen
kubectl rollout status deployment/mein-deployment -n mein-namespace

# Rollback auf die vorherige Version
kubectl rollout undo deployment/mein-deployment -n mein-namespace

Der häufigste Fehler beim manuellen Tippen: falsche Namespace-Angaben oder das Vergessen des -n-Flags. Claude Code generiert vollständige Befehle inklusive Namespace und gibt dabei immer den Kontext mit — du kopierst, prüfst, führst aus.

Fehlerdiagnose mit describe und logs

Wenn ein Pod nicht startet, ist kubectl describe pod der erste Anlaufpunkt. Es zeigt Events: OOMKilled (zu wenig RAM), ImagePullBackOff (Image nicht gefunden), CrashLoopBackOff (Container startet und stirbt sofort). Claude Code kann die Ausgabe von kubectl describe direkt analysieren:

kubectl describe pod mein-pod-7d9f8b-xyz | claude "Was ist der Fehler und wie behebe ich ihn?"

3. Manifeste schreiben: Deployment, Service, ConfigMap, Secret

Ein vollständiges Deployment-Manifest für eine Node.js-Anwendung sieht so aus — generiert durch Claude Code auf eine einfache Beschreibung hin:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  namespace: production
  labels:
    app: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api-server
        image: meine-registry/api-server:1.4.2
        ports:
        - containerPort: 3000
        envFrom:
        - configMapRef:
            name: api-config
        - secretRef:
            name: api-secrets
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5

Beachte: Liveness- und Readiness-Probes sind kein Luxus, sondern Pflicht für produktionsreife Deployments. Claude Code fügt sie standardmäßig hinzu, wenn du nach einem "produktionsreifen Manifest" fragst. Manuell werden sie oft vergessen.

claude "Schreib ein Kubernetes-Deployment für meine Node.js-API auf Port 3000,
3 Replicas, Image meine-registry/api-server:1.4.2, Namespace production,
mit Liveness- und Readiness-Probes, Resource-Limits und ConfigMap-Referenz"

4. Helm Charts: Installation und eigene Charts erstellen

Helm ist der Paketmanager für Kubernetes. Statt rohe YAML-Manifeste zu verwalten, bündelt Helm sie in "Charts" mit konfigurierbaren Werten. Der Vorteil: dieselbe Chart-Struktur kann für Staging und Production verwendet werden — nur die values.yaml unterscheidet sich.

# Helm-Repository hinzufügen und Chart installieren
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install nginx-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2

# Eigene Chart-Struktur erstellen
helm create meine-api

# Chart mit custom Values installieren
helm install meine-api ./meine-api \
  --namespace production \
  --values ./values-production.yaml

Claude Code hilft beim Erstellen eigener Charts — besonders beim Templating, das in Helm-eigener Go-Template-Syntax geschrieben wird und fehleranfällig ist:

claude "Erstelle eine Helm Chart-Vorlage für ein Deployment mit:
- konfigurierbarer Replica-Anzahl via values.yaml
- optionalem Ingress-Block der sich per values.ingress.enabled aktivieren lässt
- HPA-Konfiguration die sich ebenfalls per values aktivieren lässt"

Das Ergebnis: sauberes Go-Template mit {{ if .Values.ingress.enabled }}-Blöcken, korrekt eingerücktem YAML und einer vollständigen values.yaml mit kommentierten Defaults.

5. Autoscaling: HPA, VPA und Cluster Autoscaler

Kubernetes bietet drei Ebenen des Autoscalings, die zusammenspielen:

• Horizontal Pod Autoscaler (HPA): Skaliert die Anzahl der Pods basierend auf CPU- oder Speicherauslastung (oder custom Metriken). Wenn die durchschnittliche CPU-Auslastung aller Pods 70 % überschreitet, fügt der HPA Pods hinzu.
• Vertical Pod Autoscaler (VPA): Passt die Ressource-Requests eines Pods automatisch an. Wenn ein Pod konsistent mehr RAM benötigt als angefordert, erhöht der VPA das Request. Nützlich für Workloads mit schwer vorhersehbarem Ressourcenbedarf.
• Cluster Autoscaler: Skaliert die Nodes selbst. Wenn der HPA mehr Pods hinzufügen will, aber kein Node genügend freie Ressourcen hat, fordert der Cluster Autoscaler beim Cloud-Provider einen neuen Node an.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Claude Code generiert HPA-Manifeste auf Anfrage — inklusive der häufig vergessenen minReplicas-Angabe, die verhindert, dass der HPA alle Pods löscht wenn die Last niedrig ist.

6. Claude Code K8s-Tipps aus dem Produktivbetrieb

Nach mehreren Monaten K8s-Arbeit mit Claude Code haben sich folgende Workflows bewährt:

YAML-Fehler sofort debuggen

Der häufigste K8s-Fehler: YAML-Syntaxprobleme die kubectl apply mit kryptischen Fehlern abbricht. Statt manuell den Einzug zu prüfen:

kubectl apply -f deployment.yaml 2>&1 | claude "Was ist der YAML-Fehler und in welcher Zeile?"

Rollouts überwachen und zurückrollen

claude "Zeig mir wie ich das Rollout von deployment/api-server in production
überwache und bei Fehlern automatisch zurückrolle"

Claude Code gibt nicht nur den Befehl, sondern erklärt auch die Kriterien: wann gilt ein Rollout als fehlgeschlagen (progressDeadlineSeconds), wie man den History-Limit konfiguriert und wie ein sicherer Rollback-Prozess aussieht.

Bestehende Cluster-Konfiguration analysieren

# Alle Deployments eines Namespaces exportieren und analysieren lassen
kubectl get deployments -n production -o yaml | claude \
  "Welche Deployments haben keine Liveness-Probes, keine Resource-Limits
   oder weniger als 2 Replicas? Liste die Probleme auf."

Das ist besonders nützlich bei übernommenen Clustern: in Minuten einen Überblick über Produktionslücken bekommen, ohne jeden Manifest manuell zu lesen.

Kosten-Optimierung durch Resource-Analyse

Kubernetes-Kosten werden durch zu großzügig gewählte Resource-Requests getrieben — Pods die viel anfordern aber wenig nutzen. Claude Code kann auf Basis von kubectl top pods-Ausgaben konkrete Empfehlungen für Resource-Anpassungen geben:

kubectl top pods -n production | claude \
  "Welche Pods haben einen großen Abstand zwischen Request und tatsächlicher Nutzung?
   Empfiehl angepasste Resource-Requests."

Der Einstieg in Kubernetes ist steil — aber mit Claude Code als Pairing-Partner wird aus dem YAML-Labyrinth ein strukturierter Workflow. Nicht weil Claude Code K8s-Experte ist, sondern weil es den Kontext deines Projekts kennt, Fehler erklärt statt nur zu benennen, und Manifeste generiert die wirklich produktionsreif sind.

• Claude Code Debugging — Fehler systematisch finden und Root-Cause-Analysen durchführen
• Claude Code für Unternehmen — Deployment, Zugriffskontrolle und Team-Workflows auf Unternehmensebene