Kustomize: Manifeste je Umgebung ohne Templates

Kustomize ist ein Werkzeug zur Anpassung von Kubernetes-Manifesten ohne Template-Sprache. Es ist seit Kubernetes 1.14 direkt in kubectl integriert (kubectl apply -k) und arbeitet nach einem anderen Prinzip als Helm: Statt Platzhalter in Vorlagen zu setzen, legt man unveränderte Basismanifeste vor und beschreibt in einer kustomization.yaml, welche Änderungen darübergelegt werden sollen.

Aufbau: Base und Overlays

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

Die base beschreibt die Anwendung einmal, die Overlays übernehmen sie und ändern nur, was sich unterscheidet. Eine Overlay-Datei sieht so aus:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namespace: app-prod
namePrefix: prod-
commonLabels:
  env: prod
images:
  - name: registry.example.org/team/app
    newTag: 1.4.0
patches:
  - path: replicas-patch.yaml
    target:
      kind: Deployment
      name: app

Die wichtigsten Werkzeuge

  • patches: gezielte Änderungen an Feldern, wahlweise als strategischer Merge-Patch oder als JSON-Patch. Ersetzt das frühere patchesStrategicMerge und patchesJson6902.
  • namePrefix / nameSuffix: verhindert Namenskollisionen, wenn dasselbe Base mehrfach im Cluster liegt.
  • namespace: setzt den Namespace für alle Ressourcen zentral.
  • commonLabels / labels: bringt Labels an allen Objekten an – praktisch für Auswahl und Kostenauswertung. Labels mit includeSelectors steuert, ob sie auch in Selektoren landen.
  • images: ersetzt Repository und Tag, ohne Manifeste von Hand zu bearbeiten.
  • configMapGenerator / secretGenerator: erzeugen ConfigMaps aus Dateien und hängen einen Inhalts-Hash an den Namen. Dadurch starten Pods bei geänderter Konfiguration neu – ein sehr eleganter Weg, den klassischen „Konfiguration geändert, Pod läuft noch alt“-Fehler zu vermeiden.
  • components: optionale Bausteine, die nur bei Bedarf eingebunden werden – etwa ein Ingress oder ein Monitoring-Sidecar.

Ansehen und Anwenden

# Render-Ergebnis prüfen, ohne etwas anzuwenden
kubectl kustomize overlays/prod
# oder eigenständig:
kustomize build overlays/prod

# Anwenden
kubectl apply -k overlays/prod

# Änderungen gegenüber dem Cluster sehen
kubectl diff -k overlays/prod

Vergleich mit Helm

Helm ist ein Paketmanager: Es erzeugt Manifeste aus Vorlagen, verwaltet Releases und unterstützt Rollbacks. Kustomize ist ein Renderer: Es erzeugt fertiges YAML und kennt keinen Zustand – die Verwaltung übernimmt kubectl oder ein GitOps-Werkzeug. Für fremde Anwendungen mit vielen Einstellmöglichkeiten ist Helm meist bequemer; für eigene Manifeste und Umgebungsvarianten ist Kustomize die transparentere Lösung, weil kein Template-Code versteckt wird. In der Praxis werden beide kombiniert: Ein Kustomize-Overlay kann ein Helm-Chart als Basis einbinden.

Verwandte Grundlagen: Kubernetes, Helm, Argo CD, Flux.