Helm 4 ist da: Server-Side Apply, WebAssembly-Plugins und die Migration von Helm 3

Nach sechs Jahren und über 500 Millionen Chart-Installationen ist Helm in Version 4 erschienen. Das Release auf der KubeCon North America 2025 markiert einen der tiefgreifendsten Architekturwechsel in der Geschichte des Kubernetes-Paketmanagers. Server-Side Apply, ein WebAssembly-basiertes Plugin-System und eine zuverlässigere Deployment-Status-Überwachung machen Helm 4 nicht nur sicherer, sondern auch leistungsfähiger für moderne GitOps-Workflows. Der folgende Artikel fasst die wichtigsten Neuerungen zusammen und gibt eine Orientierung für die anstehende Migration.

Server-Side Apply: Das Ende des Drei-Wege-Merges

Die bedeutendste Änderung in Helm 4 ist der Umstieg von der bisherigen Drei-Wege-Merge-Strategie auf Server-Side Apply (SSA). Helm 3 verglich dafür drei Zustände: den gewünschten Zustand aus dem Chart, den Live-Zustand im Cluster und die letzte erfolgreiche Konfiguration aus einem Secret. Kubernetes selbst setzt seit Version 1.22 auf SSA und erfasst dort, welcher Manager (Controller, Tool oder Benutzer) welches Feld eines Objekts verwaltet.

Helm 4 nutzt SSA standardmäßig bei Neuinstallationen. Bei Upgrades bestehender Releases bleibt das bisherige Verfahren erhalten – wer wechseln möchte, übergibt explizit --server-side. Ein neuer --force-conflicts-Flag erlaubt das Überschreiben von Feldkonflikten, falls nötig. Besonders in GitOps-Umgebungen mit ArgoCD oder Flux profitieren Teams von dieser Änderung: Wenn Helm nur die Felder aktualisiert, die es selbst verwaltet, entfallen die bisherigen Überschreibungskonflikte mit anderen Controllern.

WebAssembly-Plugins: Sicherheit durch Sandboxing

Helm-3-Plugins liefen als native Binärdateien mit vollem Systemzugriff. Ein bösartiges Plugin konnte die kubeconfig auslesen oder beliebige Netzwerkverbindungen aufbauen. Helm 4 führt einen optionalen WebAssembly-Runtime ein, der Plugins in einer sandboxierten Umgebung ausführt. Berechtigungen werden explizit deklariert: Ein Plugin kann etwa nur lesend auf /tmp zugreifen oder ausschließlich HTTPS-Verbindungen zu einer bestimmten Domain aufbauen.

Die WebAssembly-Plugins sind plattformunabhängig – ein .wasm-File läuft auf Linux, macOS und Windows identisch. Bestehende native Plugins funktionieren weiterhin, das Helm-Team empfiehlt den Umstieg auf Wasm jedoch aus Sicherheitsgründen. Ein wichtiger Bruch betrifft Post-Renderer: Diese können nicht mehr als ausführbare Datei per --post-renderer übergeben werden, sondern müssen als Plugin registriert sein.

Kstatus-Watcher und verlässlichere Deployments

Ein lange bestehendes Problem in Helm 3 war die unzuverlässige --wait-Option: Helm markierte ein Deployment als abgeschlossen, sobald die Ressourcen angelegt waren – nicht erst, wenn sie tatsächlich betriebsbereit waren. Helm 4 integriert die Kubernetes-Bibliothek kstatus, die den Gesundheitszustand nativer Ressourcen (Deployments, StatefulSets, Services) präzise interpretiert.

Mit zwei neuen Annotations — helm.sh/readiness-success und helm.sh/readiness-failure — können Chart-Autoren festlegen, wann eine Ressource als bereit gilt. Helm installiert die nächste Ressourcengruppe erst, wenn die vorherige tatsächlich läuft. Race-Conditions, bei denen eine Anwendung vor ihrer Datenbank startet, gehören damit der Vergangenheit an.

OCI-Digest-Installation und Content-basiertes Caching

Für die Lieferketten-Sicherheit führt Helm 4 die Installation per OCI-Digest ein: helm install myapp oci://registry.example.com/charts/app@sha256:abc123.... Charts mit nicht übereinstimmendem Digest werden abgelehnt. Gleichzeitig ersetzt ein Content-basierter Cache den alten name/version-basierten Cache: Zwei Charts mit gleichem Namen und gleicher Version, aber unterschiedlichem Inhalt, kollidieren nicht mehr. Das beschleunigt Abhängigkeitsauflösungen und helm dependency update spürbar.

Weitere Neuerungen und CLI-Änderungen

Helm 4 bringt Multi-Document Values: Über das ----YAML-Separator lassen sich mehrere YAML-Dokumente in einer einzigen Values-Datei ablegen – nützlich für komplexe Umgebungs-Overlays. Der neue --set-json-Parameter erlaubt das Übergeben strukturierter JSON-Werte ohne Umwege. Einige CLI-Flags wurden umbenannt: --atomic heißt jetzt --rollback-on-failure, --force wurde zu --force-replace. Die alten Namen lösen eine Deprecation-Warnung aus und sollten in CI/CD-Pipelines ersetzt werden.

Migrationsstrategie

Das Helm-Team gewährt eine großzügige Übergangsfrist: Bugfixes für Helm 3 laufen bis Juli 2026, Sicherheitsfixes bis November 2026. Neue Features werden nicht mehr zurückportiert. Charts im aktuellen APIv2-Format bleiben voll kompatibel – es sind keine Chart-Änderungen nötig. Ein experimentelles v3-Chart-Format ist bereits über die Umgebungsvariable HELM_EXPERIMENTAL_CHART_V3 verfügbar.

Für die Migration empfiehlt sich ein gestaffelter Ansatz: Helm 3 und Helm 4 können als separate Binärdateien auf demselben System koexistieren. Zunächst sollten nicht-produktive Umgebungen mit Helm 4 getestet werden, bevor die CI/CD-Pipelines umgestellt werden. Besondere Aufmerksamkeit gilt Plugins und Post-Renderern – diese müssen auf Kompatibilität geprüft werden.

Fazit

Helm 4 ist kein radikaler Bruch, sondern ein dringend nötiger Modernisierungsschritt. Server-Side Apply beendet die Ära der Konflikte zwischen GitOps-Tools, WebAssembly-Plugins bringen Enterprise-Sicherheit in die Plugin-Architektur, und kstatus macht Deployment-Status endlich verlässlich. Wer Kubernetes im Produktionseinsatz betreibt, sollte die Migration noch 2026 planen – der Support für Helm 3 läuft planmäßig aus.

Quellen

• Helm 4 Released (Offizielles Blog) — Release-Ankündigung auf KubeCon NA 2025
• Helm 4: the key improvements! (enix.io) — Detaillierte Analyse der Neuerungen und Migration
• Helm 4: What Actually Changed And How To Migrate From Helm 3 (alexandre-vazquez.com) — Umfassende Migrationsanleitung mit FAQ
• Helm 4 Overview (Helm Docs) — Offizielle Übersicht mit Breaking Changes und neuen Features