Veröffentlicht am

Kustomize vs Helm: Kubernetes-Konfiguration im Vergleich

Teilen:
Authors

TL;DR

Helm nutzt Templating mit Go-Templates und verwaltet Releases als Pakete. Kustomize arbeitet ohne Templates — es patcht und überlagert plain YAML. Helm eignet sich für komplexe Anwendungen mit vielen Konfigurationsvarianten, Kustomize für einfache Overlays pro Umgebung. Beide lassen sich kombinieren.

Kustomize vs Helm: Derselbe Deployment, zwei Wege

Die Frage „Kustomize oder Helm?" kommt in jedem Kubernetes-Projekt. Statt abstrakter Vergleiche zeigen wir beide Tools am gleichen Beispiel: ein Nginx-Deployment mit Service und Ingress, konfiguriert für Staging und Production.

Ausgangspunkt — dieses Deployment wollen wir verwalten:

# Das Ziel: Nginx mit unterschiedlicher Konfiguration pro Umgebung
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 50m
              memory: 64Mi

Weg 1: Kustomize

Kustomize ist seit kubectl v1.14 eingebaut. Kein Extra-Tool nötig — kubectl apply -k reicht.

Die Verzeichnisstruktur:

web-app/
├── base/
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── staging/
    │   ├── kustomization.yaml
    │   └── replicas-patch.yaml
    └── production/
        ├── kustomization.yaml
        └── production-patch.yaml

Die Base enthält die unveränderten Manifeste:

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
commonLabels:
  app.kubernetes.io/managed-by: kustomize

Für Production patchen wir Replicas und Resources:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: prod-
namespace: production
patches:
  - path: production-patch.yaml

# overlays/production/production-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: nginx
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              memory: 512Mi

Deployment:

# Staging
kubectl apply -k overlays/staging/

# Production
kubectl apply -k overlays/production/

# Vorschau ohne Apply
kubectl kustomize overlays/production/

Weg 2: Helm

Helm nutzt Go-Templates. Dieselbe Anwendung als Helm Chart:

web-app-chart/
├── Chart.yaml
├── values.yaml
├── values-staging.yaml
├── values-production.yaml
└── templates/
    ├── deployment.yaml
    └── service.yaml

Das Deployment-Template:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-web-app
  labels:
    app: {{ .Release.Name }}-web-app
    helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}-web-app
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-web-app
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Values pro Umgebung:

# values-production.yaml
replicas: 3
image:
  repository: nginx
  tag: "1.27"
service:
  port: 80
  type: ClusterIP
resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    memory: 512Mi

Deployment:

# Staging
helm install web-staging ./web-app-chart -f values-staging.yaml -n staging

# Production
helm upgrade --install web-prod ./web-app-chart -f values-production.yaml -n production

# Vorschau ohne Install
helm template web-prod ./web-app-chart -f values-production.yaml

Direktvergleich

KriteriumKustomizeHelm
InstallationsbedarfKeiner (in kubectl enthalten)Helm CLI nötig
AnsatzPatch/Overlay auf plain YAMLGo-Templating
LernkurveFlachSteil (Go-Templates)
PaketverwaltungNeinJa (Releases, Rollback, Repos)
AbhängigkeitenNeinJa (Subcharts, Dependencies)
Conditionals/LoopsNeinJa (if, range, with)
Community-PaketeNeinTausende Charts auf ArtifactHub
GitOps-KompatibilitätExzellent (reines YAML)Gut (mit helm template)
DebuggingEinfach (YAML bleibt lesbar)Schwieriger (Template-Rendering)

Wann welches Tool?

Kustomize wählen, wenn:

  • Du einfache Umgebungsunterschiede hast (Replicas, Namespaces, Labels)
  • Dein Team kein Helm kennt und schnell starten will
  • Du mit ArgoCD oder Flux arbeitest (native Kustomize-Unterstützung)
  • Die Manifeste überschaubar bleiben (unter 10 Ressourcen)

Helm wählen, wenn:

  • Du komplexe Anwendungen mit vielen Konfigurationsoptionen verpackst
  • Du Releases verwalten und Rollbacks machen willst
  • Du Community Charts nutzen oder eigene Charts verteilen möchtest
  • Du Conditionals brauchst (Feature X nur in Production aktivieren)

Beide kombinieren

Die Tools schließen sich nicht aus. Ein gängiges Muster: Helm Charts mit Kustomize-Overlays nachbearbeiten.

# Helm Chart rendern, dann mit Kustomize patchen
helm template my-release bitnami/nginx --values custom-values.yaml > base/nginx.yaml
kubectl apply -k overlays/production/

ArgoCD unterstützt diesen Workflow nativ — du gibst ein Helm Chart als Source an und definierst Kustomize-Patches darüber. Das ist besonders nützlich bei Third-Party-Charts, deren Values nicht alle Anpassungen abdecken.

FAQ

Kann Kustomize alles, was Helm kann?

Nein. Kustomize hat keine Conditionals, keine Loops und keine Paketverwaltung. Wenn du if-Bedingungen oder Schleifen in Templates brauchst, führt kein Weg an Helm vorbei.

Ist Kustomize schneller als Helm?

In der Ausführung kaum messbar unterschiedlich. Kustomize hat den Vorteil, dass kein Extra-Tool installiert werden muss. Im CI/CD-Kontext spart das eine Dependency.

Was ist mit Helmfile?

Helmfile ist ein Wrapper um Helm, der mehrere Releases deklarativ verwaltet. Es löst ein anderes Problem — nicht Kustomize vs Helm, sondern wie du viele Helm-Releases orchestrierst.

Welches Tool empfehlen ArgoCD und Flux?

Beide unterstützen Kustomize und Helm nativ. ArgoCD erlaubt sogar die Kombination in einer Application. Die Wahl des Tools hat keinen Einfluss auf die GitOps-Plattform.

Soll ich bei einem neuen Projekt Kustomize oder Helm nehmen?

Starte mit Kustomize, wenn deine Anwendung wenige Ressourcen hat und du nur Umgebungsunterschiede brauchst. Wechsle zu Helm, sobald du Conditionals, Loops oder Paketverwaltung benötigst. Der Wechsel ist kein Drama — die YAML-Basis bleibt verwendbar.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kontakt aufnehmenKontakt aufnehmen
Diskutieren auf Twitter

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

Termin buchenKontakt aufnehmen

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen

Alle Artikel durchsuchen