Begriff

Rolling Update

Kubernetes Deployment S1

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher (Old School): Server stoppen (Downtime). Neue Version kopieren. Server starten. Ergebnis: 5 Minuten "Wartungsarbeiten"-Seite. Heute (Kubernetes): Du hast 3 Kopien (Replicas) deiner App. Du willst Version 1 durch Version 2 ersetzen. Kubernetes ersetzt einen Pod nach dem anderen.

Starte v2 (Pod #1). Warte, bis er bereit ist.
Beende v1 (Pod #1).
Starte v2 (Pod #2)... Der User merkt nichts, weil immer mindestens 2 Pods antworten. Das ist Zero Downtime Deployment.

Merksatz: Eine Deployment-Strategie, bei der Instanzen einer alten Version schrittweise durch eine neue Version ersetzt werden, um die Verfügbarkeit der Anwendung während des Updates aufrechtzuerhalten.

Ist der Standard in K8s Deployments.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1       # Darf 1 mehr starten als gewünscht (4 Pods total).
    maxUnavailable: 0 # Darf NIEMALS unter 3 Pods fallen.

Wenn du hier maxUnavailable: 1 setzt, könnte es sein, dass kurzzeitig nur 2 Pods da sind (schneller, aber weniger Kapazität).

1. Readiness Probe ist Pflicht!

Das wichtigste Detail: Woher weiß K8s, dass der neue v2 Pod "bereit" ist? Ohne Readiness Probe denkt K8s: "Prozess läuft -> Bereit." Wenn deine App aber 30 Sekunden zum Booten (Spring Boot) braucht, schickt K8s Traffic an den startenden Pod -> Fehler 502. Mit Probe: K8s wartet, bis /health 200 OK gibt, bevor es den alten v1 Pod tötet. Ohne Probes ist Rolling Update kaputt.

2. Connection Draining (SIGTERM)

Wenn der alte v1 Pod sterben soll, kriegt er ein SIGTERM Signal. Er muss:

Aufhören, neue Requests anzunehmen.
Laufende Requests fertig bearbeiten (Graceful Shutdown).
Sich beenden. Wenn er das ignoriert (Hard Kill SIGKILL nach 30s), werden User-Downloads abgebrochen. Einstellung: terminationGracePeriodSeconds: 60.

3. Inkompatible APIs

Während des Updates laufen v1 und v2 gleichzeitig (für ein paar Minuten). Frontend-Code (im Browser des Users) könnte v1 sein, aber Backend ist schon v2. Die API muss also kompatibel sein. Wenn du den Endpoint /login änderst, werden 50% der User Fehler bekommen, solange der Rolling Update läuft.

1. Ingress Connection Draining & IP Tables

Wenn K8s einen Pod beendet (SIGTERM), löscht es sofort die IP des Pods aus den iptables/IPVS Hash-Ringen des Kube-Proxys (Endpoint Slice Sync). Warum ist das kritisch? Nginx / Ingress schickt sofort neuen Traffic an die verbleibenden Pods. Aber was ist mit dem User, der gerade ein 500MB Video vom "sterbenden" Pod streamt? Der Pod erhält zwar keine neuen Requests mehr, aber sein TCP-Thread hat die bestehenden Sockets noch offen. Das preStop-Hook-Skript (sleep 15) bremst das tödliche SIGKILL von K8s ab. Der Pod bedient die Video-TCP-Session geduldig bis zum Download-Ende, K8s sendet ihn erst danach in den Äther. Fehlt diese Orchestrierung, hagelt es in den Logs beim Update 502/Connection-Reset Drops en masse.

2. Knots und Unavailability Mathematics

K8s Deployments sind mathematisch starr bei Surge-Werten. Angenommen, du hast Replicas = 2, maxUnavailable = 0%, maxSurge = 1. Rolling Update startet:

Surge greift: K8s kreiert Pod 3 (v2). Es laufen jetzt 3 Pods (2x alt, 1x neu).
Limit Evaluierung: Sind 3 Pods da? Ja. Darf ich alt löschen, sodass 2 übrig bleiben? Ja (maxUnavailbile ist 0, also minimum 2 erforderlich).
Kill: K8s tötet Pod 1 (v1). Es laufen 2 Pods (1 alt, 1 neu).
K8s kreiert Pod 4 (v2) -> Tötet letztes v1. Bei maxUnavailable = 1 würde K8s sofort Pod 1 abschießen und die Last der gesamten App läge sekundenlang auf einem einzigen Pod, während der neue bootet. Bei CPU-Latenz-sensiblen Workloads ist Surge besser als Unavailable.

3. Das Schema-Lock Problem

Ein Rolling Update dauert Zeit. Hast du 100 Pods, dauert es vielleicht 10 Minuten. In Minute 5 hast du exakt 50 alte Pods und 50 neue Pods. Die Gefahr: Schema Locks auf der Datenbank. Dein "Init-Container" am allerersten v2-Pod feuert eine DDL-Migration ("ALTER TABLE xyz ADD COLUMN"). Postgres reagiert und setzt ein exklusives Access-Exclusive-Lock. Während Postgres 3 Minuten lang den Full-Table-Scan für die Migration blockiert, rennen 50 alte v1 Pods gegen eine verschlossene Tabelle an. Das gesamte Legacy-System crasht synchron in Deadlock-Timeouts, während das Rolling Update gemütlich weiterläuft. Moderne Teams wenden deshalb Non-Locking Indizes (Postgres CREATE INDEX CONCURRENTLY) und Backward-Compatible Schema-Design zur Vermeidung von Race-Conditions an.

Quick-Check

Recreate Strategy?
Das Gegenteil. "Töte alle Alten. Dann starte alle Neuen." Vorteil: Kein Mischbetrieb (nie v1 und v2 gleichzeitig). Nachteil: Downtime. Gut für Worker, schlecht für Webseiten.
Was ist "Surge"?
Der "Überschuss". Wenn du 100 Pods hast und maxSurge: 10%, startet K8s 10 neue Pods gleichzeitig. Das Update geht schneller, braucht aber kurzzeitig 110% Ressourcen im Cluster. Hast du genug RAM?
Rollback beim Rolling Update?
Wenn der neue Pod crasht (CrashLoopBackOff), stoppt K8s das Rolling Update automatisch ("Stuck"). Es killt keine weiteren alten Pods. Du hast dann 3x v1 und 1x kaputte v2. Das System bleibt online.