Sobald ein Chart existiert, geht es bei der täglichen Arbeit mit Helm fast ausschließlich um die Verwaltung von Releases: sie installieren, upgraden, wenn sich das Chart oder seine Values ändern, und gelegentlich eines zurückrollen. Diese Anleitung behandelt diesen Lebenszyklus von Anfang bis Ende.

Die Kernbefehle

Befehl	Was er tut
helm install NAME CHART	Erstellt ein neues Release aus einem Chart.
helm upgrade NAME CHART	Wendet Änderungen auf ein bestehendes Release an.
helm upgrade --install NAME CHART	Installiert, wenn das Release noch nicht existiert, upgradet, wenn es existiert.
helm list	Listet Releases im aktuellen Namespace auf (-A für jeden Namespace).
helm status NAME	Zeigt den aktuellen Zustand eines Releases und seine NOTES.txt erneut.
helm rollback NAME REVISION	Setzt ein Release auf eine frühere Revision zurück.
helm uninstall NAME	Entfernt ein Release und seine Ressourcen.

helm upgrade --install verdient eine eigene Erwähnung: Es ist das Muster, das fast jede CI/CD-Pipeline tatsächlich nutzt, weil es „stelle sicher, dass dieses Release mit dieser Konfiguration existiert“ bedeutet, ohne dass das Skript wissen oder prüfen muss, ob es ein erstes oder das hundertste Deployment ist.

Jede Änderung ist eine nummerierte Revision

helm install web ./webapp
helm list

Eine frische Installation ist Revision 1. Jedes folgende upgrade fügt die nächste Nummer hinzu, und rollback fügt ebenfalls eine hinzu, da ein Rollback keine Zeitmaschine ist, sondern eine neue Revision, deren Inhalt zufällig einem älteren entspricht:

Operation	Resultierende Revision
helm install	1
helm upgrade	2
helm upgrade	3
helm rollback web 1	4 (Inhalt entspricht Revision 1, aber die Nummer steigt weiter)

helm history web

listet jede Revision mit Status, Chart-Version und App-Version auf, woraus rollback und die untenstehenden Inspektionsbefehle lesen.

Zurückrollen, wenn ein Upgrade schiefgeht

helm rollback web 2
kubectl rollout status deployment/web

Auf eine bestimmte Revisionsnummer zurückzurollen ist der übliche Fall. helm rollback web ohne Nummer kehrt zur unmittelbar vorherigen zurück. Weil Rollback eine neue Revision erzeugt, bringt dich ein erneutes Zurückrollen zurück zum Ausgangspunkt, es macht das Rollback selbst nicht rückgängig; prüfe helm history, um sicher zu sein, auf welche Revision du tatsächlich zurücksetzt.

Ein Release untersuchen, ohne es zu ändern

helm status web
helm get values web
helm get manifest web
helm diff upgrade web ./webapp -f values-prod.yaml   # erfordert das helm-diff-Plugin

get values zeigt, was für dieses Release tatsächlich geliefert wurde, nützlich, wenn ein laufendes Release nicht zu dem passt, was eine Values-Datei auf der Platte vermuten lässt. get manifest zeigt das exakte von Helm angewendete Kubernetes-YAML nach dem Templating, die Ground Truth beim Debuggen einer Abweichung zwischen Chart-Quelle und Live-Zustand. helm diff ist nicht eingebaut, es ist ein weit verbreitetes Community-Plugin (helm plugin install https://github.com/databus23/helm-diff), und es lohnt sich, es vor einem Upgrade zu haben, bei dem du unsicher bist, da es genau zeigt, was sich ändern würde, ohne etwas anzuwenden.

Deinstallieren und Historie behalten oder verwerfen

helm uninstall web
helm uninstall web --keep-history

Standardmäßig entfernt die Deinstallation sowohl die Ressourcen des Releases als auch seine Historie. --keep-history entfernt die Ressourcen, behält aber den Eintrag des Releases, sodass helm history web und helm rollback danach weiter funktionieren, falls du es wieder einsetzen musst oder einfach einen Audit-Trail dessen willst, was früher lief. helm list zeigt ein deinstalliertes Release auch mit --keep-history nicht, außer du fügst -a/--all hinzu.

Was sich in Helm 4 geändert hat

Wenn du Helm 4 nutzt, beachte einen Verhaltensunterschied: Neue Installationen verwenden standardmäßig Kubernetes’ Server-Side Apply statt des Client-Side Apply von Helm 3, was Feld-Besitz und Konflikte zwischen Werkzeugen vorhersagbarer behandelt. Upgrades und Rollbacks eines unter Helm 3 erstellten Releases nutzen weiter Client-Side Apply, sofern du nicht ausdrücklich --server-side übergibst, sodass sich Workflows mit gemischten Versionen nicht plötzlich im Verhalten ändern. Das ändert nichts an den obigen Befehlen, nur daran, wie das resultierende Manifest angewendet wird.