Was ist Helm?

Lernziele

Nach dieser Lektion kannst du erklären, welches Problem Helm löst, was Charts, Releases und Repositories sind und wie ein helm install unter der Haube abläuft. Du kennst den Unterschied zwischen Helm 2 und Helm 3, kannst Helm gegen Kustomize und plain YAML abgrenzen und weißt, wann welches Tool die bessere Wahl ist.

Das Problem: YAML skaliert nicht

Stell dir vor, du deployst eine Anwendung auf Kubernetes. Du brauchst ein Deployment, einen Service, eine Ingress-Ressource, eine ConfigMap, vielleicht noch ein ServiceAccount und ein HorizontalPodAutoscaler. Das sind schnell 300 Zeilen YAML — für eine Anwendung in einer Umgebung.

Jetzt kommt Staging dazu. Und Produktion. Die unterscheiden sich in Replica-Anzahl, Ressourcen-Limits, Hostnamen und Image-Tags. Kopierst du die YAML-Dateien dreimal? Dann hast du drei Kopien, die auseinanderdriften. Beim nächsten Update vergisst du eine, und Staging läuft mit einer anderen Probe-Konfiguration als Produktion. Genau dieser Drift verursacht die Sorte Incidents, bei der hinterher niemand sagen kann, seit wann der Unterschied existiert.

Und es wird schlimmer: Wie installierst du Drittsoftware wie PostgreSQL, Prometheus oder ingress-nginx? Deren Manifeste selbst zu schreiben und zu pflegen ist unrealistisch — der kube-prometheus-stack besteht aus hunderten Ressourcen.

Helm löst beide Probleme: Templating für eigene Anwendungen und Paketierung für die Verteilung — deshalb der Slogan „Package Manager für Kubernetes”. Die Analogie zu apt oder brew passt erstaunlich gut: versionierte Pakete, zentrale Repositories, Installation mit einem Befehl, Upgrades und Deinstallation inklusive.

Die drei Kernkonzepte

Helm hat genau drei Begriffe, die du sicher beherrschen musst. Alles andere baut darauf auf.

Chart — das Paket. Ein Chart ist ein Verzeichnis (oder ein .tgz-Archiv) mit einer festen Struktur: Chart.yaml enthält Metadaten wie Name und Version, values.yaml die konfigurierbaren Standardwerte, und unter templates/ liegen Kubernetes-Manifeste mit Go-Template-Platzhaltern. Statt replicas: 3 steht dort replicas: {{ .Values.replicaCount }}. Das Chart ist die Blaupause — es läuft nirgendwo, es beschreibt nur, was installiert werden kann.

Release — die installierte Instanz. Wenn du helm install my-nginx bitnami/nginx ausführst, rendert Helm die Templates mit den Values, schickt die fertigen Manifeste an die Kubernetes-API und merkt sich das Ganze als Release namens my-nginx. Wichtig: Aus einem Chart können mehrere Releases entstehen — nginx-team-a und nginx-team-b aus demselben Chart, mit unterschiedlichen Values, friedlich nebeneinander im Cluster. Jedes Upgrade erzeugt eine neue Revision, und mit helm rollback kommst du zu jeder früheren Revision zurück.

Repository — die Verteilstation. Ein Chart-Repository ist im Kern ein HTTP-Server mit einer index.yaml und den Chart-Archiven. Du fügst es mit helm repo add hinzu und suchst darin mit helm search repo. Artifact Hub ist die zentrale Suchmaschine über tausende öffentliche Repositories. Seit Helm 3.8 können Charts auch als OCI-Artefakte in Container-Registries wie Harbor oder GHCR liegen — in neuen Setups ist das inzwischen der bevorzugte Weg, weil Charts dann dieselbe Infrastruktur nutzen wie Container-Images (gleiche Registry, gleiche Zugriffskontrolle, gleiches Signing mit cosign).

Was bei helm install wirklich passiert

Diese Frage trennt in Interviews die Kandidaten, die Helm nur benutzt haben, von denen, die es verstanden haben. Der Ablauf:

1. Helm lädt das Chart (lokal, aus dem Repo-Cache oder aus einer OCI-Registry).
2. Die Values werden zusammengeführt: values.yaml aus dem Chart als Basis, darüber deine -f my-values.yaml, darüber einzelne --set-Flags. Spätere Quellen gewinnen.
3. Die Template-Engine rendert alle Dateien unter templates/ zu fertigem YAML.
4. Helm validiert die Manifeste gegen die Kubernetes-API und legt sie an — in einer sinnvollen Reihenfolge (Namespaces und CRDs vor Deployments, die sie brauchen).
5. Der Release-State — gerenderte Manifeste, verwendete Values, Revision — wird als Secret im Zielnamespace gespeichert (Typ helm.sh/release.v1).

Punkt 5 ist der unterschätzte: Helm hat keine eigene Datenbank und keinen Controller im Cluster. Der gesamte Zustand liegt in diesen Secrets. Deshalb funktioniert helm rollback auch ohne Git — die alte Revision liegt komplett im Secret. Und deshalb kann ein helm list in einem Namespace leer aussehen, obwohl dort Helm-verwaltete Ressourcen laufen: Du schaust schlicht in den falschen Namespace.

Eine ehrliche Einschränkung gehört dazu: Helm ist imperativ. Es wird nur aktiv, wenn jemand helm install oder helm upgrade aufruft. Ändert jemand danach mit kubectl edit Ressourcen am Chart vorbei, merkt Helm das nicht — es gibt keine kontinuierliche Reconciliation. Genau diese Lücke füllen GitOps-Tools wie Argo CD und Flux, die Helm-Charts rendern und den Zielzustand dann dauerhaft überwachen.

Helm 2 vs. Helm 3 — warum das noch gefragt wird

Helm 2 hatte eine Server-Komponente im Cluster: Tiller. Tiller nahm Anfragen vom CLI entgegen und legte Ressourcen an — und brauchte dafür in der Praxis fast immer cluster-admin-Rechte. Jeder, der mit Tiller sprechen konnte, konnte damit faktisch alles im Cluster tun. Ein Albtraum für Multi-Tenant-Umgebungen und der meistgenannte Kritikpunkt an Helm überhaupt.

Helm 3 (Ende 2019) hat Tiller ersatzlos gestrichen. Das CLI spricht direkt mit der Kubernetes-API und nutzt deine kubeconfig — du kannst per Helm exakt das tun, was deine RBAC-Rechte erlauben, nicht mehr. Außerdem wanderte der Release-State von ConfigMaps im kube-system in Secrets im jeweiligen Zielnamespace, und Release-Namen müssen nur noch pro Namespace eindeutig sein statt clusterweit.

Warum solltest du das 2026 noch wissen? Weil die Frage „Was war Tiller und warum wurde er entfernt?” ein beliebter Interview-Klassiker ist, um zu prüfen, ob du das Security-Modell von Helm verstehst — und weil „Komponente mit zu breiten Rechten durch Client-seitige RBAC-Delegation ersetzen” ein Architekturmuster ist, das weit über Helm hinaus relevant bleibt.

Helm vs. Kustomize vs. plain YAML

Die Abgrenzungsfrage kommt fast immer. Eine belastbare Antwort:

• Plain YAML reicht für kleine, statische Setups: ein Team, eine Umgebung, eine Handvoll Services. Kein Tooling, keine Abstraktion, maximal nachvollziehbar. Bricht zusammen, sobald Umgebungen sich unterscheiden.
• Kustomize arbeitet ohne Templates: Eine Base mit fertigen Manifesten, darüber Overlays mit Patches pro Umgebung. Es ist in kubectl eingebaut (kubectl apply -k) und das gerenderte Ergebnis bleibt gut lesbar, weil keine Template-Logik im YAML steckt. Was Kustomize nicht kann: Pakete bauen und verteilen. Es gibt kein „Kustomize-Repository”, keine Versionierung, kein install/rollback.
• Helm glänzt, wenn du Software paketieren und verteilen willst — an andere Teams, andere Cluster oder die Öffentlichkeit — oder wenn die Konfigurationsvielfalt echte Logik braucht (Conditionals, Loops, abgeleitete Werte). Der Preis: Go-Templates in YAML sind schwer zu lesen und zu debuggen, und übertrieben „flexible” Charts mit 800 Values-Optionen sind ein bekanntes Anti-Pattern.

In der Praxis ist es selten ein Entweder-oder. Ein verbreitetes Muster: Drittsoftware kommt als Helm-Chart, eigene Anwendungen nutzen ein schlankes, selbst gepflegtes Standard-Chart der Plattform — und Argo CD oder Flux rendern beides im GitOps-Flow. Manche Teams kombinieren sogar direkt: Helm rendert, Kustomize patcht hinterher das, was das Chart nicht konfigurierbar macht.

Wenn du im Interview so antwortest — Kriterien statt Tool-Religion, plus ein Hybrid-Szenario — bist du sofort glaubwürdiger als mit „Helm ist halt Standard”.

Praxis: in 15 Minuten zum ersten Release

Am besten in einem lokalen Cluster (kind oder minikube):

# Repository hinzufügen und durchsuchen
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo bitnami/nginx

# Installieren — mit einem überschriebenen Value
helm install my-nginx bitnami/nginx --set replicaCount=2

# Was ist entstanden?
helm list
kubectl get deploy,svc,secret -l app.kubernetes.io/instance=my-nginx
kubectl get secret -l owner=helm   # der Release-State

# Upgrade → neue Revision, dann Rollback
helm upgrade my-nginx bitnami/nginx --set replicaCount=3
helm history my-nginx
helm rollback my-nginx 1

# Aufräumen
helm uninstall my-nginx

Zwei Dinge solltest du dabei bewusst anschauen: das Release-Secret (kubectl get secret -l owner=helm) — damit hast du den Speicherort des States einmal selbst gesehen — und helm history nach dem Rollback. Du wirst feststellen: Ein Rollback erzeugt eine neue Revision (Revision 3 mit dem Stand von Revision 1), die Historie wird nie zurückgespult.

Wer tiefer einsteigen will: helm template bitnami/nginx | less zeigt dir das gerenderte YAML, ohne irgendetwas zu installieren — das wichtigste Debugging-Werkzeug überhaupt, dazu mehr in Lektion 7.

Typische Stolperfallen

„Helm list ist leer, aber die App läuft” — falscher Namespace. Release-State liegt im Zielnamespace; helm list -A zeigt alle.

Values-Drift durch --set: Wer Werte per --set auf der Kommandozeile setzt, hat sie nirgendwo dokumentiert. Beim nächsten Upgrade durch eine Kollegin fehlen sie. Regel: Values gehören in eine versionierte Datei, --set ist für Experimente.

Manuelle Änderungen am Release vorbei: kubectl edit an einem Helm-verwalteten Deployment überlebt das nächste helm upgrade nicht — oder kollidiert damit. Wenn das Chart etwas nicht hergibt, gehört die Änderung ins Chart oder in die Values, nicht ins Live-Objekt.

CRDs: Helm installiert CRDs aus dem crds/-Verzeichnis nur beim ersten Install und fasst sie bei Upgrades nie wieder an — eine bewusste Sicherheitsentscheidung, die regelmäßig Leute überrascht, deren Operator-Upgrade „nicht greift”.

Interview-Vorbereitung

Die Standardfrage „Was ist Helm?” beantwortest du am stärksten in dieser Reihenfolge: Problem (YAML-Duplikation über Umgebungen, Verteilung komplexer Software) → Lösung in einem Satz (Package Manager: Templating + Paketierung + Release-Verwaltung) → die drei Konzepte (Chart = Blaupause, Release = Instanz mit Revisionen, Repository = Verteilung) → eine Grenze (imperativ, kein Drift-Detection — daher die Kombination mit GitOps).

Rechne mit diesen Follow-ups:

• „Wo speichert Helm seinen State?” — Secrets im Zielnamespace, kein eigener Controller.
• „Warum wurde Tiller entfernt?” — Security: cluster-admin-Komponente ersetzt durch Client-seitige RBAC über kubeconfig.
• „Helm oder Kustomize?” — Kriterien nennen (Paketierung vs. Patching, Lesbarkeit vs. Logik), Hybrid-Realität erwähnen.
• „Was passiert bei helm rollback genau?” — neue Revision mit altem Stand, Historie bleibt vollständig.

Wenn du diese vier ohne Zögern beantworten kannst, sitzt die Lektion.

Zusammenfassung

Helm ist der Package Manager für Kubernetes: Charts paketieren Manifeste als Templates mit konfigurierbaren Values, Releases sind installierte, versionierte Instanzen mit Rollback-Fähigkeit, Repositories (zunehmend OCI-Registries) verteilen die Pakete. Helm 3 spricht direkt mit der Kubernetes-API und respektiert deine RBAC-Rechte; der Release-State liegt in Secrets im Zielnamespace. Helm ist imperativ — kontinuierliche Reconciliation liefern erst GitOps-Tools obendrauf. Gegen Kustomize grenzt es sich über Paketierung und Template-Logik ab; in echten Plattformen werden beide oft kombiniert.

In der nächsten Lektion zerlegen wir die Chart-Struktur im Detail: Chart.yaml, values.yaml, templates/ und was in ein gutes Chart gehört.