Rollout-Strategien: rollierend, Blue-Green und Canary

Worum es geht

Rollierend (rolling): Die Kubernetes-Dokumentation zu Deployments beschreibt die Standardstrategie so, dass neue Pods erzeugt und alte gelöscht werden, wobei maxUnavailable und maxSurge (je 25 Prozent als Vorgabe) die Untergrenze verfügbarer und die Obergrenze zusätzlicher Pods festlegen; alte Pods werden erst beendet, wenn genug neue laufen. progressDeadlineSeconds markiert einen Rollout, der nicht vorankommt, und kubectl rollout undo kehrt zur vorigen Revision zurück. Während des Vorgangs bedienen beide Versionen Anfragen.

Blue-Green: Zwei vollständige Umgebungen existieren; der Verkehr wechselt in einem Schritt. Argo Rollouts setzt das mit einem aktiven und einem optionalen Vorschau-Service um: Sobald das neue ReplicaSet verfügbar ist, zeigt der Controller den aktiven Service darauf und skaliert das alte nach scaleDownDelaySeconds herunter – solange es läuft, ist die Rückschaltung ein erneutes Umzeigen.

Canary: Die neue Version erhält einen kleinen Prozentsatz des Produktionsverkehrs. Bei Argo Rollouts ist das eine Liste von Schritten aus setWeight (Anteil) und pause (Wartezeit oder manuelle Freigabe), wahlweise durch eine automatische Analyse von Metriken abgesichert. Ohne Traffic-Router nähert der Controller den Anteil über die Replikazahlen an – bei zehn Replikas und zehn Prozent ist das ein neuer und neun alte Pods.

Warum es wichtig ist

Die drei Strategien tauschen Kapazität gegen Risiko. Rollierend braucht kaum Reserve, zwingt die Anwendung aber minutenlang zur Verträglichkeit gemischter Versionen. Blue-Green braucht kurzzeitig die doppelte Kapazität und liefert dafür einen sofortigen Wechsel und eine sofortige Rückschaltung. Canary begrenzt, wie viele Nutzerinnen einen Fehler sehen, setzt aber eine Verkehrsaufteilung und ein Messsignal voraus, das im Beobachtungsfenster gut von schlecht unterscheidet.

So wird es angewendet

• Grundlagen zuerst: Bereitschaftsprüfungen, die vor dem Ende der Initialisierung fehlschlagen; sauberes Beenden bei SIGTERM; Datenbankänderungen nach Expand-Contract, damit alt und neu nebeneinander laufen.
• Rollierend für zustandslose Dienste mit verträglichen Versionen; maxUnavailable: 0, wenn die Kapazität nicht sinken darf.
• Blue-Green, wenn ein Versionsmix ausgeschlossen ist (langlebige Verbindungen, inkompatible Caches) oder eine Generalprobe gegen echte Infrastruktur gewünscht ist.
• Canary, wenn ein Fehler erst unter echtem Verkehr sichtbar wird und ein messbares Signal existiert; die Abbruchschwelle vor dem Start festlegen.
• Feature-Schalter zusätzlich: Die Rollout-Strategie entscheidet, welches Binary läuft, der Schalter, welches Verhalten aktiv ist.

Stolpersteine

Session-Stickiness, Client-Caches und DNS-Laufzeiten machen «auf einmal umschalten» langsamer als geplant. Ein Canary mit wenigen Prozent Verkehr sieht seltene Fehler selten; das Fenster muss lang genug sein. Datenbankmigrationen rollen nicht mit dem Binary zurück. Auf einem einzelnen Host ohne Orchestrator sind alle drei nur mit Hilfsmitteln nachbildbar – dazu gibt es im Wiki eine offene Frage.

Was Blue-Green nicht trennt

Der Wechsel des Service-Zeigers trennt nur die Prozesse. Datenbank, Caches, Warteschlangen und die Clients sind beiden Umgebungen gemeinsam: Während scaleDownDelaySeconds (bei Argo Rollouts 30 Sekunden Vorgabe) bearbeitet Blau noch laufende Anfragen, während Grün bereits schreibt, und Browser sowie mobile Apps halten die alte Oberfläche noch lange über den Wechsel hinaus. Blue-Green schliesst den Versionsmix also nicht aus, sondern verschiebt ihn von den Serverprozessen in die Datenschicht und zu den Clients. Expand-Contract für Schemaänderungen und abwärtskompatible API-Antworten bleiben bei allen drei Strategien Pflicht; Blue-Green lohnt sich, wenn der Prozesszustand selbst keinen Mix verträgt – langlebige Verbindungen, In-Memory-Caches mit geändertem Format, ein Protokollwechsel zwischen Komponenten, die nur zusammen ausgeliefert werden. Die sofortige Rückschaltung gilt nur, solange das alte ReplicaSet läuft; danach ist die Rückkehr ein gewöhnlicher Rollout.