Kubernetes Rolling Updates: Zero-Downtime Deployments mit Rollback

TL;DR

• Rolling Updates ersetzen Pods schrittweise statt alle auf einmal -- Nutzer merken nichts vom Deployment.
• maxSurge und maxUnavailable steuern Geschwindigkeit vs. Stabilitaet des Rollouts.
• Ohne korrekte Readiness Probes sind Rolling Updates wertlos, weil Traffic an nicht-bereite Pods geht.
• kubectl rollout undo macht jedes fehlerhafte Deployment in Sekunden rueckgaengig.
• Canary und Blue/Green sind keine Alternativen, sondern Ergaenzungen -- je nach Risikoprofil der Anwendung.

Was bei einem Rolling Update tatsaechlich passiert

Ein Rolling Update ist die Standard-Deployment-Strategie in Kubernetes. Wenn du das Container-Image in einem Deployment aenderst, erstellt der Deployment Controller einen neuen ReplicaSet und faehrt dort schrittweise Pods hoch, waehrend er im alten ReplicaSet Pods herunterscaliert.

Der entscheidende Punkt: Kubernetes wartet, bis ein neuer Pod den Readiness Check besteht, bevor er einen alten Pod terminiert. So bleibt die Gesamtzahl der verfuegbaren Pods waehrend des gesamten Prozesses stabil.

Was viele uebersehen: Das alte ReplicaSet wird nicht geloescht. Es bleibt mit replicas: 0 erhalten. Das ist die Grundlage fuer Rollbacks -- Kubernetes muss bei einem undo nur die Replica-Zahlen wieder tauschen.

Die zwei Parameter, die alles steuern

maxSurge und maxUnavailable sind die einzigen zwei Stellschrauben fuer das Verhalten eines Rolling Updates. Trotzdem werden sie haeufig falsch konfiguriert.

Beide akzeptieren absolute Zahlen oder Prozentwerte. Bei Prozent rundet Kubernetes maxSurge auf und maxUnavailable ab.

Beispiel: Bei 4 Replicas und den Defaults (25%/25%) ergibt sich:

• maxSurge = ceil(4 * 0.25) = 1 zusaetzlicher Pod
• maxUnavailable = floor(4 * 0.25) = 1 Pod darf fehlen
• Es laufen also immer mindestens 3 und maximal 5 Pods

Konservative Konfiguration fuer kritische Services

Wenn du null Toleranz fuer Ausfaelle hast:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
    spec:
      containers:
      - name: payment
        image: registry.example.com/payment:v2.3.1
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /livez
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Mit maxUnavailable: 0 stellt Kubernetes sicher, dass nie weniger als 4 Pods bereit sind. Der neue Pod muss komplett ready sein, bevor ein alter terminiert wird. Das ist langsamer, aber sicherer.

Aggressive Konfiguration fuer schnelle Rollouts

Fuer nicht-kritische interne Services, bei denen Geschwindigkeit wichtiger ist:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 50%
    maxUnavailable: 25%

Hier duerfen bei 8 Replicas bis zu 12 Pods gleichzeitig laufen und 2 duerfen fehlen. Das Deployment ist in einem Bruchteil der Zeit fertig.

Warum Readiness Probes nicht optional sind

Ohne Readiness Probes betrachtet Kubernetes einen Pod als ready, sobald alle Container gestartet sind. Bei einer Java-Anwendung, die 30 Sekunden zum Starten braucht, heisst das: Kubernetes terminiert den alten Pod, der neue bekommt Traffic, kann aber noch nicht antworten. Resultat: 5xx-Fehler.

Die Readiness Probe muss tatsaechlich die Anwendungslogik pruefen, nicht nur ob der Port offen ist. Ein guter Health-Endpoint prueft Datenbankverbindung, Cache-Verfuegbarkeit und ggf. externe Abhaengigkeiten.

Mehr dazu im Detail unter Liveness vs. Readiness Probes.

Deployment-Strategien im Vergleich

Rolling Updates sind fuer die meisten Workloads die richtige Wahl. Blue/Green und Canary ergeben Sinn, wenn du zusaetzliche Absicherung brauchst -- etwa bei Aenderungen an API-Vertraegen oder Datenbankschemas. Details zu Canary findest du unter Canary Deployments in Kubernetes.

Rollback in der Praxis

Jedes Deployment in Kubernetes fuehrt eine Revisionshistorie. Du kannst jederzeit pruefen, welche Revisionen existieren:

# Revisionshistorie anzeigen
kubectl rollout history deployment/payment-service

# Details einer spezifischen Revision
kubectl rollout history deployment/payment-service --revision=3

# Rollback auf vorherige Version
kubectl rollout undo deployment/payment-service

# Rollback auf spezifische Revision
kubectl rollout undo deployment/payment-service --to-revision=2

# Status des Rollouts ueberwachen
kubectl rollout status deployment/payment-service --timeout=120s

Standardmaessig speichert Kubernetes die letzten 10 Revisionen (revisionHistoryLimit). Fuer kritische Services lohnt es sich, diesen Wert zu erhoehen:

spec:
  revisionHistoryLimit: 20

Mehr zu Rollback-Strategien und deren Automatisierung unter Kubernetes Rollback-Strategien.

Typische Fehler und wie du sie vermeidest

1. Keine Resource Requests/Limits gesetzt

Ohne Requests kann der Scheduler Pods auf bereits ausgelastete Nodes legen. Waehrend eines Rolling Updates fuehrt das zu Evictions und Instabilitaet. Setze immer mindestens Requests.

2. PodDisruptionBudget vergessen

Ein PDB schuetzt vor zu vielen gleichzeitigen Unterbrechungen, auch ausserhalb von Deployments (z.B. Node-Drain bei Cluster-Updates):

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: payment-service

3. Container-Images mit latest-Tag

Rolling Updates funktionieren nur zuverlaessig mit versionierten Image-Tags. Bei latest weiss Kubernetes nicht, ob sich das Image geaendert hat, und startet moeglicherweise kein Update. Nutze semantische Versionierung oder Git-SHA als Tag.

4. terminationGracePeriodSeconds zu kurz

Standardmaessig gibt Kubernetes einem Pod 30 Sekunden zum Herunterfahren. Wenn deine Anwendung laenger braucht, um laufende Requests abzuschliessen, erhoehe diesen Wert. Gleichzeitig sollte deine Anwendung SIGTERM korrekt behandeln und graceful shutdown implementieren.

progressDeadlineSeconds: Das versteckte Timeout

Ein Parameter, den die meisten vergessen: progressDeadlineSeconds. Er definiert, wie lange Kubernetes auf Fortschritt beim Rollout wartet, bevor es das Deployment als fehlgeschlagen markiert. Der Default ist 600 Sekunden (10 Minuten).

Wenn ein neuer Pod wiederholt abstuerzt (CrashLoopBackOff) oder nie ready wird, haengt das Deployment ohne dieses Timeout ewig im Status Progressing. Mit einem angemessenen Deadline erhaeltst du eine klare Fehlermeldung:

spec:
  progressDeadlineSeconds: 300
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Nach Ablauf der Deadline setzt Kubernetes die Condition Progressing auf False mit der Reason ProgressDeadlineExceeded. Das laesst sich im Monitoring abfangen und automatisch einen Rollback ausloesen.

Pruefe den aktuellen Status eines Rollouts:

kubectl rollout status deployment/payment-service --timeout=300s
# Exit Code 1, wenn Deadline ueberschritten

Fuer Resource-bezogene Probleme waehrend Rollouts, z.B. wenn neue Pods nicht gescheduled werden koennen, siehe Kubernetes Resource Management.

Rolling Updates in der CI/CD-Pipeline

In einer realen Umgebung loest du Rolling Updates nicht manuell aus. Ein GitOps-Workflow mit ArgoCD oder Flux ueberwacht dein Git-Repository und wendet Aenderungen automatisch an.

Der typische Flow:

1. CI-Pipeline baut neues Image, tagged mit Git-SHA
2. Pipeline aktualisiert das Image-Tag im Deployment-Manifest (oder Helm Values)
3. Git-Push in den Deployment-Branch
4. ArgoCD erkennt die Aenderung und fuehrt kubectl apply aus
5. Kubernetes startet Rolling Update

Fuer Details zur GitOps-Integration siehe GitOps mit Kubernetes und ArgoCD Tutorial.

Monitoring waehrend des Rollouts

Ein Deployment ohne Monitoring ist blind. Waehrend eines Rolling Updates solltest du mindestens diese Metriken beobachten:

• HTTP Error Rate: Steigen 5xx-Fehler an, stimmt etwas mit der neuen Version nicht.
• Latenz (p95/p99): Erhoehte Latenz kann auf Probleme in der neuen Version hinweisen.
• Pod Restart Count: Haeufige Restarts deuten auf CrashLoopBackOff hin.
• Ready Pod Count: Faellt die Zahl der Ready-Pods, blockiert etwas den Rollout.

Nuetzliche kubectl-Befehle fuer Live-Monitoring waehrend eines Rollouts:

# Rollout-Status in Echtzeit verfolgen
kubectl rollout status deployment/payment-service -w

# Pods beobachten -- zeigt Status-Uebergaenge
kubectl get pods -l app=payment-service -w

# Events fuer das Deployment pruefen (zeigt Scheduling-Probleme)
kubectl describe deployment payment-service | tail -20

# ReplicaSets vergleichen: alt vs. neu
kubectl get replicasets -l app=payment-service \
  -o custom-columns=NAME:.metadata.name,DESIRED:.spec.replicas,READY:.status.readyReplicas,AGE:.metadata.creationTimestamp

Mit Prometheus und Grafana lassen sich diese Metriken in Echtzeit visualisieren. Details zum Monitoring-Stack unter Kubernetes Observability.

Zusammenfassung

Rolling Updates sind der Standardfall -- und fuer die meisten Workloads die richtige Wahl. Die Konfiguration ist ueberschaubar, solange du maxSurge, maxUnavailable, Readiness Probes und Resource Requests korrekt setzt. Der eingebaute Rollback-Mechanismus ueber ReplicaSet-Revisionen gibt dir ein Sicherheitsnetz bei jedem Deployment.

Der wichtigste Ratschlag: Teste deine Rollback-Prozedur regelmaessig. Ein Rollback, den du nie geuebt hast, ist im Ernstfall kein Rollback.

Wenn du Unterstuetzung bei der Einrichtung stabiler Deployment-Pipelines brauchst oder deine bestehende Konfiguration reviewen lassen moechtest, melde dich unter /kontakt.