Rolling-Deployment: Neue Versionen schrittweise ausrollen

Rolling-Deployment ist eine Auslieferungsstrategie, bei der eine neue Softwareversion schrittweise über mehrere Instanzen verteilt wird, statt alle auf einmal zu ersetzen. Es ist der Standard-Ansatz in Kubernetes und bei vielen Cloud-Plattformen, weil er ohne zusätzliche Infrastruktur auskommt.

So funktioniert das Rolling Update

Bei einem Rolling Update werden die alten Instanzen nach und nach durch neue ersetzt. Kubernetes steuert das über zwei Parameter: maxSurge legt fest, wie viele Pods zusätzlich zur gewünschten Anzahl entstehen dürfen, maxUnavailable bestimmt, wie viele Pods gleichzeitig ausfallen dürfen. Typische Werte sind 25 % beziehungsweise 25 %.

kubectl set image deployment/web-api web-api=app:v2
kubectl rollout status deployment/web-api
kubectl rollout history deployment/web-api

Jede neue Instanz muss erst einen Health Check bestehen, bevor die nächste alte beendet wird. So bleibt die Anwendung während des gesamten Updates verfügbar.

Vorteile und Nachteile

Vorteile: keine doppelte Infrastruktur nötig, Downtime minimal, fein granulare Kontrolle über Tempo und Ausfalltoleranz.
Nachteile: alte und neue Version laufen zeitgleich — Datenbankschemata müssen rückwärtskompatibel sein; ein Fehler wird erst nach und nach sichtbar.

Der Rollback läuft beim Rolling-Deployment als umgekehrter Rolling-Prozess: kubectl rollout undo deployment/web-api setzt die vorherige Revision erneut schrittweise aus. Details dazu stehen im Artikel Rollback-Deployment.