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).
Auch bekannt als: Helm Charts · Kubernetes-Paketmanager · Helm 3
Ist Helm 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.
Ein Helm Chart ist ein Verzeichnis mit festem Aufbau. Die Datei Chart.yaml enthält Name und Version des Charts, values.yaml die Standardwerte, und im Ordner templates/ liegen die Kubernetes-Manifeste mit Platzhaltern. Helm füllt die Platzhalter mit den Werten und schickt das Ergebnis an die Kubernetes-API. Dieselbe Anwendung lässt sich so mit einer eigenen Werte-Datei je Umgebung installieren, ohne die Manifeste zu kopieren.
Die Platzhalter folgen der Template-Syntax von Go, ergänzt um Funktionen für Bedingungen, Schleifen und Textbearbeitung. Damit lassen sich sehr flexible Pakete bauen. Bei großen Charts wird das Template aber schwer lesbar, weil YAML-Einrückung und Template-Logik ineinandergreifen. Kustomize kommt ohne diese Sprache aus und verändert fertige Manifeste über Patches.
In GitOps-Setups mit ArgoCD hat sich eine Arbeitsteilung eingespielt. Drittanbieter-Komponenten wie Ingress-Controller, Cert-Manager oder Monitoring-Stacks kommen als gepflegte Helm-Charts aus öffentlichen Repositories. Eigene Anwendungen liegen oft in Kustomize, weil der Templating-Aufwand dort nicht nötig ist. ArgoCD rendert Charts übrigens mit helm template und wendet das Ergebnis selbst an. Ein Helm-Release entsteht dabei nicht, und helm list zeigt solche Anwendungen nicht an.
Seit November 2025 ist Helm 4 verfügbar. Es unterstützt Server-Side Apply und behandelt Post-Renderer als Plugins. Wer bisher mit --post-renderer ein beliebiges Skript aufgerufen hat, muss es für Helm 4 als Plugin verpacken. Helm 3 erhält noch bis 11. November 2026 Sicherheitsupdates, Bugfixes gab es nur bis Juli 2026.
Charts aus fremden Quellen greifen tief in den Cluster ein und gehören vor dem produktiven Einsatz geprüft. Helm-Releases im Cluster und der Git-Stand laufen auseinander, sobald jemand am GitOps-Prozess vorbei helm upgrade aufruft. Und übermäßig generische Charts mit Hunderten Konfigurationsoptionen werden in der Wartung schnell unübersichtlich.
Monitoring-Stack über das offizielle Chart
Ein Team hatte Prometheus und Grafana einmal von Hand installiert und scheute seitdem jedes Update. Jetzt kommt der Stack über das offizielle Helm-Chart, Speicher, Retention und Alerting stehen in einer eigenen values.yaml. Das Chart selbst bleibt unverändert, ein Update ist eine neue Chart-Version in der Konfiguration.
Ein Chart für dev, stage und prod
Drei Kopien derselben Manifeste liefen über Monate auseinander, bis in Produktion ein anderes Ressourcenlimit stand als getestet. Ein internes Chart wird jetzt mit je einer values-Datei für dev, stage und prod installiert. Replica-Zahl, Ressourcenlimits und Endpunkte unterscheiden sich, die Paketdefinition ist dieselbe.
Helm oder Kustomize für Ihre Manifeste?
Helm und Kustomize verwalten Kubernetes-Manifeste auf gegensätzliche Art — Templating gegen Patchen. Zwei Klicks zeigen, welcher Weg bei Ihnen weniger Reibung erzeugt.
Wie sehen Ihre Manifeste aus?
- Was ist ein Helm Chart?
- Ein Helm Chart ist ein versioniertes Paket, das alle Kubernetes-Manifeste einer Anwendung bündelt, etwa Deployment, Service, ConfigMap und Ingress. Über eine zentrale values.yaml lassen sich die variablen Teile parametrisieren, sodass dasselbe Chart mit unterschiedlichen Werten in Entwicklung, Staging und Produktion installiert wird.
- Was macht helm install?
- helm install installiert ein Chart als benanntes Release in einen Kubernetes-Cluster. Dazu lädt Helm das Chart aus einem Repository, einer OCI-Registry oder einem lokalen Verzeichnis und rendert die Templates mit den übergebenen Werten. Dann legt es die Ressourcen im Cluster an und speichert einen Release-Datensatz, standardmäßig als Secret im Namespace des Releases. Auf diesen Datensatz beziehen sich später helm upgrade und helm rollback.
- Wann nutze ich Helm und wann Kustomize?
- Helm eignet sich für parametrierbare, wiederverwendbare Pakete, besonders für Drittanbieter-Komponenten mit vielen Optionen. Kustomize ist sinnvoll für eigene Manifeste, die pro Umgebung nur leicht variieren und keine Templating-Sprache brauchen. 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. Prüfen Sie vor dem produktiven Einsatz die enthaltenen Ressourcen, RBAC-Berechtigungen und Container-Images. Pinnen Sie Chart- und Image-Versionen, statt auf latest zu setzen.
- Kann ich Helm und Kustomize zusammen verwenden?
- Ja. Ein verbreitetes Muster rendert ein Helm-Chart und passt das Ergebnis anschließend per Kustomize an. In Helm 3 geht das über --post-renderer mit einem Skript, in Helm 4 muss der Post-Renderer als Plugin vorliegen. Alternativ bindet Kustomize das Chart selbst ein und rendert es mit dem Flag --enable-helm.
Wo steht Ihr Team bei Helm?
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 Helm: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01HelmHelm Documentation(externe Seite, öffnet in neuem Tab)
Offizielle Dokumentation zu Installation, Releases, Upgrades und Rollbacks.
- /02HelmCharts(externe Seite, öffnet in neuem Tab)
Aufbau eines Charts mit Templates, Values und Abhängigkeiten.
- /03CNCFArtifact Hub(externe Seite, öffnet in neuem Tab)
Verzeichnis veröffentlichter Charts mit Signaturen und Sicherheitsberichten.
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