Rolling Updates: Kubernetes-Deployments ohne Ausfall

TL;DR

• Rolling Updates ersetzen Pods schrittweise - alte Pods laufen weiter, bis neue bereit sind
• maxSurge und maxUnavailable steuern Geschwindigkeit und Sicherheit des Rollouts
• preStop Hooks geben laufenden Requests Zeit zum Abschließen bevor der Pod terminiert wird
• minReadySeconds verhindert, dass fehlerhafte Releases zu schnell ausgerollt werden
• Die Recreate-Strategie ist nur für Anwendungen sinnvoll, die nicht parallel in zwei Versionen laufen können

Wie Rolling Updates funktionieren

Bei einem Rolling Update erstellt Kubernetes schrittweise neue Pods mit der aktualisierten Version und entfernt alte Pods erst, wenn die neuen bereit sind. Zu keinem Zeitpunkt sind null Pods verfügbar.

Rollout-Ablauf (3 Replicas, maxSurge=1, maxUnavailable=0):

Schritt 1: [v1] [v1] [v1] [v2*]    ← neuer Pod wird erstellt
Schritt 2: [v1] [v1] [v2] [v2*]    ← v2 ready, ein v1 wird entfernt
Schritt 3: [v1] [v2] [v2] [v2*]    ← nächster v1 wird ersetzt
Schritt 4: [v2] [v2] [v2]          ← Rollout abgeschlossen

* = Pod noch nicht ready

Deployment-Strategie konfigurieren

Die wichtigsten Parameter

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 10
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: myapp:2.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5
            failureThreshold: 3

maxSurge: 1 erlaubt einen zusätzlichen Pod über der gewünschten Replica-Anzahl. Bei 4 Replicas laufen kurzzeitig 5 Pods.

maxUnavailable: 0 stellt sicher, dass immer alle gewünschten Replicas verfügbar bleiben. Kein Pod wird entfernt, bevor der Ersatz ready ist.

minReadySeconds: 10 wartet 10 Sekunden nach dem Ready-Status, bevor der nächste Pod ersetzt wird. Das gibt Zeit, Fehler zu erkennen, die erst unter Last auftreten.

Prozentangaben verwenden

Beide Parameter akzeptieren absolute Zahlen oder Prozente:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%        # bei 8 Replicas = 2 zusätzliche Pods
    maxUnavailable: 25%  # bei 8 Replicas = 2 Pods dürfen fehlen

Graceful Shutdown mit preStop Hooks

Das größte Problem bei Rolling Updates: Ein Pod wird aus dem Service entfernt, aber der Load Balancer schickt noch Requests an die alte IP. Die Lösung ist ein preStop Hook mit einer kurzen Wartezeit.

spec:
  containers:
    - name: app
      image: myapp:2.0
      ports:
        - containerPort: 8080
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 15"]
      terminationGracePeriodSeconds: 30

Was passiert beim Pod-Shutdown?

1. Pod wird als "Terminating" markiert
2. Pod wird aus Service-Endpoints entfernt     ←─┐
3. preStop Hook wird ausgeführt (sleep 15)      │ parallel
4. Kube-proxy/Ingress aktualisieren Routing    ←─┘
5. SIGTERM wird an den Container gesendet
6. App hat (30 - 15) = 15 Sekunden für Cleanup
7. Nach terminationGracePeriodSeconds: SIGKILL

Die 15 Sekunden sleep im preStop Hook geben dem Netzwerk-Stack Zeit, das Routing zu aktualisieren. Ohne diesen Delay erreichen Requests den Pod noch, während er bereits herunterfahren soll.

Graceful Shutdown in der Anwendung

Neben dem preStop Hook muss die Anwendung SIGTERM korrekt behandeln:

# Vollständiges Beispiel mit Readiness + preStop
spec:
  terminationGracePeriodSeconds: 45
  containers:
    - name: api
      image: api-server:3.1
      ports:
        - containerPort: 8080
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 15
        initialDelaySeconds: 10
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 15 && kill -SIGTERM 1"]

Rolling Update vs. Recreate

# Recreate-Strategie - ALLE Pods werden gleichzeitig gestoppt
spec:
  strategy:
    type: Recreate

Recreate nur verwenden wenn:

• Die Anwendung keine zwei Versionen gleichzeitig verträgt (z.B. DB-Schema-Inkompatibilität)
• Shared Volumes exklusiven Zugriff erfordern
• Lizenzierung nur eine Instanz erlaubt

In allen anderen Fällen ist RollingUpdate die bessere Wahl.

Rollout überwachen und steuern

# Rollout-Status verfolgen
kubectl rollout status deployment/web-app

# Rollout-Historie anzeigen
kubectl rollout history deployment/web-app

# Rollout pausieren (z.B. bei Problemen)
kubectl rollout pause deployment/web-app

# Rollout fortsetzen
kubectl rollout resume deployment/web-app

# Rollback zur vorherigen Version
kubectl rollout undo deployment/web-app

# Rollback zu einer bestimmten Revision
kubectl rollout undo deployment/web-app --to-revision=3

Setzen Sie revisionHistoryLimit auf mindestens 5, damit Sie im Notfall mehrere Versionen zurückrollen können. Der Default ist 10.

Checkliste für Zero-Downtime-Deployments

Damit Rolling Updates wirklich ausfallsfrei funktionieren, müssen mehrere Teile zusammenspielen:

1. Readiness Probe konfiguriert - ohne sie schickt Kubernetes sofort Traffic an neue Pods
2. preStop Hook mit sleep 10-15 - gibt dem Netzwerk Zeit zum Routing-Update
3. terminationGracePeriodSeconds höher als preStop-Delay + Shutdown-Zeit der App
4. minReadySeconds auf 5-15 Sekunden - fängt Fehler ab, die erst unter Last auftreten
5. maxUnavailable: 0 - garantiert volle Kapazität während des Rollouts
6. PodDisruptionBudget definiert - schützt auch bei Node-Drains

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 75%
  selector:
    matchLabels:
      app: web

FAQ

Was passiert wenn ein Rolling Update fehlschlägt?

Kubernetes stoppt den Rollout automatisch, wenn neue Pods nicht ready werden. Die alten Pods bleiben aktiv und bedienen Traffic. Mit kubectl rollout undo können Sie zur vorherigen Version zurückkehren.

Kann ich maxSurge und maxUnavailable beide auf 0 setzen?

Nein, mindestens einer der beiden Werte muss größer als 0 sein. Sonst kann Kubernetes weder zusätzliche Pods erstellen noch bestehende entfernen - der Rollout wäre unmöglich.

Wie lange sollte der preStop Hook warten?

10-15 Sekunden reichen in den meisten Clustern. Der Delay muss lang genug sein, damit kube-proxy und Ingress-Controller das Routing aktualisieren. In großen Clustern mit vielen Nodes kann es etwas länger dauern.

Wann brauche ich minReadySeconds?

Immer wenn Fehler erst unter Last auftreten, z.B. Memory Leaks, Connection-Pool-Probleme oder fehlerhafte Konfigurationen. Ohne minReadySeconds rollt Kubernetes sofort weiter, sobald die Readiness Probe einmal erfolgreich war.

Wie unterscheiden sich Rolling Updates von Blue-Green Deployments?

Bei Rolling Updates laufen alte und neue Version kurzzeitig parallel im selben Service. Bei Blue-Green gibt es zwei komplette Umgebungen und der Traffic wird per Service-Switch umgeleitet. Blue-Green braucht doppelte Ressourcen, ermöglicht aber sofortiges Umschalten.