Helm Charts erklärt: Kubernetes-Anwendungen einfach verwalten

Stand: 04.10.2026

Helm Charts erklärt: Mit Helm paketierst und installierst du Kubernetes-Anwendungen reproduzierbar. Ein Chart bündelt Vorlagen, Standardwerte und Metadaten; Helm erzeugt daraus Kubernetes-Manifeste und verwaltet sie als Release. So ersetzt du wiederkehrendes YAML-Kopieren durch nachvollziehbare Deployments.

Auf einen Blick

• Ein Helm Chart beschreibt eine Anwendung samt konfigurierbaren Werten.
• Ein Release ist eine konkrete Installation eines Charts in einem Cluster.
• values.yaml trennt Konfiguration von den Templates.
• Prüfe Änderungen vor dem Ausrollen mit helm lint und helm template.
• Nutze vertrauenswürdige Quellen und halte Chart-Versionen bewusst fest.

Was sind Helm Charts?

Helm ist ein Paketmanager für Kubernetes. Ein Helm Chart ist dabei ein Paketformat, das die Ressourcen einer Anwendung beschreibt. Statt Deployment, Service und weitere Objekte für jedes Umfeld neu zu pflegen, verwendest du Templates und übergibst passende Werte.

Helm rendert die Templates lokal und sendet die resultierenden Manifeste an die Kubernetes-API. Die installierte Instanz heißt Release. Deshalb kannst du dasselbe Chart etwa als shop-dev und shop-prod mit unterschiedlichen Einstellungen einsetzen.

Wie ist ein Chart aufgebaut?

Ein neu angelegtes Chart hat eine klare Grundstruktur. Chart.yaml enthält Name, Version und weitere Metadaten. values.yaml liefert Standardwerte. Im Ordner templates liegen die Kubernetes-Vorlagen. Abhängigkeiten können außerdem in Chart.yaml definiert werden.

meine-app/
├── Chart.yaml
├── values.yaml
├── charts/
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── _helpers.tpl

Templates verwenden die Go-Template-Sprache und Helm-Funktionen. Ein Wert aus values.yaml erscheint zum Beispiel als {{ .Values.image.tag }}. Gib Werte lieber strukturiert über eine Datei weiter, statt viele einzelne --set-Parameter in Skripten zu verstecken. Das ist lesbarer und lässt sich besser prüfen.

Wie installierst du Helm und ein erstes Chart?

Installiere Helm über den Paketmanager deiner Plattform oder folge der offiziellen Installationsanleitung. Prüfe danach zuerst die installierte Client-Version. Anschließend fügst du ein Repository hinzu, aktualisierst den lokalen Index und installierst ein Chart als Release.

1. Installiere Helm mit einem für dein System passenden, offiziellen Weg.
2. Füge eine bekannte Chart-Quelle hinzu und aktualisiere die Metadaten.
3. Installiere eine konkrete Chart-Version und gib einen Release-Namen an.
4. Kontrolliere Status und erzeugte Ressourcen im Namespace.

helm version
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-nginx bitnami/nginx --namespace demo --create-namespace
helm status my-nginx --namespace demo

Ein Repository ist nicht die einzige Bezugsquelle: Helm unterstützt auch OCI-Registries. Für produktive Abläufe ist wichtig, die Chart-Version festzulegen. Damit verhindert du, dass ein späterer Lauf unbemerkt eine andere Paketversion installiert.

Wie erstellst und testest du ein eigenes Chart?

Mit helm create erhältst du ein Grundgerüst. Entferne anschließend Vorlagen, die du nicht brauchst, und passe values.yaml sowie die Ressourcen an deine Anwendung an. Starte klein: Ein Deployment und ein Service reichen für den ersten Durchlauf.

1. Erzeuge das Grundgerüst.
2. Trage Image, Port und Replikazahl als Werte ein.
3. Referenziere diese Werte in den Templates.
4. Prüfe die Chart-Struktur und rendere die Manifeste vor der Installation.
5. Installiere zunächst in einem eigenen Test-Namespace.

helm create meine-app
helm lint ./meine-app
helm template meine-app ./meine-app --namespace test
helm install meine-app ./meine-app --namespace test --create-namespace

helm lint findet typische Chart-Probleme. helm template zeigt dir die gerenderten YAML-Manifeste, ohne sie anzuwenden. Ergänze bei Änderungen außerdem helm upgrade --install erst nach dieser Prüfung. So erkennst du falsche Namen, fehlende Werte oder unerwartete Ressourcen frühzeitig.

Wie funktionieren Updates und Rollbacks?

Wenn sich Chart oder Werte ändern, aktualisierst du den Release mit helm upgrade. Helm speichert die Release-Historie. Du kannst deshalb den Verlauf ansehen und bei Bedarf auf eine frühere Revision zurückrollen. Ein Rollback ersetzt jedoch keine fachliche Prüfung: Datenbankmigrationen oder externe Änderungen können zusätzliche Schritte verlangen.

helm upgrade my-nginx bitnami/nginx --namespace demo --version <CHART-VERSION>
helm history my-nginx --namespace demo
helm rollback my-nginx <REVISION> --namespace demo

Prüfe nach jedem Update den Release-Status und die Pods. Für eine verständliche Einführung in die Grundlagen verlinkt unser Artikel Kubernetes und Minikube einfach erklärt. Wenn deine Konfiguration aus Compose stammt, hilft dir auch die Anleitung Docker Compose zu Kubernetes migrieren.

Welche Best Practices machen Charts wartbar und sicher?

Halte Anwendungscode, Chart und Umgebungskonfiguration getrennt. Dokumentiere alle unterstützten Werte in einer README.md und setze sinnvolle Defaults. Verwende eindeutige Labels und Namenshilfen, damit mehrere Releases nicht kollidieren.

• Lege Image-Tags und Chart-Versionen fest; vermeide unbestimmte Produktionsstände.
• Übergebe keine Geheimnisse im Klartext über values.yaml oder die Kommandozeile.
• Prüfe gerenderte Manifeste gegen die Richtlinien deines Clusters.
• Nutze für abhängige Charts bewusst definierte Versionen.
• Teste Upgrades in einer Staging-Umgebung, bevor du Produktion änderst.

Helm ersetzt weder RBAC noch Network Policies oder Image-Scans. Es liefert aber einen wiederholbaren Weg, diese Ressourcen gemeinsam mit der Anwendung zu versionieren. Ergänzend zeigt dir unser Beitrag zu Dockerfile Best Practices, wie du schon beim Container-Image auf schlanke und sichere Grundlagen achtest.

Wann sind Helm Charts die richtige Wahl?

Helm eignet sich besonders, wenn du dieselbe Anwendung in mehreren Umgebungen betreibst, viele Kubernetes-Ressourcen zusammen ausrollst oder Konfiguration versionieren willst. Für sehr kleine, einmalige Manifeste kann pures YAML übersichtlicher sein. Entscheidend ist, dass dein Team Templates und Werte nachvollziehen kann.

In GitOps-Workflows liegen Chart-Version und Werte üblicherweise im Git-Repository. Ein Controller wie Argo CD oder Flux kann daraus den gewünschten Cluster-Zustand ableiten. Trotzdem bleibt die Verantwortung bei dir: Prüfe Pull Requests, begrenze Berechtigungen und beobachte das Ergebnis nach dem Abgleich.

Welche Fehler solltest du vermeiden?

Der häufigste Fehler ist eine unklare Trennung zwischen Code und Umgebung. Lege deshalb nicht für jede Umgebung ein fast identisches Chart an. Nutze ein gemeinsames Chart und übergib Unterschiede über versionierte Value-Dateien, etwa values-dev.yaml und values-prod.yaml.

Vermeide außerdem, alle Einstellungen mit --set zu übergeben. Einzelne Änderungen sind dafür praktisch, doch lange Befehle lassen sich schlecht reviewen und werden leicht falsch kopiert. Werte-Dateien machen Änderungen im Git-Verlauf sichtbar. Dadurch erkennst du auch schneller, welche Konfiguration tatsächlich ausgerollt wurde.

Installiere fremde Charts nicht blind. Lies die Dokumentation, rendere die Ressourcen und prüfe, welche Berechtigungen, Images oder Services entstehen. Aktualisiere Abhängigkeiten kontrolliert und teste jede neue Chart-Version in einer passenden Umgebung. So bleibt Helm ein Werkzeug für verlässliche Releases statt eine Quelle schwer erklärbarer Änderungen.

Fazit

Helm Charts machen Kubernetes-Anwendungen wiederholbar installierbar und einfacher konfigurierbar. Beginne mit einem kleinen eigenen Chart, rendere und prüfe es lokal und pinne Versionsstände. Dann werden Updates, Tests und Rollbacks deutlich nachvollziehbarer als bei verstreuten YAML-Dateien.

Quellen

• Helm-Dokumentation: Charts
• Helm-Dokumentation: Installation
• Helm-Dokumentation: Chart Template Guide

Häufige Fragen