Diagramm der Deployment-Strategien: Rolling, Blue-Green und Canary

Die meisten Ausfälle beginnen mit einem Deployment. Der Code hat Review und Tests bestanden, und dann trifft er auf echten Traffic, echte Daten und echte Abhängigkeiten. Eine Deployment-Strategie entscheidet, wie viel deines Traffics gleichzeitig auf die neue Version trifft, wie schnell du ein Problem bemerkst und wie schnell du es rückgängig machen kannst.

Dieser Artikel vergleicht die drei Strategien, zwischen denen die meisten Teams wählen: Rolling Updates, Blue-Green und Canary Releases. Er zeigt, wie sich der Traffic jeweils verschiebt und wie ein Rollback aussieht, und endet mit einem Diagramm eines Canary Release, bei dem die Entscheidung über Weitermachen oder Zurückrollen automatisiert ist.

Rolling Update

Ersetz Instanzen der alten Version nach und nach durch die neue. Kubernetes-Deployments tun das standardmäßig: Bei der RollingUpdate-Strategie steuern maxSurge und maxUnavailable, wie viele zusätzliche und fehlende Pods während des Rollouts erlaubt sind; beide stehen standardmäßig auf 25 %.

• Traffic: Während des Rollouts bedienen beide Versionen gleichzeitig Anfragen, im Verhältnis ihrer Pod-Anzahl.
• Rollback: ein weiteres Rolling Update zurück zur alten Version. Minuten, nicht Sekunden.
• Kosten: fast nichts extra; höchstens die Surge-Kapazität.
• Risiko: Jeder Nutzer kann früh auf die neue Version treffen, und Readiness Probes sind das einzige automatische Gate. Eine Version, die sauber startet, aber unter Last versagt, wird vollständig ausgerollt.

Rolling Updates sind der richtige Standard für risikoarme Änderungen und interne Services mit guten Tests und Probes. Lass die Readiness Probe prüfen, was der Service zum Arbeiten braucht, nicht nur, ob der Prozess läuft. Sonst ersetzt der Rollout fröhlich gesunde Pods durch kaputte.

Blue-Green

Betreib zwei vollständige Umgebungen. Blue bedient die Produktion; Green bekommt die neue Version und wird vor Ort getestet. Dann schaltet der Load Balancer oder das DNS den gesamten Traffic auf einmal von Blue auf Green um. Martin Fowlers Beschreibung des Blue-Green Deployment ist die klassische Referenz.

• Traffic: erst alles auf Blue, dann alles auf Green. Nie beides, zumindest nicht lange.
• Rollback: zurück auf Blue schalten, das noch läuft. Sekunden.
• Kosten: doppelte Kapazität, solange beide laufen.
• Risiko: Die Umschaltung bewegt 100 % der Nutzer auf einmal, also trifft ein Problem, das erst unter echtem Traffic auftaucht, alle. Die Datenbank ist gemeinsam, also müssen Schemaänderungen mit beiden Versionen funktionieren.

Canary

Schick einen kleinen Anteil des echten Traffics, etwa 5 %, an die neue Version, vergleich sie mit der stabilen Version und erhöhe den Anteil schrittweise, wenn sie sich bewährt. Der Name kommt vom Kanarienvogel im Kohlebergwerk; siehe den Artikel zum Canary Release auf Fowlers Website.

• Traffic: aufgeteilt nach Gewicht, Header oder Nutzersegment.
• Rollback: Gewicht des Canary auf null setzen. Sekunden, und nur wenige Prozent der Nutzer waren betroffen.
• Kosten: ein paar zusätzliche Pods plus das Tooling für Traffic-Splitting und Analyse.
• Risiko: das niedrigste der drei, wenn du die richtigen Metriken beobachtest. Ein Canary, den niemand beobachtet, ist ein langsames Rolling Update.

Im Vergleich

Die letzte Zeile ist überall gleich, und das hat einen Grund: Bei jeder Strategie treffen irgendwann zwei Versionen des Codes auf dieselbe Datenbank. Nutze Expand-and-Contract-Migrationen: erst neue Spalten und Tabellen hinzufügen, dann Code ausrollen, der mit beiden Formen funktioniert, und die alte Form in einem späteren Release entfernen.

Shadow Traffic vor dem Canary

Manche Teams schalten dem Canary einen Schritt vor: Sie kopieren einen Teil der Produktionsanfragen an die neue Version und werfen deren Antworten weg. Envoy und Istio können Traffic so spiegeln. Das fängt Abstürze und Latenz-Regressionen ab, ganz ohne Auswirkung auf Nutzer, aber nur für Lesezugriffe und idempotente Anfragen. Gespiegelte Schreibzugriffe wiederholen ihre Nebenwirkungen wie E-Mails, Zahlungen und Bestandsänderungen. Halte sie aus dem Spiegel heraus oder lass den Shadow gegen Sandbox-Abhängigkeiten laufen.

Die Canary-Entscheidung automatisieren

Der Wert eines Canary liegt im Vergleich, und Menschen sind schlecht darin, eine Stunde lang Dashboards zu beobachten. Tools wie Argo Rollouts und Flagger automatisieren das auf Kubernetes: Sie verschieben Traffic schrittweise, fragen zwischen den Schritten deinen Metrik-Provider ab und befördern oder brechen ab, je nach den Schwellenwerten, die du festlegst.

Gute Analysemetriken sind wenige und nah am Nutzer:

• Fehlerrate (5xx-Antworten) des Canary im Vergleich zur stabilen Version.
• Latenz bei einem hohen Perzentil, etwa p99.
• Wenn möglich ein Geschäftssignal, etwa abgeschlossene Checkouts pro Minute.

Vergleich den Canary mit der stabilen Version, nicht mit einem festen Wert, damit eine schlechte Nacht einer Abhängigkeit nicht jedes Release scheitern lässt.

Das Architekturdiagramm

So liest du es:

• Oben, der Traffic-Pfad: Nutzer erreichen den Ingress, der 95 % der Anfragen an das stabile ReplicaSet und 5 % an den Canary schickt. Beide melden an die Metriken.
• Unten, der Regelkreis: CI übergibt das neue Image an den Rollout-Controller. Der Controller setzt die Ingress-Gewichte (gestrichelte Kante), liest Fehlerrate und p99-Latenz beider Versionen und entscheidet.
• Die Entscheidung: innerhalb der Schwellenwerte weiter zum nächsten Schritt; außerhalb Abbruch und aller Traffic zurück an v1.
• Der Markdown-Block listet die Schritte und die Abbruchregel auf, die in das Review der Rollout-Konfiguration jedes Service gehören.

Feature Flags sind die vierte Strategie

Eine Deployment-Strategie steuert, welche Server neuen Code ausführen. Ein Feature Flag steuert, welche Nutzer ein neues Verhalten sehen, unabhängig von Deployments. Teams, die oft ausliefern, kombinieren beides: per Rolling Update oder Canary deployen, riskante Features hinter einem Flag halten und das Flag schrittweise einschalten. Das Flag ist der schnellere Rollback, weil nichts neu ausgerollt werden muss.

Was in ein Deployment-Diagramm gehört

• Traffic-Prozente an den Kanten. Sie ändern sich während eines Rollouts; zeig den ersten Schritt.
• Wer die Gewichte ändert. Ein Controller, eine Pipeline oder ein Mensch.
• Die Abbruchkriterien. Zahlen, nicht „wenn es schlecht aussieht“.
• Die Datenbank, mit dem Hinweis, dass Schemaänderungen nach Expand-and-Contract laufen.

Das CI/CD-Pipeline-Diagramm zeigt die Build- und Teststufen davor, das Kubernetes-Architekturdiagramm behandelt den Cluster, und das Observability-Architekturdiagramm zeigt, woher die Metriken kommen.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge eine Person für die Nutzer hinzu und aus dem Kubernetes-Pack einen Ingress und zwei ReplicaSet-Nodes für Stable und Canary.
3. Füge aus dem DevOps-Pack Metriken und eine CI/CD-Pipeline hinzu sowie aus dem C4-Modell-Pack einen Container für den Rollout-Controller.
4. Füge aus dem Flussdiagramm-Pack eine Entscheidung, einen Prozess und einen Start / Ende-Node für Beförderung und Abbruch hinzu.
5. Beschrifte die Ingress-Kanten mit den Traffic-Gewichten, zeichne die Gewichtsänderungen als gestrichelte Kante und füge einen Markdown-Block aus dem Basis-Pack mit den Schritten hinzu.

Das Beispiel nutzt 11 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Welche Deployment-Strategie ist die beste? Das hängt von Risiko und Tooling ab. Rolling Updates passen zu den meisten risikoarmen Änderungen; Canaries zu nutzernahen Services, bei denen ein schlechtes Release teuer ist; Blue-Green zu Systemen, die sofortige, vollständige Umschaltungen brauchen und sich doppelte Kapazität leisten können.

Was ist der Unterschied zwischen Blue-Green und Canary? Blue-Green schaltet den gesamten Traffic auf einmal um und hält die alte Umgebung für einen sofortigen Rollback bereit. Ein Canary verschiebt zuerst einen kleinen Teil des Traffics und erweitert ihn erst, wenn sich die neue Version bewährt.

Wie gehe ich bei einem Deployment mit Datenbankmigrationen um? Mach jede Schemaänderung abwärtskompatibel: erst erweitern, dann Code ausrollen, der mit beiden Formen funktioniert, und in einem späteren Release zurückbauen.

Welche Metriken sollte eine Canary-Analyse nutzen? Fehlerrate und Latenz bei hohen Perzentilen im Vergleich zur stabilen Version, dazu eine Geschäftsmetrik, wenn du sie schnell messen kannst.

Sind Feature Flags eine Deployment-Strategie? Sie sind eine Release-Strategie. Sie entkoppeln das Einschalten eines Features vom Ausrollen des Codes und lassen sich gut mit jeder der drei Deployment-Strategien kombinieren.

Kostenlos starten — ein Seat, keine Kreditkarte.