Releases, Revisionen und Rollbacks

Lernziele

Nach dieser Lektion beherrschst du den kompletten Release-Lifecycle: Du kannst mit helm history Revisionen lesen, mit helm rollback gezielt zurückrollen und erklären, warum ein Rollback eine neue Revision erzeugt. Du kennst die Release-Status wie deployed, superseded und pending-upgrade, weißt, was --history-max begrenzt, und kannst ein hängengebliebenes Upgrade wieder flottmachen.

Das Problem: Deployments ohne Gedächtnis

Stell dir vor, du deployst mit kubectl apply -f und das neue Image crasht in Produktion. Was war der Stand davor? Welche Konfiguration lief zuletzt stabil? Ohne zusätzliche Disziplin — Git-Tags, Manifest-Archive — hast du keine verlässliche Antwort, und unter Incident-Druck ist „ich rekonstruiere das mal aus Git” ein schlechter Plan.

Helm löst das mit dem Release-Begriff aus Lektion 1: Jede Installation und jedes Upgrade wird als Revision festgehalten — vollständig, mit gerenderten Manifesten und den verwendeten Values, gespeichert als Secret im Zielnamespace (sh.helm.release.v1.<name>.v<revision>). Das Release hat damit ein Gedächtnis, das unabhängig von Git und CI existiert.

Revisionen lesen: helm history und die Release-Status

Der zentrale Befehl ist helm history:

helm history my-app

Die Ausgabe zeigt pro Revision Nummer, Zeitstempel, Status, Chart-Version und eine Beschreibung. Die Status musst du deuten können:

• deployed — die aktuell aktive Revision. Es gibt immer höchstens eine.
• superseded — eine frühere Revision, von einer neueren abgelöst.
• failed — das Upgrade ist durchgelaufen, aber fehlgeschlagen (z. B. von der API abgelehnt).
• pending-install / pending-upgrade / pending-rollback — eine Operation läuft gerade. Wenn dieser Status dauerhaft dasteht, wurde ein Helm-Prozess mittendrin abgebrochen — das klassische Symptom eines gekillten CI-Jobs.
• uninstalled — das Release wurde mit helm uninstall --keep-history entfernt.

Ergänzend zeigt dir helm status my-app den Zustand der aktiven Revision und helm get values my-app die Values, mit denen sie installiert wurde — mit --revision N auch für jede frühere Revision. Das ist Gold wert, wenn du wissen willst, was genau sich zwischen zwei Deployments geändert hat.

Rollback: vorwärts in die Vergangenheit

helm rollback my-app 2

rollt auf den Stand von Revision 2 zurück. Der Mechanismus ist der Punkt, den Interviewer hören wollen: Helm holt die gerenderten Manifeste und Values aus dem Secret von Revision 2 und wendet sie als neue Revision an. Lief dein Release auf Revision 5, erzeugt der Rollback Revision 6 — mit dem Inhalt von Revision 2. Die Historie wird nie zurückgespult, sie wächst nur. Das ist bewusst so: Auch der Rollback selbst ist ein nachvollziehbares Ereignis mit Zeitstempel.

Zwei Eigenschaften musst du ehrlich einordnen. Erstens: Der Rollback stellt nur wieder her, was Helm verwaltet — Manifeste und Values. Daten in der Datenbank, ein bereits gelaufenes Schema-Migrationsskript oder manuell per kubectl edit geänderte Felder rollt er nicht zurück. Zweitens: Ohne Revisionsnummer (helm rollback my-app) geht Helm zur vorherigen Revision — nach einem fehlgeschlagenen Upgrade meist das Richtige, aber im Skript solltest du explizit sein.

Für CI-Pipelines relevant ist --atomic beim Upgrade: Schlägt das Upgrade fehl, rollt Helm automatisch zurück. Zusammen mit --wait (warten, bis Ressourcen ready sind) und --timeout bekommst du ein Upgrade, das sich selbst aufräumt — um den Preis, dass ein hängendes Deployment die Pipeline bis zum Timeout blockiert.

Aufräumen: uninstall, —keep-history und —history-max

helm uninstall my-app löscht die Ressourcen des Release und standardmäßig die komplette Historie — danach gibt es nichts mehr, wohin du zurückrollen könntest. Mit helm uninstall --keep-history bleiben die Release-Secrets erhalten (Status uninstalled), und du kannst das Release später per helm rollback wiederbeleben. In regulierten Umgebungen ist --keep-history auch ein Audit-Werkzeug: Die Historie belegt, was wann lief.

Die Kehrseite des Release-Gedächtnisses: Jede Revision ist ein Secret, und bei einem Release, das per CI mehrmals täglich deployt wird, sammeln sich die an. helm upgrade begrenzt die Historie standardmäßig auf die letzten 10 Revisionen; mit --history-max stellst du das ein. Mehr Historie heißt mehr Rollback-Spielraum, aber auch mehr Secrets im Namespace — bei großen Charts mit vielen Manifesten sind die Secrets nicht klein.

Praxis: einen kaputten Upgrade-Zyklus durchspielen

Das folgende Lab erzeugt absichtlich ein fehlgeschlagenes Upgrade und übt den Rollback (lokaler Cluster, z. B. kind):

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Revision 1: funktionierende Installation
helm install demo bitnami/nginx --set replicaCount=1

# Revision 2: Upgrade mit kaputtem Image-Tag
helm upgrade demo bitnami/nginx \
  --set image.tag=does-not-exist \
  --wait --timeout 60s

# Das Upgrade läuft in den Timeout. Jetzt: Lagebild
helm history demo
helm status demo
kubectl get pods   # ImagePullBackOff

# Welche Values hatte Revision 1?
helm get values demo --revision 1

# Rollback und Kontrolle
helm rollback demo 1 --wait
helm history demo   # Revision 3 = Stand von Revision 1, Status deployed

# Aufräumen, Historie behalten und wiederbeleben
helm uninstall demo --keep-history
helm history demo
helm rollback demo 3
helm uninstall demo

Beobachte zwei Dinge: Nach dem fehlgeschlagenen Upgrade steht Revision 2 auf failed, und der Rollback erzeugt Revision 3 statt Revision 2 zu löschen. Genau diese Ausgabe von helm history solltest du im Interview aus dem Kopf skizzieren können.

Typische Stolperfallen

Hängendes pending-upgrade: Ein abgebrochener CI-Job lässt das Release im Status pending-upgrade zurück, und jedes weitere Upgrade scheitert mit „another operation is in progress”. Der saubere Ausweg: helm rollback auf die letzte deployed-Revision. Das Release-Secret der hängenden Revision von Hand zu löschen funktioniert auch, ist aber der Holzhammer.

Rollback erwartet, dass Daten zurückkommen: Helm stellt Manifeste wieder her, keine Datenbank-Inhalte und keine gelaufenen Migrationen. Wer Schema-Änderungen deployt, braucht eine Rollback-Strategie neben Helm — abwärtskompatible Migrationen oder Backups.

helm uninstall ohne Nachdenken: Standardmäßig ist danach auch die Historie weg. Wenn die Option „wiederherstellen” offen bleiben soll: --keep-history.

Rollback nach Values-Drift: Wenn das letzte Upgrade per --set Werte gesetzt hat, die nirgendwo dokumentiert sind, stellt der Rollback einen Zustand her, den niemand mehr in einer Datei stehen hat. Das nächste reguläre Upgrade überschreibt ihn dann wieder. Values gehören in versionierte Dateien — das Problem aus Lektion 1 schlägt hier voll durch.

Interview-Vorbereitung

Die Standardfrage lautet „Wie funktionieren Rollbacks in Helm?”. Starke Antwort in drei Schritten: Speichermodell (jede Revision liegt komplett — Manifeste plus Values — als Secret im Namespace), Mechanik (Rollback wendet den alten Stand als neue Revision an, Historie wächst monoton) und Grenzen (keine Daten, keine Migrationen, keine Out-of-Band-Änderungen). Wer die Grenzen von sich aus nennt, signalisiert Produktionserfahrung.

Follow-ups, mit denen du rechnen solltest:

• „Was bedeutet der Status pending-upgrade und wie behebst du ihn?” — abgebrochener Helm-Prozess; Rollback auf die letzte deployed-Revision.
• „Was macht --atomic?” — automatischer Rollback bei fehlgeschlagenem Upgrade, sinnvoll in CI zusammen mit --wait und --timeout.
• „Kann man nach helm uninstall zurückrollen?” — nur wenn mit --keep-history deinstalliert wurde.
• „Warum erzeugt ein Rollback eine neue Revision?” — Nachvollziehbarkeit: Auch der Rollback ist ein auditierbares Ereignis, die Historie bleibt lückenlos.

Zusammenfassung

Ein Release führt Buch: Jede Operation erzeugt eine Revision, gespeichert als Secret im Zielnamespace, begrenzt durch --history-max. helm history zeigt die Zeitleiste mit Status wie deployed, superseded, failed und pending-*; helm rollback wendet einen alten Stand als neue Revision an und rollt weder Daten noch manuelle Änderungen zurück. --atomic macht Upgrades selbstheilend, --keep-history hält die Tür nach uninstall offen.

Bisher haben wir Charts aus dem Bitnami-Repository benutzt, ohne zu fragen, wie sie dort hinkommen. Die nächste Lektion zeigt, wie Chart-Repositories funktionieren und wie du eigene Charts paketierst und veröffentlichst.