Rolling-, Blue-Green- und Canary-Deployments im Vergleich

Worum es geht

Rolling Update: Die Kubernetes-Deployment-Dokumentation (zitiert) beschreibt die Standardstrategie als das Erstellen neuer Pods und Löschen alter Pods innerhalb zweier Grenzen, maxUnavailable und maxSurge (standardmässig beide 25 Prozent); alte Pods werden erst beendet, wenn eine ausreichende Anzahl neuer Pods hochgefahren ist, und progressDeadlineSeconds markiert ein Rollout, das ins Stocken gerät. Während des Rollouts bedienen beide Versionen Verkehr.

Blue-Green: Zwei vollständige Stacks bestehen nebeneinander; der Verkehr wird in einem einzigen Schritt vom aktiven auf den neuen umgeschaltet. Die Argo-Rollouts-Dokumentation (zitiert) setzt dies um, indem ein aktiver Service und ein optionaler Preview-Service auf unterschiedliche ReplicaSets zeigen und, sobald das neue ReplicaSet verfügbar ist, der aktive Service so geändert wird, dass er darauf zeigt; danach wird das alte Set nach einer Verzögerung heruntergefahren.

Canary: Die neue Version erhält einen kleinen Prozentsatz des Produktionsverkehrs, der in Schritten erhöht wird. Argos Canary-Strategie (zitiert) drückt dies als Liste von setWeight- und pause-Schritten aus, wahlweise abgesichert durch automatisierte Analyse von Metriken.

Warum es wichtig ist

Die Strategien tauschen Kapazität gegen Risiko. Rolling braucht wenig zusätzliche Kapazität, zwingt die Anwendung aber, gemischte Versionen für Minuten zu vertragen; Blue-Green braucht kurzzeitig die doppelte Kapazität, bietet dafür eine sofortige Umschaltung und ein sofortiges Rollback, solange der alte Stack noch läuft; Canary begrenzt die Anzahl der Nutzenden, die einem Fehler ausgesetzt sind, braucht aber Traffic-Splitting und eine Metrik, die innerhalb des Beobachtungsfensters zuverlässig zwischen gut und schlecht unterscheidet.

So wird es angewendet

• Zunächst jede Strategie überhaupt ermöglichen: Readiness-Checks, die fehlschlagen, bevor der Prozess bereit ist, ein geordnetes Herunterfahren bei SIGTERM, sowie abwärtskompatible Datenbankänderungen und API-Antworten, damit alte und neue Version nebeneinander bestehen können.
• Rolling für zustandslose Dienste mit kompatiblen Versionen verwenden; maxUnavailable: 0 setzen, wenn die Kapazität nicht einbrechen darf.
• Blue-Green verwenden, wenn eine Vermischung von Versionen nicht akzeptabel ist (langlebige Verbindungen, inkompatible Caches) oder wenn vor der Umschaltung eine Generalprobe gegen die echte Infrastruktur gewünscht ist.
• Canary verwenden, wenn sich ein Fehler nur unter echtem Verkehr zeigen würde und ein messbares Signal (Fehlerrate, Latenz, Geschäftskennzahl) existiert; die Abbruchschwelle vor dem Start festlegen.
• Mit Feature-Toggles kombinieren: Eine Deployment-Strategie steuert, welches Binary läuft, ein Toggle steuert, welches Verhalten aktiv ist.

Stolpersteine

Session-Stickiness, Client-Caches und DNS-TTLs machen das «Verkehr auf einmal umschalten» langsamer als erwartet. Ein Canary, der nur einen kleinen Anteil des Verkehrs erhält, sieht seltene Fehler selten, daher muss sein Beobachtungsfenster lang genug sein, um aussagekräftig zu sein. Datenbankmigrationen werden nicht zusammen mit dem Binary zurückgerollt.

Blue-Green isoliert gemeinsam genutzten Zustand nicht

Blue und Green teilen sich die Datenbank, die Queue und jeden anderen Backing-Service; ab dem Moment, in dem der neue Stack startet (Health-Checks, Aufwärmen, Probeverkehr), lesen und schreiben also beide Versionen dieselben Daten, und nach der Umschaltung bleibt der alte Stack für das Rollback-Fenster verbunden. Die Vermischung von Versionen, die Blue-Green beseitigt, betrifft also nur die prozesslokale Art: Caches im Arbeitsspeicher, klebende Sessions, langlebige Verbindungen, inkompatible Formate auf der Festplatte innerhalb der Instanz. Schema- und Nachrichtenformat-Änderungen brauchen dieselbe Expand-and-Contract-Disziplin wie ein Rolling Update, und das sofortige Rollback gilt nur so lange, bis die neue Version etwas geschrieben hat, das die alte nicht lesen kann. Blue-Green für prozesslokale Inkompatibilitäten oder für eine Generalprobe gegen die echte Infrastruktur wählen; nicht wählen, um abwärtskompatible Datenänderungen zu umgehen.