Helm 3.22.1: weniger als vier Monate Sicherheitssupport – was der Umstieg auf Helm 4 verlangt
Victoria Shinder3 Min. LesezeitDas Helm-Projekt hat diese Woche zwei Patch-Releases ausgeliefert: Helm 4.3.1 am 15. Oktober und am selben Tag Helm 3.22.1. Beide Release Notes enden mit derselben Zeile: 4.3.2 und 3.22.2 sind für den 11. November 2026 geplant, 4.4.0 für den 13. Januar 2027, und „es wird keine weiteren Helm-3-Minor-Releases geben“. Für Teams auf der 3.x-Linie ist dieser Satz die eigentliche Nachricht; die Patches selbst sind klein.
Was die beiden Patches enthalten. Helm 3.22.1 hebt Abhängigkeiten an, „um Schwachstellen in Go-Paketen zu entfernen“, und aktualisiert die k8s.io-Go-Pakete; laut Changelog geht golang.org/x/net wegen fünf Go-Advisories (GO-2026-6603, -6610, -6611, -6612 und -6617) auf v0.60.0 und die k8s.io-Gruppe auf v0.37.1. Helm 4.3.1 nennt zwei wichtige Änderungen – das Warten auf etablierte CRDs bei der Hook-only-Strategie (#32672) und ein Update von golangci-lint – sowie golang.org/x/net v0.61.0 und weitere Abhängigkeits-Updates.
Die entscheidenden Daten. Laut dem End-of-Life-Beitrag des Projekts haben die Maintainer ein zusätzliches, begrenztes Feature-Release am 9. September 2026 eingeschoben – beschränkt auf Updates der Kubernetes-Client-Bibliotheken für neue Kubernetes-Versionen, ohne weitere zurückportierte Funktionen – und den Sicherheitssupport um drei Monate bis zum 10. Februar 2027 verlängert. Fehlerkorrekturen gab es bis zu diesem letzten Feature-Release. Nach Februar 2027 erhält Helm 3 laut Beitrag überhaupt keine Updates mehr, auch keine Client-Bibliotheken und keine Sicherheitspatches. Zum Zeitpunkt von 3.22.1 sind das weniger als vier Monate.
Was laut Projekt übernommen werden kann. Die Maintainer schreiben, dass mit Helm 3 deploybare Charts auch mit Helm 4 deploybar sein sollten und von Helm 3 verwaltete Releases sich in der Regel mit Helm 4 aktualisieren lassen – das Binary lässt sich also tauschen, ohne Charts umzuschreiben oder Releases neu auszurollen. Neue Releases nutzen standardmäßig Server-Side Apply, Upgrades bestehender Helm-3-Releases bleiben automatisch bei Client-Side Apply.
Was sich nicht unverändert übernehmen lässt. Derselbe Beitrag listet die Breaking Changes, und dort muss ein Migrationsplan ansetzen: helm install --post-renderer erwartet jetzt einen Plugin-Namen statt eines Pfads zu einer ausführbaren Datei, Post-Renderer-Abläufe müssen also als Plugins neu gebaut werden; helm registry login akzeptiert nur noch Domainnamen, keine vollständigen URLs; aus --atomic wurde --rollback-on-failure, aus --force wurde --force-replace – die alten Flags funktionieren weiter, geben aber Abkündigungswarnungen aus. Wo Skripte die CLI kapseln oder ihre Ausgabe auswerten, werden diese Warnungen zuerst auffallen.
Warum die Grenze gezogen wird. Laut Beitrag hat Helm 3 technische Schulden und architektonische Grenzen angesammelt, die neue Funktionen ohne Bruch der öffentlichen SDK-APIs verhinderten; Helm 4, erschienen im November 2025, vollzieht diese Brüche einmalig und erklärt die SDK-API für stabil. Genannt wird auch, was 3.x-Nutzer nicht bekommen haben: eine optionale, auf WebAssembly basierende Plugin-Laufzeit, Ressourcenüberwachung über kstatus, Values verteilt auf mehrere YAML-Dateien und eigene Template-Funktionen per Plugin.
Die praktische Lesart. Für den Betrieb ergeben Patch Notes und End-of-Life-Beitrag zusammen eine kurze Liste aus dem eigenen Text des Projekts: Post-Renderer und Registry-Logins erfassen, die beiden umbenannten Flags in Skripten ersetzen, bevor die Warnungen zum Rauschen werden, und den Wechsel vor dem 10. Februar 2027 einplanen – danach erhält ein Helm-3-Binary nach den Worten der Maintainer keine Updates mehr.
Quelle: Helm, „Helm 3 End of Life“ — https://helm.sh/blog/helm-v3-end-of-life/ ; Releases: https://github.com/helm/helm/releases/tag/v3.22.1 und https://github.com/helm/helm/releases/tag/v4.3.1