Claude Code & Helm: Kubernetes-Deployments mit Charts verwalten

Kubernetes ist mächtig — aber roh. Wer eine Applikation deployen will, schreibt YAML-Manifeste für Deployment, Service, ConfigMap, Ingress, HorizontalPodAutoscaler. Jede Umgebung (dev, staging, prod) braucht leicht andere Werte. Versionierung fehlt. Rollbacks sind mühsam. Helm löst genau das: es paketiert Kubernetes-Ressourcen in wiederverwendbare Charts, parametrisiert sie über values.yaml und verwaltet Releases mit Upgrade und Rollback.

Claude Code beschleunigt diesen Workflow erheblich — nicht weil es YAML schreibt, sondern weil es den gesamten Chart-Kontext gleichzeitig sieht: Template-Logik, Values-Struktur, Abhängigkeiten zwischen Ressourcen. Dieser Artikel zeigt, wie Helm funktioniert und wo Claude Code konkret hilft.

1. Was ist Helm?

Helm ist der Paketmanager für Kubernetes. Was apt für Debian oder npm für Node.js ist, ist Helm für Cluster: es definiert, wie eine Applikation auf Kubernetes ausgerollt wird, welche Ressourcen sie braucht, und welche Parameter sich zwischen Umgebungen unterscheiden.

Ein Helm-Paket heißt Chart. Ein Chart enthält alle Kubernetes-Manifeste einer Applikation als Templates, plus eine values.yaml mit konfigurierbaren Standardwerten. Beim Installieren füllt Helm die Templates mit den übergebenen Werten und schickt das Ergebnis an den Cluster.

• Versionierung: jede Installation ist ein Release mit Versionsnummer
• Rollback: helm rollback bringt den vorherigen Stand zurück, ohne manuelles YAML-Tracking
• Wiederverwendung: einmal geschriebene Charts lassen sich in mehreren Projekten und Umgebungen einsetzen
• Abhängigkeiten: Charts können andere Charts (Subcharts) einbinden — z.B. PostgreSQL als Abhängigkeit deiner App

2. Chart-Struktur verstehen

Ein Helm-Chart ist ein Verzeichnis mit einer klar definierten Struktur. Claude Code kennt diese Struktur und kann sie vollständig generieren — aber wichtiger ist, dass es die Beziehungen zwischen den Dateien versteht, wenn du es nach einem Problem fragst.

mein-chart/
├── Chart.yaml          # Metadaten: Name, Version, Beschreibung
├── values.yaml         # Standardwerte für alle Templates
├── charts/             # Subcharts (Abhängigkeiten)
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── ingress.yaml
    ├── configmap.yaml
    ├── _helpers.tpl    # Hilfsfunktionen (Makros)
    └── NOTES.txt       # Ausgabe nach Installation

Die Chart.yaml enthält die Pflichtfelder apiVersion, name und version. Ab Helm 3 ist apiVersion: v2 Standard. Das templates/-Verzeichnis enthält alle Kubernetes-Manifeste — aber nicht als statisches YAML, sondern als Go-Templates, die mit Werten aus values.yaml befüllt werden.

3. values.yaml mit Claude Code

Die values.yaml ist das Herzstück eines Charts: sie definiert alle Parameter, die sich zwischen Deployments unterscheiden können. Eine gut strukturierte values.yaml macht den Chart flexibel ohne die Templates unleserlich zu machen.

replicaCount: 2

image:
  repository: meine-registry.io/meine-app
  tag: "1.4.2"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  hostname: app.beispiel.de
  tls: true

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

env:
  LOG_LEVEL: info
  DATABASE_URL: ""  # wird pro Umgebung überschrieben

Claude Code hilft hier auf zwei Arten: es generiert eine initiale values.yaml aus einer Beschreibung der Applikation, und es findet Konsistenzprobleme zwischen values.yaml und den Templates — etwa wenn ein Template einen Wert referenziert, der in der Values-Datei nicht definiert ist.

claude "Analysiere meinen Chart: values.yaml referenziert DATABASE_URL,
aber in deployment.yaml sehe ich keine env-Variable dafür. Zeige wo
der Wert übergeben werden muss."

4. Eigenen Chart erstellen

Helm bietet einen Scaffold-Befehl, der die Grundstruktur erzeugt:

helm create meine-app

Das erzeugt einen vollständigen Beispiel-Chart mit Deployment, Service, Ingress und HPA. Für die meisten Projekte ist das der beste Startpunkt — nicht von null anfangen, sondern den generierten Chart anpassen.

Wo Claude Code konkret hilft: der generierte Chart enthält viele Beispiel-Kommentare und Optionen, die du nicht brauchst. Claude Code bereinigt den Chart auf deine tatsächlichen Anforderungen und erklärt dabei, was jeder Teil tut — ohne dass du die gesamte Helm-Dokumentation lesen musst.

claude "Ich habe einen neuen Chart mit 'helm create' erstellt für eine
Node.js-App mit PostgreSQL. Bereinige die Templates auf das Wesentliche
und erkläre welche Teile ich für meine Anforderungen anpassen muss."

5. Templates und Go-Template-Syntax

Helm-Templates verwenden die Go-Template-Syntax — eine eigene, manchmal eigenwillige Sprache. Die häufigsten Konstrukte:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "meine-app.fullname" . }}
  labels:
    {{- include "meine-app.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "meine-app.selectorLabels" . | nindent 6 }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          {{- if .Values.ingress.enabled }}
          ports:
            - containerPort: {{ .Values.service.port }}
          {{- end }}

Die doppelten geschweiften Klammern {{ }} kennzeichnen Template-Ausdrücke. Der führende Bindestrich {{- entfernt vorangehende Leerzeichen und Zeilenumbrüche — wichtig für korrekt formatiertes YAML. .Values referenziert Werte aus values.yaml, .Chart Metadaten aus Chart.yaml.

Die Funktion include ruft wiederverwendbare Hilfsfunktionen aus _helpers.tpl auf. nindent 4 fügt einen Zeilenumbruch vor dem Inhalt ein und rückt ihn um 4 Leerzeichen ein — notwendig für korrekte YAML-Hierarchie.

6. Helm-Repositories

Fertige Charts für gängige Dienste musst du nicht selbst schreiben. Die Community pflegt Repositories mit tausenden Charts:

# Bitnami-Repository hinzufügen (beliebt für Middleware wie PostgreSQL, Redis)
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Verfügbare Charts suchen
helm search repo bitnami/postgresql

# Chart installieren
helm install mein-postgres bitnami/postgresql \
  --set auth.postgresPassword=geheim \
  --set primary.persistence.size=10Gi

Für eigene Charts nutzt du entweder ein privates Repository (OCI-Registry wie Docker Hub oder GitHub Container Registry) oder packst den Chart als .tgz-Datei. Claude Code hilft beim Aufsetzen der Chart-Packaging-Pipeline: helm package, helm push in eine OCI-Registry, und die entsprechende CI/CD-Integration.

7. Upgrade und Rollback

Helm verwaltet Releases — und damit die History aller Deployments. Das macht Upgrades und Rollbacks zu einer einzeiligen Operation:

# Erstinstallation
helm install meine-app ./meine-app --values values-prod.yaml

# Update (neues Image-Tag oder geänderte Values)
helm upgrade meine-app ./meine-app \
  --values values-prod.yaml \
  --set image.tag=1.5.0

# Release-History anzeigen
helm history meine-app

# Rollback zur vorherigen Version
helm rollback meine-app

# Rollback zu einer bestimmten Revision
helm rollback meine-app 3

Helm speichert die gesamte Release-History als Kubernetes-Secrets im Cluster. Das bedeutet: du brauchst keinen externen State-Store, der Cluster selbst ist die Quelle der Wahrheit. Bei einem Rollback setzt Helm exakt die Kubernetes-Ressourcen zurück, die beim Ziel-Release aktiv waren.

8. Secrets mit Helm Secrets Plugin

Secrets gehören nicht in values.yaml — schon gar nicht als Klartext in Git. Das Helm Secrets Plugin löst das: es verschlüsselt sensible Values-Dateien mit SOPS (Secrets OPerationS) und entschlüsselt sie automatisch beim Deployment.

# Plugin installieren
helm plugin install https://github.com/jkroepke/helm-secrets

# Verschlüsselte Values-Datei erstellen (mit AGE oder GPG)
helm secrets enc values-secrets.yaml

# Deploy mit verschlüsselten Secrets
helm secrets upgrade meine-app ./meine-app \
  --values values.yaml \
  --values values-secrets.yaml

Die verschlüsselte Datei (values-secrets.yaml.enc) kann sicher in Git eingecheckt werden. Nur wer den entsprechenden Private Key hat, kann sie entschlüsseln. Claude Code hilft beim Aufsetzen der SOPS-Konfiguration und beim Einbinden in CI/CD-Pipelines — ein Bereich, der in der Dokumentation oft nur oberflächlich behandelt wird.

9. Helmfile für mehrere Charts

Sobald eine Umgebung aus mehreren Services besteht (App, Datenbank, Cache, Monitoring), wird das manuelle Ausführen von helm upgrade für jeden Chart mühsam. Helmfile löst das: es beschreibt alle Charts und ihre Konfiguration in einer einzigen Datei und synchronisiert alles mit einem Befehl.

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: postgresql
    namespace: datenbank
    chart: bitnami/postgresql
    version: "12.5.6"
    values:
      - values/postgresql.yaml

  - name: redis
    namespace: cache
    chart: bitnami/redis
    version: "17.11.3"
    values:
      - values/redis.yaml

  - name: meine-app
    namespace: app
    chart: ./charts/meine-app
    values:
      - values/app-{{ .Environment.Name }}.yaml

# Alle Charts synchronisieren
helmfile sync

# Nur Charts mit Änderungen deployen
helmfile apply

# Für eine bestimmte Umgebung
helmfile --environment production apply

Das {{ .Environment.Name }} in der Values-Referenz ist Helmfile-Template-Syntax — es lädt automatisch die richtige Values-Datei für die aktuelle Umgebung. Claude Code versteht diese Helmfile-Struktur und kann mehrere Charts koordiniert aufsetzen, Abhängigkeiten zwischen Services erkennen und die richtige Deployment-Reihenfolge bestimmen.

Zwei verwandte Artikel:

• Claude Code & GitHub Actions — CI/CD-Pipelines für automatische Helm-Deployments
• Claude Code für Unternehmen — Team-Workflows, Zugriffskontrolle und Deployment-Standards