So führen Sie Rolling Updates mit Null-Ausfallzeit in Kubernetes-Bereitstellungen durch

Kubernetes-Rolling-Updates können Pods ohne sichtbare Unterbrechung ersetzen, aber nur, wenn Ihre Bereitstellung und Ihre Anwendung sich darüber einig sind, wann ein Pod bereit ist und wie er heruntergefahren werden soll. Die Standardstrategie hilft, schützt Sie jedoch nicht vor schlechten Readiness-Probes, inkompatiblen Releases oder verlorenen laufenden Anfragen.

Um eine echte Null-Ausfallzeit zu erreichen, ist jedoch mehr als nur die Standard-Kubernetes-Konfiguration erforderlich. Sie erfordert eine sorgfältige Koordination zwischen dem Bereitstellungsmanifest, den Health-Endpunkten der Anwendung und dem Graceful-Termination-Prozess. Diese Anleitung bietet einen umfassenden, schrittweisen Ansatz zur Konfiguration von Kubernetes-Bereitstellungen, um sicherzustellen, dass Anwendungsaktualisierungen nahtlos und für den Endbenutzer unsichtbar sind.

Diese Anleitung behandelt Readiness-Probes, maxSurge, maxUnavailable und Graceful Termination, damit Ihr Dienst während eines Rollouts die Kapazität behält.

Voraussetzungen für Null-Ausfallzeit

Bevor Sie das Kubernetes-Manifest konfigurieren, muss die zugrunde liegende Anwendung bestimmte Prinzipien einhalten, um Bereitstellungen mit Null-Ausfallzeit zu unterstützen:

Abwärtskompatibilität der Anwendung: Für den kurzen Zeitraum, in dem sowohl die alte als auch die neue Version der Anwendung gleichzeitig ausgeführt werden, müssen sie mit gemeinsam genutzten Ressourcen (Datenbanken, Warteschlangen, Caches) kompatibel sein.
Idempotenz: Operationen, die von beiden Versionen verarbeitet werden könnten, müssen ohne negative Nebenwirkungen wiederholbar sein.
Graceful Termination: Die Anwendung muss so programmiert sein, dass sie das von Kubernetes gesendete SIGTERM-Signal erkennt und ordnungsgemäß keine neuen Verbindungen mehr annimmt, während sie laufende Anfragen beendet, bevor sie beendet wird.

Verstehen der Kubernetes-Rolling-Update-Strategie

Kubernetes-Bereitstellungen verwenden standardmäßig die RollingUpdate-Strategie. Diese Methode stellt sicher, dass die alte Anwendungsversion nicht vollständig heruntergefahren wird, bevor die neue Version betriebsbereit ist, und steuert den Übergang mithilfe von zwei primären Parametern:

Parameter	Beschreibung	Auswirkung auf Null-Ausfallzeit
`maxSurge`	Definiert die maximale Anzahl von Pods, die über der gewünschten Anzahl von Replikaten erstellt werden können. Kann eine absolute Zahl oder ein Prozentsatz sein (Standard: 25%).	Steuert die Geschwindigkeit des Rollouts und stellt sicher, dass die Kapazität vorübergehend erhöht wird.
`maxUnavailable`	Definiert die maximale Anzahl von Pods, die während des Updates nicht verfügbar sein können. Kann eine absolute Zahl oder ein Prozentsatz sein (Standard: 25%).	Entscheidend für Null-Ausfallzeit. Wenn dieser Wert auf 0% gesetzt wird, werden keine aktiven Pods beendet, bis die neuen Pods vollständig `Ready` sind.

Empfohlene Strategie für Null-Ausfallzeit

Für die höchste Verfügbarkeit besteht die beste Konfiguration oft darin, einen Kapazitätsverlust von Null sicherzustellen:

maxUnavailable: 0 (Stellen Sie sicher, dass die Kapazität niemals sinkt).
maxSurge: 1 oder 25% (Ermöglichen Sie, dass die Kapazität kurzzeitig das Ziel überschreitet, um sicherzustellen, dass ein neuer Pod bereit ist, bevor ein alter beendet wird).

Schritt 1: Implementieren von Readiness-Probes

Die Readiness Probe ist der wichtigste Mechanismus zur Gewährleistung von Updates mit Null-Ausfallzeit. Kubernetes verlässt sich auf diese Sonde, um zu bestimmen, ob ein neuer Pod bereit ist, Benutzerverkehr zu empfangen, und ob ein alter Pod noch aktiv Verkehr bedient.

Liveness vs. Readiness

Liveness Probe: Teilt Kubernetes mit, ob der Container gesund und funktionsfähig ist. Wenn sie fehlschlägt, wird der Container neu gestartet.
Readiness Probe: Teilt Kubernetes mit, ob der Container bereit ist, Anfragen zu bedienen. Wenn sie fehlschlägt, wird der Pod aus den zugehörigen Service-Endpunkten entfernt, wodurch der Verkehr von ihm weggeleitet wird, bis er bereit ist.

Bei Rolling Updates wird die Readiness Probe verwendet, um den Übergang zu steuern. Kubernetes wird nicht fortfahren, einen alten Pod zu beenden, bis ein neu erstellter Pod erfolgreich seine Readiness-Prüfung bestanden hat.

# deployment.yaml Auszug
spec:
  containers:
  - name: my-app
    image: myregistry/my-app:v2.0
    ports:
    - containerPort: 8080
    
    # --- Readiness Probe Konfiguration ---
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 15  # Zeit bis zum ersten Sondenversuch
      periodSeconds: 5         # Wie oft die Prüfung durchgeführt wird
      timeoutSeconds: 3
      failureThreshold: 3      # Anzahl aufeinanderfolgender Fehler, um Pod als nicht bereit zu markieren

    # --- Liveness Probe Konfiguration (Standard Health Check) ---
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 60
      periodSeconds: 10

Tipp: Stellen Sie sicher, dass der /health/ready-Endpunkt Ihrer Anwendung nur dann einen Erfolgscode (HTTP 200-299) zurückgibt, wenn die Initialisierung, Datenbankverbindungen und andere externe Abhängigkeiten vollständig betriebsbereit sind.

Schritt 2: Konfigurieren der Bereitstellungsstrategie

Um eine echte Null-Ausfallzeit zu erzwingen, konfigurieren wir die Rolling-Update-Strategie explizit so, dass ein Abfall der Anzahl verfügbarer Replikate verhindert wird.

In dieser Konfiguration erstellt Kubernetes zuerst einen neuen Pod (maxSurge: 1). Sobald der neue Pod seine Readiness-Probe bestanden hat, beendet Kubernetes erst dann einen alten Pod. Da maxUnavailable 0 ist, sinkt die Dienstkapazität niemals unter die Zielreplikatanzahl.

# deployment.yaml Auszug
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # Stellt sicher, dass die Kapazität niemals unter die gewünschte Replikatanzahl (4) fällt
      maxUnavailable: 0 
      # Erlaubt die Erstellung eines zusätzlichen Pods während des Rollouts
      maxSurge: 1 
  template:
    # ... Containerspezifikation ...

Schritt 3: Sicherstellen von Graceful Termination

Selbst mit robusten Readiness-Probes riskiert die Anwendung, laufende Anfragen zu verlieren, wenn sie sofort nach Erhalt des Terminationssignals herunterfährt.

Kubernetes folgt einer bestimmten Terminationssequenz:

Der Pod wird als Terminating markiert.
Der Pod wird aus den Service-Endpunkten entfernt (der Verkehr wird nicht mehr zu ihm geleitet).
Der Pre-Stop-Hook (falls definiert) wird ausgeführt.
Der Container empfängt das SIGTERM-Signal.
Kubernetes wartet für die Dauer von terminationGracePeriodSeconds (Standard: 30 Sekunden).
Wenn der Container noch läuft, empfängt er ein nicht verhandelbares SIGKILL.

Um ein ordnungsgemäßes Herunterfahren zu gewährleisten, muss die Anwendung SIGTERM verarbeiten, und terminationGracePeriodSeconds muss lang genug sein, damit die Anwendung vorhandene Anfragen beenden kann.

# deployment.yaml Auszug, innerhalb der Pod-Vorlagenspezifikation
spec:
  terminationGracePeriodSeconds: 45 # Pod-Ebene-Einstellung
  containers:
  - name: my-app
    image: myregistry/my-app:v2.0
    lifecycle:
      preStop:
        exec:
          # Gibt Endpunktaktualisierungen und externen Load-Balancern Zeit zum Entleeren.
          command: ["/bin/sh", "-c", "sleep 10"]

Best Practice: Ihre Anwendung sollte keine neuen Arbeiten mehr annehmen, wenn sie SIGTERM empfängt, und dann laufende Anfragen beenden, bevor sie beendet wird. Ein etwas längeres terminationGracePeriodSeconds, z. B. 45 oder 60 Sekunden, hilft, harte Beendigungen für langsamere Anfragen zu verhindern.

Schritt 4: Durchführen und Überwachen des Updates

Sobald Ihr Bereitstellungsmanifest die optimierte Strategie und robuste Sonden enthält, ist die Durchführung des Updates unkompliziert.

Aktualisieren des Image-Tags: Ändern Sie Ihr Bereitstellungsmanifest, um die neue Image-Version widerzuspiegeln (z. B. v2.0 auf v2.1).

Anwenden der Konfiguration:

kubectl apply -f deployment.yaml

Alternativ können Sie das Image direkt patchen:

kubectl set image deployment/my-web-deployment my-app=myregistry/my-app:v2.1

Überwachen des Rollout-Status: Beobachten Sie, wie Kubernetes die Phasen durchläuft, und überprüfen Sie, ob die Anzahl der bereiten Pods niemals unter die gewünschte Anzahl fällt.
```
kubectl rollout status deployment/my-web-deployment
```
Überprüfen der Pod-Verfügbarkeit: Beobachten Sie den Pod-Status, um zu bestätigen, dass die alten Pods (v2.0) erst ordnungsgemäß beendet werden, nachdem die neuen Pods (v2.1) vollständig bereit sind.
```
kubectl get pods -l app=my-web-deployment -w
```

Fortgeschrittene Überlegungen

Verwenden von Pod Disruption Budgets (PDBs)

Während eine Bereitstellungsstrategie Rollouts verwaltet, begrenzt ein Pod Disruption Budget (PDB) freiwillige Unterbrechungen wie Knoten-Drains und einige Cluster-Wartungsvorgänge. Es verhindert nicht jeden ungeplanten Ausfall, gibt aber Kubernetes und Automatisierungstools ein Mindestverfügbarkeitsziel vor, das respektiert werden muss.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 75%  # Stellen Sie sicher, dass mindestens 75% der Replikate immer verfügbar sind
  selector:
    matchLabels:
      app: my-web-deployment

Die Bedeutung der anfänglichen Verzögerung

Wenn Ihre Anwendung Zeit zum Aufwärmen benötigt, passen Sie initialDelaySeconds, periodSeconds und failureThreshold an, damit die Bereitschaft das tatsächliche Startverhalten widerspiegelt. Eine fehlschlagende Readiness-Probe hält den Pod aus den Service-Endpunkten heraus; eine fehlschlagende Liveness-Probe kann den Container neu starten und eine Crash-Schleife erzeugen.

Sicher ausrollen

Das Erreichen von echten Rolling Updates mit Null-Ausfallzeit in Kubernetes ist eine Kombination aus robuster Plattformkonfiguration und disziplinierter Anwendungsentwicklung. Durch die korrekte Nutzung von Readiness-Probes zur Signalisierung des Betriebszustands, die Optimierung der Bereitstellungsstrategie (maxUnavailable: 0) zur Aufrechterhaltung der Kapazität und die Implementierung von Graceful-Termination-Handlern können Sie sicherstellen, dass Anwendungsaktualisierungen zuverlässig durchgeführt werden, ohne den Dienst für Ihre Benutzer zu unterbrechen. Testen Sie Ihren Aktualisierungsprozess immer gründlich in einer Staging-Umgebung, um die Terminations-Grace-Periode und die Sondenlogik zu validieren.