Helm vs. Kustomize: Kubernetes richtig konfigurieren

Wer Kubernetes-Workloads verwaltet, stößt früher oder später auf die Frage: Wie verwalte ich meine YAML-Konfigurationen über verschiedene Umgebungen (Dev, Staging, Prod) konsistent und wartbar? Zwei Tools haben sich als de-facto-Standards etabliert: Helm und Kustomize.

Das Problem: YAML-Dschungel

Kubernetes lebt von YAML-Manifesten. Ein typisches Deployment besteht aus Deployment, Service, ConfigMap, Ingress, HPA – schnell sind es Dutzende Dateien. Das Problem: Dev braucht 1 Replica, Prod 10. Staging nutzt ein anderes Image-Tag. Die Datenbank-URL variiert pro Umgebung.

Ohne Werkzeuge entstehen Copy-Paste-Hölle oder unüberschaubare Konfigurations-Drifts. Helm und Kustomize lösen dieses Problem – auf unterschiedliche Weise.

Helm: Der Kubernetes Package Manager

Helm ist der älteste und verbreitetste Ansatz. Helm nutzt Templates (Go-Template-Syntax), in denen Platzhalter durch Werte aus values.yaml ersetzt werden.

Konzept:

Chart/
  Chart.yaml         # Metadaten
  values.yaml        # Standardwerte
  values-prod.yaml   # Produktionswerte
  templates/
    deployment.yaml  # Template mit {{ .Values.replicas }}
    service.yaml

Stärken von Helm:

  • Package Manager – Charts können versioniert, geteilt und wiederverwendet werden
  • Riesiges Chart-Repository – Artifact Hub bietet tausende Community-Charts
  • Releases verwalten – helm install, helm upgrade, helm rollback
  • Hooks – Pre/Post-Install-Aktionen
  • Templating-Power – komplexe Logik in Templates möglich

Schwächen:

  • Template-Syntax kann unleserlich werden (viele {{ }}-Blöcke)
  • Debugging schwer – helm template nötig um das Ergebnis zu sehen
  • Helm Tiller (v2) war ein Sicherheitsproblem (v3 löst das)
  • Eigene Lernkurve für Go-Templates

Kustomize: Overlays ohne Templates

Kustomize verfolgt einen anderen Ansatz: Es gibt keine Templates. Stattdessen werden valide Kubernetes-YAML-Dateien als Basis verwendet und durch Overlays angepasst – Patches, die Änderungen aufsetzen.

Struktur:

base/
  deployment.yaml    # Basis-YAML
  service.yaml
  kustomization.yaml

overlays/
  prod/
    kustomization.yaml   # referenziert base + patches
    replicas-patch.yaml  # ändert replicas auf 10

Stärken von Kustomize:

  • Kein Template-Chaos – Basis-YAML ist immer valides Kubernetes-YAML
  • Seit kubectl 1.14 eingebaut – kein separates Tool nötig
  • Transparenz – man sieht immer echtes YAML
  • Einfaches Patching – Strategic Merge Patch oder JSON Patch
  • Kein Paketmanager-Overhead

Schwächen:

  • Kein eingebautes Release-Management (kein Rollback-Mechanismus)
  • Kein Package-Repository wie Helm Hub
  • Komplexe Konfigurationen erfordern viele Patch-Dateien
  • Begrenzte Logik (keine Bedingungen, Schleifen)

Direkter Vergleich

Merkmal Helm Kustomize
Ansatz Go-Templates YAML-Overlays/Patches
Lernkurve Höher Niedriger
Package-Management Ja (Charts, Rollback) Nein
In kubectl integriert Nein (separates Tool) Ja
Lesbarkeit Mittel (viel {{ }}) Hoch (plain YAML)
Kompatibilität mit GitOps Gut (mit Flux/ArgoCD) Sehr gut
Third-Party Charts Tausende auf Artifact Hub Kein Repository
Komplexe Logik Ja (Schleifen, Bedingungen) Begrenzt

Kombination: Helm + Kustomize

Ein in der Praxis beliebtes Muster: Helm für Third-Party-Charts (z.B. Ingress-Nginx, cert-manager, prometheus-stack), Kustomize für eigene Applikationen. Kustomize kann sogar Helm-Charts als Quelle verarbeiten – mit helmCharts in der kustomization.yaml.

Meine Empfehlung

  • Eigene Applikationen: Kustomize ist einfacher, lesbarer und transparent.
  • Community-Software installieren (Prometheus, ArgoCD, etc.): Helm ist unschlagbar durch die Community-Charts.
  • GitOps mit ArgoCD oder Flux: Beide Tools werden unterstützt, Kustomize ist nativ integriert.

Für eigene Deployments starte ich mit Kustomize. Wenn die Konfigurationskomplexität wächst und ich Konditionen und Schleifen brauche, wechsle ich zu Helm.