Helm 3: Was sich geändert hat und warum es besser ist

Tiller ist Geschichte

Mitte November 2019 hat das Helm-Projekt Version 3.0 veröffentlicht. Das Major Release bringt grundlegende Architekturänderungen mit, die man als Helm-Nutzer kennen sollte. Die wichtigste davon vorweg: Tiller ist weg. Endgültig.

Wer unseren Artikel zu Helm Charts gelesen hat, erinnert sich vielleicht an den Abschnitt zu Tiller -- die serverseitige Komponente, die im Cluster lief und die eigentlichen Deployments ausführte. Wir hatten damals geschrieben, dass man Tiller in Produktionsumgebungen mit eingeschränkten RBAC-Rechten und TLS absichern sollte. Und dass die Community aktiv über Tillers Zukunft diskutierte. Diese Diskussion ist nun abgeschlossen.

Die Probleme mit Tiller waren in der Praxis nicht zu übersehen. In der Standardkonfiguration lief Tiller mit Cluster-Admin-Rechten -- ein einzelner Pod mit vollem Zugriff auf alle Namespaces und Ressourcen. In Shared-Cluster-Umgebungen, in denen mehrere Teams auf einem Cluster arbeiten, war das ein Sicherheitsrisiko, das man nicht ignorieren konnte. Die Absicherung über dedizierte Service Accounts, TLS-Zertifikate und eingeschränkte Namespaces war möglich, aber aufwendig und fehleranfällig. In unseren Projekten war die Tiller-Konfiguration regelmäßig der komplizierteste Teil des Helm-Setups.

Die neue Architektur: Helm spricht direkt mit der API

Helm 3 macht es radikal einfacher. Es gibt keinen serverseitigen Prozess mehr. Der Helm-Client kommuniziert direkt mit dem Kubernetes API-Server und nutzt dafür die bestehende kubeconfig -- dieselbe Konfiguration, die auch kubectl verwendet. Die Berechtigungen eines Helm-Benutzers entsprechen damit exakt seinen Kubernetes-Berechtigungen. Wer per RBAC nur Zugriff auf den Namespace staging hat, kann mit Helm auch nur dort Releases installieren. Keine Umwege, keine Sonderberechtigungen.

Das vereinfacht die Einrichtung erheblich. Statt Tiller zu installieren, Service Accounts zu konfigurieren und TLS-Zertifikate zu verwalten, funktioniert Helm 3 sofort -- vorausgesetzt, kubectl funktioniert bereits. Das helm init entfällt komplett.

# Helm 2: Tiller musste erst installiert werden
helm init --service-account tiller --tiller-namespace my-team

# Helm 3: Einfach nutzen. Helm verwendet die aktive kubeconfig.
helm install my-app ./my-spring-app -f values-prod.yaml

Three-Way Strategic Merge: Upgrades, die den Ist-Zustand kennen

Eine der subtileren, aber wirkungsvollsten Änderungen betrifft die Upgrade-Logik. Helm 2 verglich bei einem helm upgrade nur zwei Zustände: das alte Chart-Manifest und das neue Chart-Manifest. Was tatsächlich im Cluster lief, spielte keine Rolle.

Das führte zu einem konkreten Problem. Angenommen, jemand änderte eine Konfiguration direkt im Cluster per kubectl edit -- ein Replica-Count, ein Ressourcen-Limit, ein Annotation. Beim nächsten helm upgrade verglich Helm nur altes und neues Manifest. Hatte sich dort nichts geändert, passierte nichts. Die manuelle Änderung blieb bestehen, obwohl sie im Chart nicht abgebildet war. Oder schlimmer: Die manuelle Änderung wurde stillschweigend überschrieben, wenn sich zufällig derselbe Wert im neuen Manifest geändert hatte.

Helm 3 verwendet stattdessen einen Three-Way Strategic Merge Patch. Es vergleicht drei Zustände: das alte Manifest, den tatsächlichen Live-Zustand im Cluster und das neue Manifest. Manuelle Änderungen werden erkannt. Wenn das neue Manifest einen Wert nicht ändert, den jemand manuell angepasst hat, bleibt die manuelle Änderung erhalten. Wenn das neue Manifest den Wert explizit setzt, wird die manuelle Änderung überschrieben -- aber bewusst und nachvollziehbar.

In der Praxis bedeutet das weniger Überraschungen bei Upgrades und ein vorhersagbareres Verhalten, besonders in Umgebungen, in denen Hotfixes gelegentlich direkt auf dem Cluster landen.

Release-Storage: Secrets statt ConfigMaps

Helm 2 speicherte Release-Informationen als ConfigMaps im kube-system-Namespace. Jede Revision eines Releases erzeugte eine eigene ConfigMap -- und diese ConfigMaps enthielten das gesamte gerenderte Manifest, einschließlich aller Werte. Da ConfigMaps nicht verschlüsselt sind, lagen sensible Werte wie Datenbankpasswörter oder API-Keys im Klartext in kube-system -- lesbar für jeden, der Zugriff auf diesen Namespace hatte.

Helm 3 speichert Release-Informationen als Kubernetes Secrets, und zwar im selben Namespace wie das Release selbst. Das hat zwei Vorteile: Secrets lassen sich mit Encryption at Rest verschlüsseln, und die Release-Daten liegen dort, wo sie hingehören -- neben den Ressourcen, die sie beschreiben. Die Sichtbarkeit folgt den bestehenden RBAC-Regeln des Namespaces.

Validierung und neue Chart-Features

Helm 3 bringt zwei Features, die Charts robuster und wartbarer machen.

JSON Schema Validation: Charts können nun ein JSON Schema (values.schema.json) mitliefern, das die values.yaml validiert. Fehlerhafte oder fehlende Werte werden bereits beim helm install abgefangen, nicht erst zur Laufzeit im Cluster.

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["image", "replicaCount"],
  "properties": {
    "replicaCount": {
      "type": "integer",
      "minimum": 1
    },
    "image": {
      "type": "object",
      "required": ["repository", "tag"],
      "properties": {
        "repository": { "type": "string" },
        "tag": { "type": "string" }
      }
    }
  }
}

Gerade bei Charts, die von mehreren Teams oder in CI-Pipelines genutzt werden, verhindert das eine ganze Klasse von Fehlern. Statt einer kryptischen Template-Fehlermeldung bekommt man eine klare Aussage: "replicaCount muss eine Ganzzahl sein."

Library Charts: Ein neuer Chart-Typ, der Templates und Hilfsfunktionen bereitstellt, aber keine eigenen Kubernetes-Ressourcen erzeugt. In der Chart.yaml kennzeichnet man einen Library Chart mit type: library. Andere Charts binden ihn als Dependency ein und nutzen seine Templates. Für Teams, die viele ähnliche Charts pflegen -- etwa ein Basis-Template für Spring-Boot-Services -- reduziert das die Duplikation erheblich.

Migration von Helm 2: Der helm-2to3-Plugin-Weg

Das Helm-Team stellt ein offizielles Migrations-Plugin bereit, das den Umstieg erleichtert. Das Plugin konvertiert die Helm-2-Konfiguration und migriert bestehende Releases.

# Plugin installieren
helm plugin install https://github.com/helm/helm-2to3

# Helm-2-Konfiguration migrieren (Repositories, Plugins)
helm 2to3 convert my-release

# Alten Helm-2-Release-Daten aufräumen
helm 2to3 cleanup

Die Migration ist pro Release durchzuführen. helm 2to3 convert liest die ConfigMap aus kube-system, konvertiert sie in ein Secret im Release-Namespace und erstellt die Helm-3-Release-Struktur. Danach verwaltet Helm 3 das Release, und die alten ConfigMaps können mit cleanup entfernt werden.

Unser Rat: Migriert nicht alles auf einmal. Beginnt mit den Development-Umgebungen, testet die Upgrades, und arbeitet euch schrittweise zu Production vor. Helm 2 und Helm 3 können parallel existieren, da sie unterschiedliche Storage-Backends verwenden.

Weitere Änderungen im Überblick

Einige kleinere, aber erwähnenswerte Änderungen:

• helm install erfordert einen Release-Namen: In Helm 2 konnte man den Namen automatisch generieren lassen (helm install ./chart). Helm 3 verlangt einen expliziten Namen oder das Flag --generate-name.
• Namespaces werden nicht mehr automatisch erstellt: Helm 3 erwartet, dass der Ziel-Namespace existiert. Mit --create-namespace kann man das alte Verhalten erzwingen.
• helm test überarbeitet: Test-Pods werden nach dem Testlauf nicht mehr automatisch gelöscht. Das erleichtert die Fehleranalyse bei fehlgeschlagenen Tests.
• requirements.yaml entfällt: Chart-Dependencies werden direkt in der Chart.yaml unter dem Schlüssel dependencies definiert.

Fazit

Helm 3 räumt die wesentlichen Schwachstellen von Helm 2 auf. Der Wegfall von Tiller allein rechtfertigt die Migration -- das RBAC-Setup wird drastisch einfacher, die Angriffsfläche im Cluster kleiner. Der Three-Way Merge macht Upgrades vorhersagbarer, die Secret-basierte Release-Speicherung sicherer, und JSON Schema Validation robuster.

Wer heute noch Helm 2 im Einsatz hat, sollte die Migration zeitnah angehen. Helm 2 wird nur noch bis August 2020 mit Sicherheitsupdates versorgt. Das helm-2to3-Plugin macht den Umstieg handhabbar, und die CLI-Änderungen halten sich in Grenzen. In unseren Projekten haben wir die Migration innerhalb weniger Tage pro Cluster abgeschlossen -- die aufwendigste Aufgabe war dabei nicht Helm selbst, sondern die Aktualisierung der CI/CD-Pipelines.