Helm 3 auf Helm 4 migrieren

Kubernetes-Delivery, die trägt? WZ-IT baut und betreibt GitOps-, CI/CD- und Plattformbausteine - von Helm und Argo CD über Registry und Policies bis zum reproduzierbaren Rollout. Platform Engineering ansehen

Helm ist der De-facto-Paketmanager für Kubernetes, und mit Helm 4 steht die erste neue Hauptgeneration seit sechs Jahren bereit. Die gute Nachricht vorweg: Der Umstieg ist deutlich sanfter als der berüchtigte Sprung von Helm 2 auf Helm 3. Helm 4 übernimmt bestehende Releases ohne Migrationsschritt. Die weniger gute: Es gibt eine Reihe von Breaking Changes, die still zuschlagen - besonders --wait, Post-Renderer und CI/CD-Skripte. Und die Uhr für Helm 3 tickt.

Dieser Leitfaden zeigt, was sich ändert, was gleich bleibt und wie ein risikoarmer, planbarer Umstieg aussieht. Stand Juli 2026.

Inhaltsverzeichnis

• Warum jetzt: die EOL-Uhr für Helm 3
• Die gute Nachricht: kein Bruch beim Bestand
• Was Helm 4 ändert: die Breaking Changes
• Charts: was bleibt, was experimentell ist
• Der risikoarme Migrationsweg
• Vier Stolpersteine

Warum jetzt: die EOL-Uhr für Helm 3

Helm 4.0 wurde am 12. November 2025 auf der KubeCon North America als General Availability veröffentlicht (Helm-Blog). Damit beginnt der Auslauf von Helm 3 nach einem festen Fahrplan:

• 9. September 2026: das letzte, begrenzte Helm-3-Feature-Release. Es enthält nur noch Kubernetes-Client-Library-Updates für die Unterstützung neuer Kubernetes-Versionen. Weitere Features werden nicht mehr zurückportiert.
• 10. Februar 2027: Ende des Security-Supports. Danach erhält Helm 3 keinerlei Updates mehr, auch keine Sicherheits-Patches (Helm-Blog: End of Life).

Wichtig für die Planung: Diese Daten wurden im Juni 2026 offiziell verlängert. Der ursprüngliche GA-Blogpost nannte noch November 2026 als Support-Ende. Wer sich an älteren Zweitquellen orientiert, arbeitet mit falschen Fristen - maßgeblich sind der 9. September 2026 und der 10. Februar 2027.

Der Handlungsdruck ist also nicht akut wie bei einem Sicherheitsvorfall, aber planbar: Bis Anfang 2027 sollte Helm 3 in produktiven Pipelines und Clustern abgelöst sein. Das ist genug Zeit für einen kontrollierten Umstieg - und genug Grund, ihn nicht auf die lange Bank zu schieben.

Die gute Nachricht: kein Bruch beim Bestand

Der Sprung von Helm 2 auf Helm 3 war schmerzhaft, weil sich das Speicherformat änderte und jedes Release mit dem 2to3-Plugin migriert werden musste. Bei Helm 4 ist das anders.

Helm 4 verwaltet bestehende Helm-3-Releases ohne Migrationsschritt. Das Storage-Format der Release-Secrets im Cluster ist identisch; es gibt kein Konvertierungswerkzeug und keinen Migrationslauf. In der Praxis ist es ein In-Place-Upgrade der CLI: Sie tauschen das Binary, und Helm 4 sieht denselben Cluster-Zustand wie zuvor Helm 3.

Ein Detail müssen Betriebsteams trotzdem kennen: die Apply-Methode. Neue, mit Helm 4 installierte Releases nutzen standardmäßig Server-Side Apply. Bestehende, von Helm 3 erzeugte Releases bleiben nach dem Umstieg dagegen auf Client-Side Apply - Helm 4 folgt beim Upgrade oder Rollback der bisherigen Methode des jeweiligen Releases. In einem Cluster laufen also nach der Migration zwei Apply-Modelle nebeneinander. Für die meisten Charts ist das unkritisch, kann aber bei Field-Ownership-Konflikten relevant werden.

Was Helm 4 ändert: die Breaking Changes

Helm 4 bringt bewusst rückwärtsinkompatible Änderungen an CLI, Flags und SDK mit. Die vier praktisch wichtigsten:

1. --wait benötigt zusätzliche RBAC-Rechte. Helm 4 setzt für --wait auf die kstatus-Bibliothek, die neben list auch das watch-Verb auf allen Chart-Ressourcen braucht (HIP-0022). Fehlt das Recht, scheitern --wait-Operationen sofort. Das ist der erste Stolperstein direkt nach dem Binary-Tausch.

2. Post-Renderer sind jetzt Plugins. Ein Executable-Pfad lässt sich nicht mehr direkt an helm ... --post-renderer übergeben; es muss ein Plugin-Name sein. Wer Kustomize oder eigene Skripte als Post-Renderer einbindet (häufig in GitOps-Setups), muss das vor der Migration neu verdrahten.

3. helm registry login und umbenannte Flags. Der OCI-Login akzeptiert in v4 nur noch den Domainnamen ohne Pfad. Zusätzlich wurden Flags umbenannt: --atomic wird zu --rollback-on-failure, --force zu --force-replace. Die alten Flags funktionieren noch, geben aber eine Deprecation-Warnung aus; --create-pods ist ganz entfernt.

4. Neuer SDK-Importpfad. Wer Helm als Go-Bibliothek nutzt, muss auf den Importpfad helm.sh/helm/v4 umstellen. Die stabile SDK ist code-inkompatibel mit v3, das Logging läuft über slog. Das betrifft eigene Tools und Operatoren, die Helm programmatisch aufrufen (Helm 4.0 Release Notes).

Details zu diesen Änderungen stehen in der Helm-4-Übersicht.

Charts: was bleibt, was experimentell ist

Für die meisten Teams ist das der beruhigendste Teil: Bestehende Charts mit apiVersion: v2 laufen unter Helm 4 unverändert. Das ist die große Mehrheit aller heutigen Charts. Es gibt keinen Zwang, Charts umzuschreiben.

Helm 4 führt zwar ein neues Chart-Format v3 ein, dieses ist in 4.0 aber ausdrücklich experimentell. Es ist standardmäßig deaktiviert und nur über HELM_EXPERIMENTAL_CHART_V3=1 sowie helm create --chart-api-version=v3 erreichbar. Die Dokumentation warnt selbst, dass sich Features noch ändern oder entfallen können. Für Produktion gilt deshalb: bei apiVersion: v2 bleiben und v3 vorerst nur beobachten.

Auch das Plugin-System wurde überarbeitet (Plugin-apiVersion v1) und bringt einen optionalen WebAssembly-Runtime für mehr Sicherheit und OCI-Distribution mit. Bestehende Plugins funktionieren aber weiter; die Umstellung auf WebAssembly ist optional, nicht verpflichtend.

Der risikoarme Migrationsweg

Weil keine automatische Konvertierung nötig ist, folgt der empfohlene Umstieg einem einfachen Test-First-Muster:

1. Helm-4-CLI parallel installieren und zuerst in nicht-produktiven Umgebungen einsetzen. Beide Versionen sehen denselben Cluster-Zustand.
2. Bestehende Charts und Releases testen - helm template, helm upgrade --dry-run und ein echter Upgrade in Staging zeigen früh, ob etwas hakt.
3. RBAC aktualisieren: überall dort, wo --wait genutzt wird, das watch-Verb ergänzen und vorab mit kubectl auth can-i watch ... prüfen.
4. CI/CD-Skripte anpassen: umbenannte Flags ersetzen, helm registry login auf Domain-only umstellen, --create-pods entfernen.
5. Post-Renderer als Plugin neu einbinden, falls im Einsatz.
6. Registry- und OCI-Workflows testen (Login, Push, Pull mit dem neuen Verhalten).
7. Eigene SDK-Nutzung prüfen und auf den Importpfad helm.sh/helm/v4 umstellen.

Erst nach diesen Schritten in nicht-produktiven Umgebungen folgt der produktive Rollout - idealerweise über dieselbe GitOps- und Platform-Engineering-Pipeline, die auch die Anwendungen ausrollt.

Vier Stolpersteine

Zum Abschluss die Punkte, an denen Migrationen erfahrungsgemäß hängen bleiben:

• --wait bricht ohne watch-RBAC sofort. Der häufigste Fehler direkt nach dem Umstieg - RBAC zuerst anpassen.
• Post-Renderer-Pipelines brechen still. Executable-Pfade an --post-renderer funktionieren nicht mehr; als Plugin neu verdrahten, sonst scheitern GitOps-Renderings.
• CI/CD bricht an Login und Flags. Pfad-Anteile im registry login und Skripte mit --atomic/--force müssen angepasst werden.
• Der Apply-Methoden-Split überrascht. Neue Releases nutzen Server-Side Apply, migrierte Helm-3-Releases bleiben auf Client-Side Apply. Dieses gemischte Verhalten und mögliche Field-Ownership-Konflikte einplanen.

Helm 4 ist damit ein kontrollierbarer, aber nicht trivialer Umstieg. Wer ihn früh und getestet angeht, hat bis Anfang 2027 reichlich Puffer - und vermeidet den Druck, kurz vor dem Security-Ende überstürzt migrieren zu müssen.

Der andere große Lifecycle-Umbau 2026 betrifft das Cluster-Netzwerk: von ingress-nginx zur Gateway API migrieren. Und ob Kubernetes für Ihre Anwendung überhaupt der richtige Weg ist, klärt Brauchen wir Kubernetes?