Text size
Auf meinem Radar5 Min. Lesezeit

Steuer 4: Was hat sich geändert?

Die erste große Helm-Veröffentlichung seit Jahren. Was anders ist und ob deine Karten noch funktionieren.

Helm 4: what changed
KI-generierte Illustration

Helm 3 kam 2019 heraus. Das ist alte Geschichte in Kubernetes Jahren. Es entfernte Tiller, die Server-Komponente, die alle hassten, und blieb dann sechs Jahre lang bemerkenswert stabil. Millionen Einsätze hängen davon ab.

Helm 4 erschien Ende 2025, bekannt gegeben auf KubeCon North America. Die große Frage für die meisten Teams ist also: Was ist anders, und muss ich etwas ändern?

Was gibt's Neues?

Helm 4 ist weniger revolutionär als Helm 3. Es ist eher eine Modernisierung. Die Überschrift ändert sich:

Serverseite anwenden. Helm 3 hat Ressourcen mit einer eigenen Drei-Wege-Fusion-Logik auf dem Client angewendet. Helm 4 kann Kubernetes benutzen. Serverseite anwenden, so wie moderne Tools wie Argo CD und Flux zunehmend funktionieren. Dies macht Helm besser mit anderen Werkzeugen zu spielen, die die gleichen Ressourcen berühren, und behandelt Feldbesitz richtig.

Besser warten und den Status überprüfen. Die --wait Die Verhaltensregeln wurden überarbeitet, um eine modernere Statusprüfung zu ermöglichen, so daß Helm besser wissen kann, ob die Ressourcen tatsächlich bereit sind, einschließlich benutzerdefinierter Ressourcen.

Ein neues Plugin-System. Plugins können nun als WebAssembly-Module geschrieben werden, was sie portabel und sandboxed macht, anstatt willkürliche Skripte, die auf Ihrem Computer ausgeführt werden. Die alten Plugins funktionieren noch.

OCI-Register sind erstklassig. Die Speicherung von Diagrammen in Containerregistern (wie Docker Hub, GHCR, ECR, Harbor) war bereits in Helm 3 möglich. In Helm 4 ist OCI die klare Standardrichtung, und die alte index.yaml Stylisch-Diagramm-Repositories fühlen sich zunehmend wie ein Vermächtnis an.

Modernisierte interne Anlagen und SDK. Strukturierte Logging, gereinigte Go-APIs und viele interne Refactoring. Das ist vor allem für Werkzeuge wichtig, die auf Helm's Bibliotheken aufgebaut wurden.

Funktionieren meine alten Karten noch?

Das ist die wichtigste Frage und die gute Nachricht: Ja, bestehende Karten (apiVersion v2) funktionieren weiterhin in Helm 4. Die Instandhalter waren vorsichtig mit der Kompatibilität. Der Release-Verlauf von Helm 3 wird auch von Helm 4 verstanden, so dass Sie die CLI aktualisieren und Ihre bestehenden Releases weiter verwalten können.

Wo Sie Unterschiede bemerken könnten:

  • Einige Befehlszeilenflaggen wurden umbenannt oder entfernt. Die Scripts und CI-Pipelines, die Helm direkt anrufen, sollten getestet werden.
  • Serverseite anwenden kann Feldbesitzkonflikte aufdecken, die die alte Client-Seitenlogik stillschweigend überschrieb.
  • Werkzeuge, die Helm einbetten Die Software kann als Bibliothek (einige CI-Tools, ältere Betreiber) aktualisiert werden.

Ich schlage vor, Helm 4 zuerst mit Ihren Karten und Umgebungen zu testen. - Ich weiß . helm template, helm upgrade --dry-run, und ein echtes Upgrade auf ein Nicht-Produktionscluster.

Steuer 4 bittet nicht, Ihre Karten neu zu schreiben. Sie fordert Sie auf, Ihre Rohrleitungen zu testen, was Sie sowieso tun sollten.

Chart Gewohnheiten, die es wert sind, behalten zu werden

Eine große Version ist eine gute Ausrede , um deine Karten zu aufräumen:

  • Fügen Sie ein values.schema.json Also versagen falsche Werte schnell mit einem klaren Fehler anstelle einer kaputtem Einsatz.
  • Schreiben von Diagramm-Tests (helm test) und laufen helm lint in CI.
  • Nutzen Sie Bibliotheksdiagramme für gemeinsame Vorlagen statt Helfer zwischen Diagrammen zu kopieren.
  • Veröffentlichung in einem OIC-Register und Signaturdiagramme, zum Beispiel mit Cosign.
  • Die Werte-Dateien klein halten mit vernünftigen Fehlern in der Tabelle.
  • Versionen des Pinch-Diagramms in Ihren Einsätzen. Verwenden Sie nie "letzte".

Helm, Kustomize oder was anderes?

Helm bleibt die häufigste Art und Weise, Kubernetes-Anwendungen, insbesondere von Drittanbietern, zu verpacken. Fast jedes Open-Source-Projekt liefert eine Helm-Karte.

  • Anpassen ist ideal für Ihre eigenen Anwendungen, wenn Sie einfache YAML mit Überlagerungen pro Umgebung und keine Vorlagensprache wollen.
  • Kro, - Das ist Timoni. und CUE-basierte Instrumente bieten strukturiertere Ansätze, aber mit viel kleineren Ökosystemen.
  • Viele Teams verwenden sowohl Helm als auch Kustomize: Helm für Software von Drittanbietern, Kustomize für eigene Apps, oft von Argo CD oder Flux verwaltet.

Sollten Sie ein Upgrade machen?

Ja, aber nicht so eilig. Steuer 3 erhält noch eine Weile Sicherheitsbehebungen, also haben Sie Zeit. Erst die CLI in CI aktualisieren, dann die Karten testen und dann auf die Maschinen der Leute rollen.

Mein Verständnis: Ruder 4 ist ein leises Upgrade mit guten Grundlagen. Testen Sie Ihre Leitungen, reinigen Sie Ihre Karten und genießen Sie es, nichts neu zu schreiben.

Desly