Helm ist der etablierte Paketmanager für Kubernetes. Es bündelt die vielen YAML-Manifeste einer Anwendung – Deployments, Services, ConfigMaps, Secrets und mehr – in einem Chart: einem versionierten, wiederverwendbaren Paket, das sich mit wenigen Befehlen installieren, aktualisieren und zurücksetzen lässt. Ohne Helm verwaltet man jede Ressource als einzelne Datei und muss Versionsstände selbst koordinieren.
Wie ein Chart aufgebaut ist
Ein Helm-Chart ist ein Verzeichnis mit festen Bausteinen:
- Chart.yaml: Metadaten wie Name, Version und Abhängigkeiten.
- values.yaml: die Standardwerte, die pro Installation übersteuert werden können.
- templates/: die eigentlichen Kubernetes-Manifeste, die mit Go-Templates – inklusive Schleifen und Bedingungen – aus den Werten erzeugt werden.
- charts/: eingebettete Unter-Charts als Abhängigkeiten (zum Beispiel eine Datenbank neben der Web-App).
Da Templates und YAML kombiniert werden, lässt sich dieselbe Chart-Vorlage für Test- und Produktionsumgebungen nutzen: Die Unterschiede stecken in den Werten, nicht in kopierten Manifestsammlungen.
Von Helm 2 zu Helm 3
Helm entstand 2015 bei Deis und wurde 2018 ein CNCF-Projekt. Mit Helm 3 (2019) wurde die serverseitige Komponente Tiller entfernt: Helm arbeitet seitdem rein clientseitig und greift direkt über die Kubernetes-API auf den Cluster zu. Das verbesserte die Sicherheit erheblich, weil keine privilegierte Komponente im Cluster mehr mit eigenen Rechten läuft.
Typischer Arbeitsablauf
Charts liegen in Repositories; die zentrale Such- und Verteilplattform ist der CNCF-betriebene Artifact Hub. Typische Befehle sind helm repo add, helm search repo, helm install, helm upgrade, helm rollback, helm list und helm uninstall. Eine installierte Instanz eines Charts heißt Release – so lassen sich mehrere Umgebungen aus demselben Chart mit unterschiedlichen Werten betreiben. Werte werden per -f values-datei.yaml oder --set übersteuert.
Abgrenzung
Kubernetes orchestriert Container und kümmert sich um Skalierung und Ausfallsicherheit; Helm bündelt und versioniert die dazugehörigen Ressourcen-Definitionen – vergleichbar mit der Rolle von apt oder dnf für Softwarepakete auf einem Betriebssystem. Auch Docker-Images selbst werden nicht von Helm verwaltet, sondern aus einem Container-Registry gezogen; ein Chart referenziert sie nur. Für den Betrieb von Kubernetes-Pods und Diensten bleibt Helm damit die Standard-Schicht für Applikations-Deployments – unabhängig davon, ob die zugrunde liegende Infrastruktur klassisch per Terraform oder quelloffen mit OpenTofu provisioniert wird.