Bei Kubernetes springen wir oft direkt zu YAML, Helm Charts und kubectl apply. Je mehr Zeit ich mit echten Systemen verbringe, desto klarer wird: Die Deployment-Strategie zählt genauso wie die Manifeste.
Rolling, Blue-Green und Canary sind nicht nur verschiedene Wörter für „Deploy ohne Downtime“. Sie sind verschiedene Wege, mit Risiko, Kosten und Unsicherheit umzugehen.
Was ein Deployment wirklich tut
Ein Kubernetes Deployment verwaltet ReplicaSets, sorgt dafür, dass die richtige Anzahl Pods läuft, und unterstützt deklarative Updates.
Mit strategy.type, maxUnavailable und maxSurge steuert man, wie aggressiv Kubernetes alte Pods durch neue ersetzt.
Kurz gesagt: Das Deployment-Objekt ist der Motor. Die Strategie ist die Art, wie man ihn fährt.
Die meisten Teams landen standardmäßig bei Rolling Updates — selbst wenn die Änderung ganz andere Risikomerkmale hat.
Rolling Deployments — der Standard
Mit RollingUpdate ersetzt Kubernetes schrittweise alte Pods durch neue und versucht, den Service verfügbar zu halten.
Das funktioniert gut bei kleinen, kompatiblen Änderungen, wenn Tests und Probes solide sind.
Zwei Fallstricke sehe ich wiederholt:
- Ein gemischter Zustand, in dem manche Clients die alte und manche die neue Version erreichen — Debugging wird schwerer.
- Jede rückwärtsinkompatible Änderung (DB-Schema, Verträge, Annahmen) kann alte oder neue Pods brechen, solange beide live sind.
Für viele Alltags-Releases ist Rolling weiterhin meine Standardwahl — aber nur, wenn Änderungen kompatibel gehalten werden und maxUnavailable sowie maxSurge für kritische Services konservativ sind.
Blue-Green — zwei Produktionswelten
Blue-Green heißt: zwei Produktionsumgebungen parallel. Blue ist live, Green bekommt die neue Version.
Man deployt, testet und verifiziert auf Green. Wenn man überzeugt ist, schaltet man den Traffic um. Geht etwas schief, schaltet man in Sekunden zurück auf Blue.
Das passt, wenn:
- große, riskante Releases anstehen
- oder wenige Kernservices absolut nicht ausfallen dürfen.
Der Kompromiss ist offensichtlich: höhere Infrastrukturkosten und mehr Komplexität rund um Zustand und Datenbanken.
Deshalb sehe ich Blue-Green eher für Änderungen mit wirklich hoher Wirkung — nicht für jedes kleine Feature.
Canary — zuerst wenig Traffic
Canary Deployments leiten zunächst nur einen kleinen Anteil des Traffics (oder ein bestimmtes Segment) auf die neue Version.
Mit einem kleinen Anteil auf dem Canary beginnen, Fehlerrate und Latenz beobachten, schrittweise erhöhen — oder Rollback, wenn es schiefgeht. Bild bei Bedarf horizontal scrollen.
Man startet mit 1–5 %, beobachtet Metriken und Fehlerraten und erhöht schrittweise, wenn es gut aussieht.
Das lohnt sich, wenn:
- häufig deployt wird
- gute Observability da ist (Metriken, Logs, Traces, SLOs)
- und klare Schwellen für „passt“ versus „jetzt zurückrollen“ definiert sind.
Der Nachteil: Canary ist nicht „nur eine Deployment Spec“. Meist braucht man ein Service Mesh oder smartes Ingress plus solides Monitoring und Automatisierung, um wirklich davon zu profitieren.
Eine einfache Entscheidungshilfe
So denke ich im Moment ungefähr darüber nach:
| Situation | Risiko | Infra-Budget | Strategie meiner Wahl |
|---|---|---|---|
| Kleine, gut getestete Änderung, knappes Budget | medium | low | Rolling |
| Großer, riskanter Release auf einem kritischen Service | high | high | Blue-Green |
| Häufige Releases bei großer Nutzerbasis und guten Metriken | high | medium | Canary |
Das ist keine perfekte Regel. Aber sie erzwingt eine bewusste Entscheidung statt „wir machen immer Rolling“.
Die Pilotenperspektive
Vom Fliegen habe ich gelernt: nicht dieselbe Checkliste für jede Flugphase. Start, Reiseflug und Landung haben verschiedene Verfahren und Risikoprofile.
Deployment-Strategien sind ähnlich: Rolling, Blue-Green und Canary sind verschiedene Checklisten für verschiedene Arten von Änderungen.
Für mich ist die wichtigste Verschiebung: die Wahl der Strategie als bewusste Entscheidung behandeln, nicht als nachträglichen Gedanken im YAML. Wenn zuerst über Risiko gesprochen und dann die Strategie gewählt wird, werden Produktions-Incidents deutlich weniger aufregend.
