Was ist Helm?
Helm ist der Paketmanager für Kubernetes. Mit Helm Charts lassen sich komplexe Kubernetes-Anwendungen als versionierte Pakete definieren, konfigurieren und installieren — vergleichbar mit apt oder brew, nur eben für Kubernetes-Cluster. In ArgoCD-Setups werden Helm-Charts häufig für Drittanbieter-Komponenten genutzt; eigene Anwendungen liegen oft in Kustomize. Beide Ansätze lassen sich auch kombinieren (Helm-Render via Kustomize-Post-Renderer).
Helm im ArgoCD-WorkshopHelm bündelt die typischerweise vielen einzelnen YAML-Manifeste einer Kubernetes-Anwendung — Deployment, Service, ConfigMap, Ingress — in ein versioniertes Paket namens Chart. Über eine zentrale values.yaml-Datei werden die variablen Teile parametrisiert, sodass dieselbe Anwendung mit unterschiedlichen Werten für Entwicklung, Staging und Produktion installiert werden kann, ohne die Manifeste selbst zu duplizieren.
Der technische Kern ist die Templating-Engine. Helm-Charts enthalten Platzhalter, die beim Installieren mit konkreten Werten gefüllt werden. Das ist mächtig für parametrierbare Pakete, bringt aber eine eigene Templating-Syntax mit, die bei komplexen Charts schwer lesbar werden kann. Genau hier liegt der wesentliche Unterschied zu Kustomize, das ohne Templating-Sprache auskommt.
In GitOps-Setups mit ArgoCD hat sich eine pragmatische Arbeitsteilung etabliert: Drittanbieter-Komponenten — Ingress-Controller, Cert-Manager, Monitoring-Stacks — kommen meist als fertige, gut gepflegte Helm-Charts aus öffentlichen Repositories. Eigene Anwendungen liegen dagegen oft in Kustomize, weil dort der Templating-Overhead nicht nötig ist. Beide Ansätze lassen sich über einen Kustomize-Post-Renderer sogar kombinieren.
Stolpersteine: Charts aus fremden Quellen sollten vor dem produktiven Einsatz geprüft werden, da sie tief in den Cluster eingreifen. Helm-Releases im Cluster und der Git-Stand können auseinanderlaufen, wenn nicht konsequent über GitOps gearbeitet wird. Und übermäßig generische Charts mit hunderten Konfigurationsoptionen werden in der Wartung schnell unübersichtlich.
Drittanbieter-Stack als Chart installieren
Ein Monitoring-Stack mit Prometheus und Grafana wird über das offizielle Helm-Chart installiert. Die Konfiguration — Speicher, Retention, Alerting — erfolgt über eine eigene values.yaml, das Chart selbst bleibt unverändert und einfach aktualisierbar.
Gleiche Anwendung über mehrere Umgebungen
Ein internes Chart wird mit unterschiedlichen values-Dateien für dev, stage und prod installiert. Replica-Zahl, Ressourcenlimits und Endpunkte unterscheiden sich, die zugrunde liegende Paketdefinition bleibt identisch.
- Wann nutze ich Helm und wann Kustomize?
- Helm eignet sich für parametrierbare, wiederverwendbare Pakete — besonders Drittanbieter-Komponenten mit vielen Optionen. Kustomize ist sinnvoll für eigene Manifeste, die nur leicht pro Umgebung variieren, ohne dass eine Templating-Sprache nötig ist. In der Praxis werden beide oft kombiniert.
- Wie sicher sind Charts aus öffentlichen Repositories?
- Etablierte Charts der Projekt-Maintainer sind in der Regel gut gepflegt, aber jedes Chart greift tief in den Cluster ein. Vor dem produktiven Einsatz sollte man die enthaltenen Ressourcen, RBAC-Berechtigungen und Container-Images prüfen und Versionen pinnen statt blind auf latest zu setzen.
- Kann ich Helm und Kustomize zusammen verwenden?
- Ja. Ein verbreitetes Muster ist, ein Helm-Chart zu rendern und das Ergebnis anschließend per Kustomize-Post-Renderer mit Overlays anzupassen. So nutzt man die Parametrisierung von Helm und die schlanke Overlay-Logik von Kustomize gemeinsam.
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