Ein Helm Chart ist ein Paket für Kubernetes: Es bündelt alle Manifeste, die eine Anwendung zum Laufen braucht, zusammen mit Vorlagen, die sich über eine values.yaml an deine Umgebung anpassen lassen. Kubernetes Helm übernimmt dabei die Rolle eines Paketmanagers, ähnlich wie du es von deinem Betriebssystem kennst: Du wählst ein Paket, gibst ein paar Werte mit, und Helm bringt daraus fertige Kubernetes-Objekte in deinen Cluster.
Wer schon einmal ein Deployment, einen Service und ein Ingress-Manifest von Hand für dieselbe Anwendung in drei Umgebungen gepflegt hat, merkt schnell, warum sich Helm durchgesetzt hat. Ich betreibe produktionsreife Kubernetes-Cluster und rolle dort seit Jahren Anwendungen über Helm Charts aus, gemeinsam mit GitOps über ArgoCD. Alle meine Beiträge rund um den Betrieb von Kubernetes findest du auf der Seite Kubernetes.
Was ist ein Helm Chart in Kubernetes?
In Helm gibt es drei Begriffe, die du auseinanderhalten solltest. Ein Chart ist das Paket selbst: alle Manifeste und Vorlagen, die eine Anwendung braucht, zusammengefasst in einer Ordnerstruktur oder einem gepackten Archiv. Ein Release ist eine konkrete Installation dieses Charts in deinem Cluster, du kannst dasselbe Chart mehrfach installieren und bekommst dann mehrere unabhängige Releases, etwa für verschiedene Kunden oder Umgebungen. Ein Repository schließlich ist der Ort, an dem Charts abgelegt und verteilt werden, vergleichbar mit einem Paket-Repository für dein Betriebssystem.
Der Unterschied zu einem einfachen Ordner voller YAML-Dateien liegt im Templating: Ein Chart enthält keine fertigen Manifeste, sondern Vorlagen mit Platzhaltern, die Helm erst beim Ausrollen mit den Werten aus deiner values.yaml zu echten Kubernetes-Manifesten zusammensetzt. Genau das macht ein Chart wiederverwendbar, ohne dass du für jede Umgebung eine eigene Kopie der Manifeste pflegen musst.
Aufbau eines Helm Charts: Chart.yaml, values.yaml, templates
Führst du helm create webshop aus, legt Helm dir ein vollständiges Standard-Chart mit Beispielmanifesten an. Die Struktur sieht bei jedem Chart im Kern gleich aus:
webshop/
├── Chart.yaml
├── values.yaml
├── charts/
└── templates/
├── deployment.yaml
├── service.yaml
├── ingress.yaml
└── _helpers.tpl
In der Chart.yaml stehen Name, Version und Beschreibung des Charts, also die Metadaten, mit denen sich ein Chart in einem Repository eindeutig identifizieren lässt:
apiVersion: v2
name: webshop
description: Chart für den Webshop-Dienst
type: application
version: 0.1.0
appVersion: "1.4.0"
version ist dabei die Version des Charts selbst, appVersion die der Anwendung darin; beide zählen unabhängig voneinander hoch.
Der Ordner templates enthält die eigentlichen Kubernetes-Manifeste, angereichert mit Platzhaltern in doppelten geschweiften Klammern. Ein Ausschnitt aus dem Deployment könnte so aussehen:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-webshop
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: webshop
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
Alles innerhalb der {{ }} wertet Helm vor dem Ausrollen aus. .Release.Name ist ein eingebauter Wert und liefert den Namen des Releases, .Values.replicaCount und .Values.image kommen dagegen aus deiner values.yaml. Das Ergebnis ist ein ganz normales Kubernetes-Manifest, Kubernetes selbst sieht von der Template-Syntax nichts mehr. Wie du ein solches Chart von Grund auf selbst entwickelst, inklusive aller Template-Funktionen und Bedingungen, zeige ich ausführlich in Eigenes Helm Chart erstellen.
Ein Helm Chart installieren, aktualisieren und zurückrollen
Für die ersten Schritte reichen dir wenige Helm-Befehle. Aus dem Ordner deines Charts heraus rollst du es mit helm install zum ersten Mal aus, jedes weitere Update spielst du mit helm upgrade ein:
| Befehl |
Wirkung |
helm install webshop . |
rollt das Chart als neues Release namens webshop aus |
helm upgrade --install webshop . |
aktualisiert das Release oder legt es an, falls es fehlt |
helm history webshop |
zeigt alle bisherigen Revisionen des Releases |
helm rollback webshop 2 |
setzt das Release auf Revision 2 zurück |
helm uninstall webshop |
entfernt das Release und alle zugehörigen Objekte |
Ich nutze in Pipelines fast ausschließlich helm upgrade --install, weil ich dann nicht unterscheiden muss, ob ein Release schon existiert. Jedes Upgrade erhöht die Revisionsnummer des Releases um eins, und genau diese Historie macht helm rollback möglich: Ist ein Rollout fehlgeschlagen oder ein neuer Wert falsch, springst du mit einem einzigen Befehl auf den letzten funktionierenden Stand zurück, ohne die alten Manifeste irgendwo aufheben zu müssen.
Values überschreiben: eigene Konfiguration je Umgebung
Ein Chart liefert immer eine values.yaml mit sinnvollen Standardwerten mit, damit es sofort lauffähig ist. Für eigene Anpassungen überschreibst du diese Werte, ohne das Chart selbst zu verändern, entweder direkt über die Kommandozeile oder mit einer weiteren values-Datei:
helm upgrade --install --set image.tag=c3f1a9d webshop .
helm upgrade --install -f values-basis.yaml -f values-prod.yaml webshop .
Die values.yaml des Charts musst du dabei nicht mit -f mitgeben, sie ist immer die Grundlage; alles, was du mit --set oder einer eigenen Datei angibst, legt sich darüber. Gibst du mehrere values-Dateien an, gewinnt bei überlappenden Werten immer die zuletzt genannte Datei. Das erlaubt dir, Standardwerte, umgebungsspezifische Werte und beispielsweise team- oder regionsspezifische Werte sauber in eigenen Dateien zu trennen, statt eine einzige values.yaml mit Kommentaren vollzustopfen. Für dev, staging und prod lege ich mir typischerweise je eine schlanke values-Datei an, die nur die Unterschiede zum Standard enthält, etwa die Replikatanzahl oder das Image-Tag.
Helm Charts im GitOps-Workflow statt per Hand ausrollen
helm install und helm upgrade von der eigenen Kommandozeile aus sind praktisch zum Lernen und Testen, in produktiven Umgebungen bevorzuge ich einen anderen Weg: GitOps. Statt dass ein Mensch oder eine Pipeline den Helm-Befehl direkt gegen den Cluster ausführt, beschreibt eine ArgoCD-Application deklarativ, welches Chart mit welchen Values ausgerollt werden soll, und ArgoCD rendert und synchronisiert das selbstständig gegen den gewünschten Zustand in Git:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: webshop
spec:
project: default
source:
repoURL: https://charts.example.com
chart: webshop
targetRevision: 0.1.0
helm:
values: |
replicaCount: 3
destination:
server: https://kubernetes.default.svc
namespace: webshop
Zwei Details lohnen den Blick: project ist in einer Application Pflicht, und die Werte stehen hier direkt im values-Block, weil valueFiles bei einem Chart aus einem Chart-Repository nur Dateien innerhalb des Charts findet. Liegt dein Chart dagegen in Git, kannst du dort eine eigene values-Datei danebenlegen und sie referenzieren.
Der Unterschied ist mehr als kosmetisch: Bei helm install von der Kommandozeile weißt du nie mit letzter Sicherheit, welcher Stand tatsächlich im Cluster läuft, wenn niemand die Befehle protokolliert. Bei GitOps ist Git die einzige Quelle der Wahrheit, jede Änderung an Chart-Version oder Values läuft über einen Commit, und ArgoCD gleicht Cluster und Git kontinuierlich ab. Wie GitOps mit ArgoCD im Detail funktioniert, auch jenseits von Helm, beschreibe ich in GitOps mit ArgoCD: Deployments aus Git.
Secrets in Helm Charts sauber lösen
Der naheliegende, aber falsche Weg ist, Passwörter und Zugangsdaten direkt in einer values.yaml einzutragen und diese ins Git-Repository zu committen. Damit landet jedes Secret im Klartext in der Versionshistorie, und zwar dauerhaft, auch wenn du die Zeile später wieder entfernst. In meinen Clustern verschlüssele ich values-Dateien mit sensiblen Werten, bevor sie ins Repository kommen, und die Pipeline entschlüsselt sie erst unmittelbar vor dem Helm-Rollout. So bleibt Git die Quelle der Wahrheit, ohne dass ein Secret jemals unverschlüsselt dort landet. Alternativ setzen viele Teams auf externe Secret-Stores, aus denen Kubernetes die Werte zur Laufzeit nachlädt, statt sie überhaupt durch Helm zu schleusen.
Häufige Fragen
Was ist der Unterschied zwischen Helm und Kustomize?
Helm paketiert eine Anwendung als versioniertes Chart mit Templating-Engine und Values, Kustomize patcht dagegen reines Kubernetes-YAML ohne eigene Templatesprache, meist über Overlays für verschiedene Umgebungen. Hier geht es darum, wie ein Chart aufgebaut ist und wie du damit arbeitest; die Entscheidung zwischen beiden Werkzeugen samt Auswahlkriterien steht in Kustomize vs Helm: was wann?.
Brauche ich Helm, wenn ich ArgoCD nutze?
Nicht zwingend, ArgoCD kann auch reines YAML oder Kustomize-Overlays ausrollen. Sobald du aber fremde Anwendungen aus öffentlichen Charts installierst oder eigene Anwendungen mit vielen Umgebungen versionieren willst, ergänzen sich Helm und ArgoCD gut: Helm liefert das Paket und die Templating-Logik, ArgoCD sorgt für den GitOps-Rollout darum herum.
Wie verwalte ich Secrets in Helm Charts?
Trage niemals Klartext-Passwörter in eine values.yaml ein, die ins Repository committet wird. Verschlüssele sensible values-Dateien vor dem Commit und entschlüssele sie erst zur Rollout-Zeit, oder lade Secrets zur Laufzeit aus einem externen Secret-Store nach, statt sie durch Helm zu reichen.
Wie rolle ich ein Helm-Release zurück?
Mit helm history <release> siehst du alle bisherigen Revisionen, mit helm rollback <release> <revision> setzt du das Release auf eine davon zurück. Das funktioniert nur, solange Helm die entsprechende Revision noch in seiner Historie im Cluster gespeichert hat.
Wie du weitermachst
Der nächste Schritt ist, selbst ein Chart zu entwickeln statt nur fertige zu installieren: Templating-Funktionen, Bedingungen und eine saubere values-Struktur zeige ich Schritt für Schritt in Eigenes Helm Chart erstellen. Wenn du unsicher bist, ob Helm für deinen Anwendungsfall überhaupt das richtige Werkzeug ist, hilft dir Kustomize vs Helm: was wann? bei der Entscheidung, und für den produktiven Rollout über Git lohnt sich GitOps mit ArgoCD: Deployments aus Git.
Mein Vorschlag für den Einstieg: Installiere mit helm create ein Standard-Chart, rolle es in einem Testnamespace aus, ändere anschließend einen Wert in der values.yaml und beobachte mit helm upgrade und helm rollback, wie sich Revisionen im Cluster verhalten.
Ausführlich mit allen Template-Funktionen, Bedingungen und dem Aufbau eigener Charts, den ich hier nur angerissen habe, steht das in Kapitel 9 meines Kubernetes-Praxisbuchs bei Rheinwerk. Die vollständige Kommandoreferenz findest du in der offiziellen Helm-Dokumentation, Details zur Helm-Integration von ArgoCD in dessen Dokumentation zu Helm-Quellen.
