Was ist ein Helm Chart? Der Paketmanager für Kubernetes

Wer 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 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:

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:

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:

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:

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "my-app.fullname" . }}
{{- end }}

Oder eine Schleife über mehrere Hosts:

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:

# 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, dem zentralen Verzeichnis für öffentliche Helm Charts. Dort gibt es Charts für cert-manager, ingress-nginx, Prometheus, PostgreSQL mit Helm und Hunderte weitere Pakete.

Ein Repository hinzufügen und daraus installieren:

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:

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:

# 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 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 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:

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.