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.

Weiterführende Artikel

Verwandte Technologien im Techradar