--- title: 'Was ist ein Helm Chart? Der Paketmanager für Kubernetes' description: 'Helm Charts bündeln Kubernetes-Ressourcen in ein versioniertes Paket. So sind sie aufgebaut, so funktioniert das Templating und so setzt du sie sinnvoll ein.' image: src: /images/blog/what-is-a-helm-chart.jpg authors: - name: Thomas Ens to: /about/thomasens avatar: src: /images/blog/authors/thomas.jpeg date: 2026-04-08 tags: lastUpdated: 2026-04-13 published: true --- Wer [Kubernetes](/de/blog/what-is-kubernetes) ernsthaft betreibt, kennt das Problem: Eine Applikation besteht aus einem Deployment, einem Service, einer ConfigMap, vielleicht einem HorizontalPodAutoscaler und einem Ingress. Macht fünf YAML-Dateien, pro Umgebung. Und schon hat man ein Verwaltungsproblem. Helm Charts sind die Standardantwort auf diese Komplexität. Sie bündeln alle Kubernetes-Ressourcen einer Anwendung in ein versioniertes, konfigurierbares Paket. Dieser Artikel erklärt, wie Helm Charts aufgebaut sind, wie das Templating funktioniert und wann du sie sinnvoll einsetzen kannst. ## Was ist Helm und was ist ein Chart? [Helm](https://helm.sh/de/) ist der Paketmanager für Kubernetes. Wenn du dir apt für Debian, Homebrew für macOS oder npm für Node.js vorstellst, bist du konzeptionell nah dran. Helm installiert, aktualisiert und deinstalliert Anwendungen auf einem Kubernetes-Cluster und hält dabei den Zustand der Installationen im Blick. Ein Helm Chart ist das Paketformat, das Helm verwendet. Es ist im Kern eine Sammlung von Dateien in einer definierten Verzeichnisstruktur, die zusammen beschreiben, was auf dem Cluster deployt werden soll, parametrisiert über eine zentrale Konfigurationsdatei. Der entscheidende Vorteil gegenüber rohem YAML: Statt für jede Umgebung eigene Kopien zu pflegen, definierst du einmal die Struktur und passt per Werte-Datei oder CLI-Parameter an, was sich unterscheidet. ## Aufbau eines Helm Charts Ein frisch erstellter Chart sieht so aus: ``` my-app/ ├── Chart.yaml ├── values.yaml ├── charts/ └── templates/ ├── deployment.yaml ├── service.yaml ├── _helpers.tpl └── NOTES.txt ``` ### Chart.yaml Diese Datei enthält die Metadaten des Charts: ```yaml apiVersion: v2 name: my-app description: A Helm chart for my application type: application version: 0.1.0 appVersion: "1.2.3" ``` `version` ist die Version des Charts selbst – also des Pakets. `appVersion` beschreibt die Version der Anwendung, die deployt wird. Beide sind unabhängig voneinander und sollten getrennt versioniert werden. ### values.yaml Hier liegen die Standardwerte für alle konfigurierbaren Parameter: ```yaml replicaCount: 2 image: repository: my-registry/my-app tag: "1.2.3" pullPolicy: IfNotPresent service: type: ClusterIP port: 80 ``` Diese Werte sind der Kontrollpunkt für alles, was sich zwischen Umgebungen unterscheidet. Wer für Produktion andere Replikazahlen oder ein anderes Image-Tag braucht, überschreibt nur diese Datei, die Templates bleiben unverändert. ### Das templates/-Verzeichnis Hier liegen die eigentlichen Kubernetes-Manifeste, allerdings mit Platzhaltern statt fester Werte: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "my-app.fullname" . }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "my-app.selectorLabels" . | nindent 6 }} template: spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ``` Die doppelten geschwungenen Klammern `{{ }}` sind Go-Template-Syntax. `.Values` greift auf values.yaml zu, `.Chart` auf Chart.yaml. ## Wie Helm-Templating funktioniert Helm nutzt die Go-Template-Engine, ergänzt um eine Reihe von Zusatzfunktionen aus der Sprig-Bibliothek. Das gibt dir Möglichkeiten wie Bedingungen, Schleifen, String-Manipulationen und eigene Hilfsfunktionen. Ein einfaches Beispiel mit einer Bedingung: ```yaml {{- if .Values.ingress.enabled }} apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: {{ include "my-app.fullname" . }} {{- end }} ``` Oder eine Schleife über mehrere Hosts: ```yaml rules: {{- range .Values.ingress.hosts }} - host: {{ .host | quote }} http: paths: {{- range .paths }} - path: {{ .path }} {{- end }} {{- end }} ``` Eigene Hilfsfunktionen landen in `_helpers.tpl`. Die Datei beginnt mit einem Unterstrich, damit Helm sie nicht als eigenständiges Manifest behandelt. Dort definierst du benannte Templates, die du in den anderen Dateien per `include` einbindest. Mit `helm template my-app ./my-app` kannst du dir das fertig gerenderte YAML lokal ausgeben lassen, nützlich zum Debuggen, bevor du etwas auf den Cluster loslässt. ## Helm-Befehle im Alltag Die wichtigsten Operationen: ```bash # Chart installieren helm install my-release ./my-app # Mit eigenen Werten überschreiben helm install my-release ./my-app -f production-values.yaml # Upgrade einer bestehenden Installation helm upgrade my-release ./my-app --set image.tag=1.3.0 # Installieren oder upgraden (idempotent, gut für CI) helm upgrade --install my-release ./my-app # Status einer Installation anzeigen helm status my-release # Alle Releases auflisten helm list # Rollback auf eine frühere Version helm rollback my-release 1 # Deinstallieren helm uninstall my-release ``` Helm speichert den Zustand jeder Installation als Release im Cluster (als Secret oder ConfigMap) und verwaltet Revisionen. Das ermöglicht das Rollback auf eine frühere Version mit einem einzigen Befehl. ## Chart-Repositories und Artifact Hub Fertige Charts für gängige Software findest du auf [Artifact Hub](https://artifacthub.io), dem zentralen Verzeichnis für öffentliche Helm Charts. Dort gibt es Charts für cert-manager, ingress-nginx, Prometheus, [PostgreSQL mit Helm](/de/blog/postgresql-helm-chart-kubernetes) und Hunderte weitere Pakete. Ein Repository hinzufügen und daraus installieren: ```bash helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install ingress-nginx ingress-nginx/ingress-nginx ``` Für eigene Charts kannst du ein privates Repository betreiben, klassisch als statischer HTTP-Server mit einem `index.yaml`, oder moderner als OCI-Registry. Seit Helm 3.8 ist OCI-Support stabil, und viele Teams nutzen ihre bestehende Container-Registry gleichzeitig für Charts und Images. ## Helm Chart erstellen. Eigene Anwendung deployen Einen neuen Chart anlegen: ```bash helm create my-app ``` Das erzeugt die vollständige Verzeichnisstruktur mit Beispiel-Templates für ein Deployment inkl. Service, Ingress, HPA und ServiceAccount. Der generierte Code ist funktional und ein guter Ausgangspunkt. Danach passt du `values.yaml` an deine Anwendung an und bereinigst die Templates um alles, was du nicht brauchst. Testen lässt sich das mit: ```bash # Rendering prüfen helm template my-release ./my-app -f my-values.yaml # Lint-Check helm lint ./my-app # Dry-run gegen den Cluster helm install my-release ./my-app --dry-run ``` Bevor du einen Chart produktiv einsetzt, lohnt sich ein Blick auf `helm lint`, der prüft auf häufige Fehler in Chart-Struktur und Templates. ## Helm vs. Kustomize. Wann was? Beide Werkzeuge lösen das Problem der YAML-Verwaltung in Kubernetes, aber mit unterschiedlichem Ansatz. [Kustomize](/de/blog/what-is-kustomize) arbeitet mit Overlays: Du hast eine Basis-Konfiguration und überlagerst sie umgebungsspezifisch, ohne Templates oder Variablen. Es ist näher an purem YAML und kommt ohne eigene DSL aus. Seit kubectl 1.14 ist es direkt integriert. Helm setzt auf Templating und Paketierung. Es ist mächtiger für komplexe Konfigurationen, hat aber eine steilere Lernkurve und mehr Moving Parts. Faustregeln aus der Praxis: - Du deployest fremde Software (cert-manager, Prometheus, etc.)? Helm, weil die Maintainer das als Chart liefern. - Du verwaltest eigene Apps mit vielen Umgebungen und Konfigurationsunterschieden? Helm funktioniert gut, Kustomize ist aber oft übersichtlicher. - Du willst GitOps-kompatibel bleiben und Plain-YAML bevorzugen? Kustomize. - Du brauchst Rollback-Funktionalität und Release-Tracking? Helm. Viele Teams kombinieren beides: Helm zum Installieren externer Charts, Kustomize für die eigene Applikationskonfiguration. Beide Werkzeuge sind Teil eines größeren Themas, das wir im Artikel zu [lesbarer Kubernetes-Konfiguration](/de/blog/simplify-kubernetes-configuration) aufgreifen. ## Helm in CI/CD und GitOps In CI/CD-Pipelines ist `helm upgrade --install` der Standardbefehl, er installiert, wenn noch nichts da ist, und upgradet sonst. Das macht Pipelines idempotent: ```bash helm upgrade --install my-app ./chart \ --namespace production \ --create-namespace \ --set image.tag=$CI_COMMIT_SHA \ -f environments/production/values.yaml ``` In GitOps-Setups mit ArgoCD oder Flux wird Helm nativ unterstützt. ArgoCD kann direkt auf Chart-Repositories zeigen und Helm-Releases als Application-Ressourcen verwalten. Flux bringt dafür den `HelmRelease`-Custom-Resource-Typ mit. Der Vorteil: Der gewünschte Zustand liegt im Git-Repository, der Cluster gleicht sich automatisch ab. Für Secrets in Helm gibt es verschiedene Ansätze: das Helm Secrets Plugin (arbeitet mit SOPS oder Vault), External Secrets Operator oder direkt mit einem Secret-Store-CSI-Driver. Werte mit Passwörtern oder API-Keys gehören nicht unverschlüsselt in values.yaml, das ist einer der häufigsten Sicherheitsfehler beim Helm-Einsatz. --- Helm Charts sind heute der De-facto-Standard für strukturierte Kubernetes-Deployments – sowohl für Standardsoftware als auch für eigene Anwendungen. Der Einstieg ist überschaubar: `helm create` erzeugt einen funktionalen Chart in Sekunden, und die Konzepte von Templating und Releases erschließen sich schnell in der Praxis. Wer Kubernetes auf einer Plattform betreibt, die Helm nativ unterstützt, profitiert zusätzlich: **lowcloud** bietet eine Kubernetes-Umgebung, in der Helm-Deployments direkt funktionieren, ohne Infrastrukturaufwand drumherum. Das lässt Teams sich auf den eigentlichen Chart-Inhalt konzentrieren, statt auf Cluster-Management.