Betrieb & Monitoring
Helm
Helm ist der Paketmanager für Kubernetes: Er bündelt Manifeste als versionierbare Charts und verwaltet Installation, Upgrade und Rollback als Releases.
- CNCF, Apache-2.0
- Charts: Templates + Werte
- Releases, Upgrade, Rollback
- OCI-Registries als Repos
- Provenance/Signierung
Helm ist der Paketmanager für Kubernetes. Ein Chart bündelt zusammengehörige Manifeste mit Templates und konfigurierbaren Werten; eine Installation wird als benanntes Release verwaltet, mit Revisionen, Upgrades und Rollbacks. Helm ist ein CNCF-Graduated-Projekt unter Apache-2.0.
Dieser Artikel erklärt den Aufbau von Charts, das Templating, das Release-Konzept, OCI-Registries als Chart-Repositories, die Abgrenzung zu Kustomize und GitOps sowie die typischen Fehler beim Umgang mit Werten und Secrets.
1. Charts und Templating
Ein Chart besteht aus Chart.yaml (Metadaten, Version, Abhängigkeiten), values.yaml (Standardwerte) und templates/ (Kubernetes-Manifeste als Go-Templates, erweitert um die Sprig-Funktionen). Über --set oder eigene Werte-Dateien lassen sich Werte überschreiben; values.schema.json validiert sie. Charts können andere Charts als Abhängigkeiten einbinden, fixiert über Chart.lock.
2. Releases: Upgrade und Rollback
Jede Installation erzeugt ein Release mit eindeutigem Namen; derselbe Chart kann mehrfach parallel installiert werden. Jede Änderung (helm upgrade) erzeugt eine neue Revision, auf die sich mit helm rollback zurückspringen lässt. Den Release-Zustand speichert Helm als Secret im jeweiligen Namespace.
3. Repositories und OCI
Charts kommen aus Repositories. Klassisch basieren diese auf einer index.yaml (größtes öffentliches Verzeichnis: Artifact Hub). Moderner sind OCI-Registries als Chart-Speicher (Präfix oci://): dieselbe Registry wie für Container-Images, mit unveränderlichen Digests für reproduzierbare Referenzen, ohne zentralen Index.
4. Abgrenzung zu Kustomize und GitOps
Kustomize ist patch-basiert (Overlays auf valides YAML, in kubectl integriert) und kennt keine Releases oder Rollbacks, Helm ist template-basiert mit Release-Management; viele Teams kombinieren beides. In GitOps nutzt Argo CD Helm meist nur als Template-Engine (kein Helm-Release im Cluster), während Flux über die Custom Resource HelmRelease echte Helm-Operationen mit Lifecycle ausführt.
Keine Secrets in values.yaml
Klartext-Passwörter in values.yaml oder per --set landen base64-kodiert im Release-Secret und ggf. im Git-Verlauf, beides für Cluster-Admins lesbar. Besser: SOPS/Age (Helm-Secrets-Plugin), External Secrets Operator oder Vault. Zufallsfunktionen wie randAlphaNum erzeugen zudem bei jedem Render neue Werte und stören GitOps.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Reproduzierbare, versionierte Deployments mit Rollback | Go-Templating wird bei großen Charts schnell unübersichtlich |
| Riesiges Ökosystem an Upstream-Charts (Artifact Hub) | Fremde Charts erfordern Prüfung (Secrets, Defaults, Versionen) |
| OCI-Registries und Provenance-Signaturen für Lieferkette | Secrets-Handling muss extern gelöst werden (SOPS/Vault) |
Häufige Fragen zu Helm
Nein. Seit Helm 3 ist die serverseitige Komponente Tiller entfallen. Helm spricht direkt mit der Kubernetes-API unter den RBAC-Rechten des Nutzers, was das Sicherheitsmodell deutlich vereinfacht.
Helm ist template-basiert mit Paketierung, Versionierung und Rollback, ideal für wiederverwendbare und Upstream-Charts. Kustomize ist patch-basiert und in kubectl integriert, stark für umgebungsspezifische Anpassungen. In der Praxis werden beide oft kombiniert.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Helm im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.