Helm 3 end of life, erklärt

Das End of Life von Helm 3 ist der Tag, ab dem das Helm-Projekt keine Helm-3-Version mehr ausliefert, auch keine Sicherheitskorrekturen. Dieser Tag ist der 10. Februar 2027, so der Beitrag des Helm-Projekts zum End of Life. Viele Anleitungen nennen noch November 2026, das Datum aus dem ursprünglichen Plan. Teams, die Helm 3 in Skripten und Pipelines nutzen, haben noch etwa drei Monate für den Wechsel zu Helm 4.

Helm ist der Paketmanager für Kubernetes, das System, das Container auf vielen Servern betreibt. Ein Helm-Chart ist ein Paket mit Vorlagen für eine App. Die Installation eines Charts erzeugt ein Release. Jedes Upgrade fügt der Historie dieses Releases eine nummerierte Revision hinzu.

Diese Anleitung behandelt den Zeitplan, die Änderungen in Helm 4 und einen praktischen Test von Helm 4.3.1 mit Releases, die Helm 3.22.1 erstellt hat.

So funktioniert das End of Life von Helm 3

Helm 3 läuft in zwei Schritten aus. Das steht im Beitrag zum End of Life, den George Jenkins am 2. Juni 2026 für das Projekt schrieb.

• Fehlerkorrekturen endeten am 9. September 2026. Die Version von diesem Tag war die letzte Feature-Version von Helm 3. Sie brachte nur aktualisierte Kubernetes-Client-Bibliotheken. So konnte Helm 3 mit neueren Kubernetes-Versionen sprechen.
• Sicherheitskorrekturen enden am 10. Februar 2027. Wird vorher eine Lücke gefunden, liefert das Projekt noch einen Patch. Nach diesem Datum bekommt Helm 3 laut dem Beitrag keine Updates mehr, „einschließlich Kubernetes-Client-Bibliothek und Sicherheitspatches“.

Die Versionshinweise zu v3.22.0 bestätigen, dass 3.22 die letzte Minor-Version von Helm 3 ist. Der neueste Patch, 3.22.1, erschien am 15. Oktober 2026.

End of Life schaltet nichts ab. Ein Helm-3-Binary läuft auch nach dem 10. Februar 2027 weiter, wie Private DevOps in seiner Migrationsanleitung betont. Es bekommt nur keine Sicherheitskorrekturen und keine Unterstützung für neue Kubernetes-Versionen mehr.

Was sich wann geändert hat

Der ursprüngliche Zeitplan stammt aus HIP-0012, einem Helm-Verbesserungsvorschlag. Er versprach Sicherheitskorrekturen für Helm 3 bis ein Jahr nach Helm 4.0.0, also bis November 2026. Im Juni verlängerten die Maintainer um drei Monate.

Datum	Was geschah
12. November 2025	Helm 4.0.0 erscheint auf der KubeCon, die erste neue Hauptversion von Helm seit sechs Jahren
2. Juni 2026	Helm verlängert die Sicherheitskorrekturen für Helm 3 um drei Monate
9. September 2026	Letzte Feature-Version von Helm 3 (3.22); Fehlerkorrekturen enden
15. Oktober 2026	Helm 3.22.1 und Helm 4.3.1 erscheinen, die neuesten Versionen am 8. November
13. Januar 2027	Helm 4.4.0 geplant, laut der Release-Seite
10. Februar 2027	Sicherheitskorrekturen für Helm 3 enden; keine weiteren Helm-3-Versionen

Der Rat des Beitrags ist klar: „Wir empfehlen allen Nutzern dringend, vor diesem Datum auf Helm 4 umzusteigen.“

Was Helm 4 für Nutzer von Helm 3 ändert

Laut dem Helm-Projekt soll Helm 4 „mit den meisten bestehenden Helm-3-Charts, -Releases und -Workflows kompatibel sein“. Charts im heutigen v2-Format funktionieren unverändert. Ein neues v3-Chartformat ist noch experimentell. Die Helm-4-Übersicht nennt die Änderungen, die zählen:

• Umbenannte Flags. --atomic heißt jetzt --rollback-on-failure, und --force heißt jetzt --force-replace. Die alten Namen funktionieren noch, geben aber eine Warnung aus.
• Post-Renderer sind Plugins. Ein Post-Renderer bearbeitet die Ausgabe von Helm, bevor sie den Cluster erreicht. --post-renderer erwartet jetzt den Namen eines installierten Plugins, nicht den Pfad zu einem Skript.
• Registry-Login mit Hostnamen. helm registry login akzeptiert nur eine Domain, keine URL.
• Server-side Apply für neue Installationen. Bei Server-side Apply führt Kubernetes jede Änderung selbst zusammen und hält fest, welchem Werkzeug welches Feld gehört. Upgrades und Rollbacks behalten die Methode, die ein Release schon nutzt. Releases von Helm 3 bleiben deshalb bei der älteren clientseitigen Methode. Das Flag --server-side überschreibt das.
• Ein neues Plugin-System. Bestehende Plugins funktionieren weiter. Plugins können außerdem auf einer optionalen WebAssembly-Laufzeit laufen, die das Projekt aus Sicherheitsgründen empfiehlt.

Getestet: Helm 4.3.1 mit Releases von Helm 3

In einem Test von Tech AI Wire am 8. November 2026 lief ein k3s-Cluster mit Kubernetes 1.36.6 in Docker 28.4.0 unter macOS 26.6.2. Beide Helm-Binaries stammten von get.helm.sh, und ihre SHA-256-Prüfsummen stimmten. Helm 3.22.1 installierte das Beispiel-Chart, das helm create anlegt. Danach arbeitete Helm 4.3.1 mit demselben Release. Die beiden Binaries heißen unten helm3 und helm4.

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

Test	Ergebnis
Helm 4 liest das Release von Helm 3	Ja: helm list und helm history zeigten es
upgrade --atomic	Funktionierte, mit „Flag --atomic has been deprecated, use --rollback-on-failure instead“
upgrade --force	Funktionierte, mit „Flag --force has been deprecated, use --force-replace instead“
registry login https://ghcr.io	Scheiterte: invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh, ein Shell-Skript	Scheiterte: Plugin nicht gefunden; Helm 3.22.1 führte dasselbe Skript aus
Apply-Methode des Helm-3-Releases nach Upgrades mit Helm 4	„client-side apply (defaulted)“
Apply-Methode einer neuen Installation mit Helm 4	„server-side apply“
Helm 3 nach den Upgrades mit Helm 4	Las alle vier Revisionen und rollte auf Revision 1 zurück

Die eigenen Aufzeichnungen von Kubernetes passten dazu. Das Deployment des Helm-3-Releases wurde mit einer „Update“-Operation geschrieben, das neue Helm-4-Release mit einem „Apply“.

Ein Ergebnis steht nicht in der Dokumentation. --server-side=true stellte das Helm-3-Release auf Server-side Apply um. Ein späteres Upgrade mit Helm 3.22.1 ließ Helm 4 es dann wieder als clientseitig melden, mit dem Zusatz „(defaulted)“. Wechseln sich alte und neue Binaries bei einem Release ab, kann das eine Migration unbemerkt rückgängig machen.

Was das für Entwickler bedeutet

• Zuerst die zwei harten Fehler beheben. CI-Skripte nach helm registry login mit https:// durchsuchen und nach --post-renderer, das auf ein Skript zeigt. Beides stoppt eine Helm-4-Pipeline, während die umbenannten Flags nur Warnungen ausgeben.
• --atomic und --force jetzt umbenennen. Sie funktionieren noch, aber Helm 4 markiert sie als veraltet und gibt bei jedem Lauf eine Warnung aus.
• Ein Binary pro Release wählen. Während des Umstiegs ein Release, das Helm 4 einmal angefasst hat, nur noch mit Helm 4 aktualisieren. Sonst kann die Apply-Methode zurückspringen.
• Server-side Apply bewusst wählen. Releases von Helm 3 bleiben clientseitig, bis jemand --server-side übergibt. Den Wechsel vor der Produktion auf einem Staging-Cluster ausprobieren.
• Die Helm-Version in der CI festlegen und Rollbacks testen. Private DevOps rät, jeden Helm-Aufruf zu erfassen und Helm 4 zuerst außerhalb der Produktion zu testen.
• Nicht bis zum 10. Februar warten. Danach bleibt eine Sicherheitslücke in Helm 3 ungepatcht, und neuere Kubernetes-Versionen bekommen keine Unterstützung im Helm-3-Client.