Neu in Helm

Die Client-Bibliotheken stehen auf 0.37.0, unterstützt werden Kubernetes 1.37 bis 1.34. 1.33 liegt damit außerhalb des unterstützten Fensters von 4.3. Cluster auf 1.33 sollten vor dem Helm-Update angehoben werden, denn 4.2 bekommt keine Patches mehr.

Vor dem Löschen liest Helm jedes Objekt und verlangt das Label app.kubernetes.io/managed-by: Helm sowie die Annotationen meta.helm.sh/release-name und meta.helm.sh/release-namespace mit den Werten dieses Release. Objekte ohne passende Metadaten bleiben stehen, ebenso Objekte, die Helm nicht lesen kann, etwa mangels RBAC. Die Ausgabe listet beide Gruppen auf. Wer Labels oder Annotationen von Hand entfernt hat, findet nach dem Uninstall Waisen im Cluster.

Die Helm-CLI berechnet den kstatus-Status mit acht parallelen Workern, die Resync-Periode des Watchers sinkt von einer Stunde auf drei Minuten. Upgrades mit vielen Deployments (im Commit etwa 20) hingen vorher ein bis drei Minuten und länger im Wait. SDK-Nutzer wie Controller bleiben beim seriellen Default und müssen die Parallelität über kube.WithStatusComputeWorkers selbst einschalten.

--keyring liest neben dem binären pubring.gpg jetzt auch GnuPGs Keybox pubring.kbx und ASCII-armored Exporte (gpg --export --armor). Fehlt pubring.gpg in ~/.gnupg bzw. $GNUPGHOME, nimmt Helm per Default pubring.kbx. Der Konvertierungsschritt vor helm verify und --verify entfällt. Eine Keybox enthält nur Public Keys, zum Signieren braucht es weiterhin einen exportierten Secret Key.

Ist SOURCE_DATE_EPOCH gesetzt, stempeln helm package und helm dependency build/update (auch über install und upgrade mit --dependency-update) die Archiv-Einträge und das generated-Feld in Chart.lock mit diesem Zeitpunkt, normiert auf UTC und ganze Sekunden. Zwei Builds aus demselben Stand ergeben so ein bitgleiches .tgz, und OCI-Digests werden über unabhängige Builds hinweg vergleichbar.

Endete eine Values-Datei ohne abschließenden Zeilenumbruch und war die letzte Zeile ein Vielfaches von 4096 Byte lang, verwarf der Loader diese Zeile still. Bei kompakten JSON-Values, die nur aus einer Zeile bestehen, fiel so die ganze Datei weg. 4.3 liest die Datei vollständig ein.

Templates kennen mustToDuration sowie durationSeconds, durationMinutes, durationHours, durationDays, durationWeeks (dazu Milli-, Mikro- und Nanosekunden), durationRoundTo und durationTruncateTo. Nur mustToDuration bricht bei ungültiger Eingabe ab, die übrigen liefern still 0. helm rollback nimmt --description (bis 256 Zeichen), der Grund erscheint in helm history.

3.22.0 ist das letzte Minor der Helm-3-Linie. Bis 10.02.2027 kommen nur noch Security-Patches nach Bedarf, keine Bugfixes und keine Updates der Client-Bibliotheken. Danach erscheint kein Helm-3-Release mehr.

Die Client-Bibliotheken stehen auf 0.37.0, unterstützt werden 1.37 bis 1.34. Weil keine Client-Updates mehr folgen, ist 1.37 die letzte Kubernetes-Version, die Helm 3 abdeckt. Wer 1.38 einplant, muss vorher auf Helm 4 sein.

Neben den Client-Bibliotheken enthält 3.22.0 Bugfix-Backports: helm push fordert bei Registries mit Token-Auth den Scope pull,push an, und Rollbacks funktionieren auch dann, wenn Ressourcen der Zielrevision im Cluster fehlen. Die Umstellung des Provenance-Codes auf ProtonMail/go-crypto (GO-2026-5932) kam bereits mit 3.21.4.

Client-Bibliotheken auf 1.36, unterstützt werden 1.36 bis 1.33. Wer die Cluster-Version anhebt, braucht ab 1.36 mindestens Helm 4.2.

Der serverseitige Dry-Run behandelt Ressourcen mit generateName korrekt. Vorher lief die Vorschau für solche Objekte ins Leere.

Beide Flags an helm template sind deprecated und sollen in Helm 5 entfernt werden, für das es keinen Termin gibt. Sie waren ohnehin wirkungslos, weil die Template-Ausgabe keine Notes enthält.

--wait akzeptiert jetzt auch hookOnly als expliziten Wert, --wait=true und --wait=false sind deprecated (Ersatz: watcher bzw. hookOnly). Außerdem läuft das SDK nicht mehr in einen Timeout-Fehler, wenn gar kein Timeout gesetzt war.

Wer Custom Resources betreibt, deren Readiness kstatus nicht von sich aus versteht, kann eigene Status-Reader registrieren. Damit wird --wait auch für Operator-verwaltete CRs verlässlich.

Helm schreibt die Index-Dateien im Repository-Cache (<repo>-index.yaml, <repo>-charts.txt) atomar. Parallel laufende Helm-Prozesse, etwa mehrere helm dependency build in derselben CI, lesen damit keine halb geschriebenen Index-Dateien mehr. Schneller wird der Build dadurch nicht.

Helm 4 verwaltet vorhandene Helm-3-Releases direkt. Es gibt kein Konvertierungswerkzeug und keinen Migrationslauf: man tauscht das Binary und prüft Charts, Pipelines und Post-Renderer.

Neuinstallationen nutzen per Default Server-Side Apply, was Konflikte mit Operatoren und anderen Controllern sauber auflöst. Bei Upgrade und Rollback rastet Helm auf die Methode der bestehenden Release ein: aus Helm 3 übernommene Releases bleiben auf Client-Side Apply, bis --server-side=true gesetzt wird.

Das Ressourcen-Watching hinter --wait läuft über kstatus und meldet detaillierten Rollout-Status statt reiner Pod-Prüfung. Wichtig: kstatus braucht das watch-Verb, ein Service-Account ohne watch lässt --wait scheitern.

Charts lassen sich unveränderlich per Digest ziehen, etwa oci://registry.example.com/charts/app@sha256:abc123. Stimmt der Digest nicht, wird nicht installiert. In regulierten Umgebungen der Weg, eine Chart-Version wirklich festzunageln.

plugin.yaml trägt jetzt apiVersion v1, einen type und ein runtime-Feld, entweder subprocess oder extism/v1 für WASM. Bestehende Subprocess-Plugins laufen unverändert weiter, die WASM-Laufzeit ist optional und sandboxt fremden Plugin-Code.

--post-renderer nimmt keinen Pfad auf ein Executable mehr, sondern einen Plugin-Namen. Jede bestehende Post-Renderer-Integration, typischerweise ein Kustomize-Wrapper in der CI, muss als Plugin verpackt werden.

--atomic heißt jetzt --rollback-on-failure, --force heißt --force-replace; die alten Flags warnen nur, funktionieren aber noch. helm registry login akzeptiert dagegen ausschließlich den Domainnamen, keine vollständige URL mehr. Das bricht Pipelines, die die Registry bisher mit https:// übergeben haben.