Wann nutzt man Kustomize statt Helm?
Kustomize nutzen Sie statt Helm, wenn Ihre Konfiguration pro Umgebung nur in überschaubaren Punkten wie Replica-Zahl, Ressourcenlimits oder Endpunkten variiert und Sie ohne Templating-Sprache auskommen wollen. Das nativ in kubectl integrierte Tool legt dazu per overlays/ deklarative Patches über eine gemeinsame base/, statt wie Helm Templates mit Platzhaltern zu rendern. Für hochgradig parametrierbare Drittanbieter-Pakete mit hunderten Optionen bleibt Helm die bessere Wahl. In ArgoCD-Setups werden beide oft kombiniert. Mit kubectl kustomize prüfen Sie das gerenderte YAML vorab, kubectl apply -k wendet es direkt auf den Cluster an.
Auch bekannt als: kubectl kustomize · Kustomize Overlays · kustomization.yaml
Ist Kustomize bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Kustomize arbeitet ohne Platzhalter und ohne Templating-Sprache. Es nimmt vollständige, gültige Kubernetes-Manifeste als Basis und verändert sie über Overlays. Eine base/-Definition enthält die gemeinsame Konfiguration. Pro Umgebung legt ein Verzeichnis unter overlays/ gezielt Patches darüber, etwa eine andere Replica-Zahl für Produktion oder zusätzliche Annotationen. Die Datei kustomization.yaml listet in jedem Verzeichnis, welche Ressourcen und Patches dazugehören. Die Basis bleibt dabei unangetastet.
Kustomize ist seit kubectl 1.14 nativ enthalten (kubectl apply -k), es braucht also kein zusätzliches Werkzeug. Basis und Overlays bleiben jederzeit gültiges, lesbares YAML. Jede Datei lässt sich einzeln verstehen, ohne eine Template-Logik im Kopf aufzulösen. Das senkt die Einstiegshürde und erleichtert Code-Reviews.
Für Patches kennt Kustomize zwei Formate. Ein Strategic Merge Patch sieht aus wie ein Ausschnitt des Ziel-Manifests und enthält nur die Felder, die sich ändern sollen. Listen wie Container oder Umgebungsvariablen führt Kustomize dabei über deren Namen zusammen. Ein JSON-6902-Patch beschreibt dagegen einzelne Operationen wie add, replace oder remove auf einem genauen Pfad. Er ist ausführlicher, eignet sich aber für Änderungen, die ein Merge nicht ausdrücken kann, etwa das Entfernen eines Listeneintrags.
Bei sehr vielen Umgebungen oder tief verschachtelten Overlays wird auch Kustomize unübersichtlich, und für komplexe Fallunterscheidungen fehlt die Logik einer Templating-Sprache. Tückisch ist das Zusammenführen über Namen. Soll ein Patch eine Umgebungsvariable überschreiben und enthält ihr Name einen Tippfehler, legt Kustomize still eine zweite Variable an, und der alte Wert bleibt aktiv. Für wiederverwendbare, optionale Bausteine über mehrere Overlays hinweg gibt es Kustomize Components. Sie schließen einen Teil der Lücke zur Parametrisierung, ohne eine Templating-Sprache einzuführen.
Umgebungs-Overlays für dev, stage und prod
Eine base/-Definition beschreibt die Anwendung neutral. Drei Overlays setzen darauf auf, dev mit einer Replica und Debug-Logging, stage mit Testdaten-Konfiguration, prod mit drei Replicas und produktiven Ressourcenlimits. Eine Änderung an der Basis erreicht alle drei Umgebungen mit einem Commit.
Standortspezifische Anpassung ohne Duplikation
Mehrere Werksstandorte teilen sich eine gemeinsame Basis. Pro Standort passt ein Overlay nur die abweichenden Endpunkte und Labels an. Die kompletten Manifeste existieren damit genau einmal statt einmal pro Standort.
Kustomize oder Helm für Ihre Manifeste?
Kustomize patcht reines YAML per Overlay, Helm setzt auf Templates — welcher Ansatz passt, hängt an Ihren Umgebungen und Ihrem Team. Zwei Klicks geben die Richtung.
Wie unterscheiden sich Ihre Umgebungen?
- Was ist Kustomize?
- Kustomize ist ein Konfigurations-Werkzeug für Kubernetes, das Manifeste ohne Templating-Sprache anpasst. Eine gemeinsame base/ wird per overlays/ pro Umgebung (Dev, Staging, Prod) deklarativ variiert. Kustomize ist nativ in kubectl integriert (kubectl apply -k) und gilt als templatefreie Alternative zu Helm.
- Wie nutze ich kubectl kustomize?
- kubectl kustomize rendert die Manifeste eines Overlays und gibt das fertige YAML aus, ohne es anzuwenden. Das eignet sich für Reviews und Debugging. kubectl apply -k wendet das Ergebnis direkt auf den Cluster an. Beide Befehle nutzen die in kubectl eingebaute Kustomize-Version, die eigenständige kustomize-CLI ist meist aktueller und bietet zusätzliche Funktionen.
- Kustomize vs. Helm: Was ist der Unterschied?
- Helm arbeitet mit einer Templating-Sprache und Platzhaltern, Kustomize mit Patches auf vollständigen, gültigen Manifesten. Als Faustregel gilt Kustomize für eigene Anwendungen mit überschaubaren Umgebungsunterschieden und Helm für stark parametrierbare Pakete, typischerweise Drittanbieter-Komponenten mit vielen Optionen. In ArgoCD-Setups werden beide oft kombiniert, Kustomize für eigene Workloads, Helm für externe Komponenten.
- Kann man Kustomize und Helm zusammen nutzen?
- Ja, das ist ein verbreitetes Muster. Man rendert ein Helm-Chart und passt das Ergebnis anschließend per Kustomize über Overlays an, in Helm 4 über ein Post-Renderer-Plugin. Umgekehrt kann Kustomize ein Chart selbst einbinden und mit dem Flag --enable-helm rendern, ArgoCD aktiviert das über eine Einstellung in der ConfigMap argocd-cm. Ein Entweder-oder ist die Entscheidung Kustomize vs. Helm also nur selten.
- Wann stößt Kustomize an seine Grenzen?
- Sobald komplexe Logik oder umfangreiche Parametrisierung nötig ist, etwa Hunderte konfigurierbare Optionen oder bedingte Strukturen, ist Helm meist die bessere Wahl. Auch bei sehr vielen, tief verschachtelten Overlays leidet die Übersichtlichkeit.
- Wird Kustomize noch aktiv weiterentwickelt?
- Ja. Kustomize wird von der Kubernetes SIG CLI gepflegt und ist als kubectl apply -k fester Bestandteil von kubectl, ein Wegfall ist damit nicht zu erwarten. Die in kubectl eingebettete Version läuft der eigenständigen kustomize-CLI allerdings oft hinterher. Wer neuere Funktionen nutzen möchte, ruft die separate CLI mit kustomize build direkt auf.
Wo steht Ihr Team bei Kustomize?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Kustomize: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Kubernetes SIG CLIKustomize Referenz(externe Seite, öffnet in neuem Tab)
Vollständige Referenz der Felder von kustomization.yaml.
- /02kustomize.ioKustomize(externe Seite, öffnet in neuem Tab)
Projektseite mit dem Grundgedanken, Manifeste ohne Templating zu überlagern.
- /03KubernetesObjekte mit Kustomize verwalten(externe Seite, öffnet in neuem Tab)
Aufgabenorientierte Anleitung zu Bases, Overlays und Patches.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance