kubectl rollout status meldet «successfully rolled out» — aber was beweist das? Nur, dass die neuen Pods die Readiness-Probe bestanden haben. Die Probe prüft «der Prozess läuft», nicht «der Service funktioniert»: eine Regression, die die Error Rate von 0,1 % auf 2 % hebt, sieht ein Standard-RollingUpdate nicht — er tauscht die Pods bis zum Ende aus und meldet Erfolg. Der Incident beginnt später, wenn 100 % des Traffics bereits auf der neuen Version liegen. Progressive Delivery dreht das Modell um: ein Release ist eine Hypothese — «die neue Version ist nicht schlechter als die alte» —, der Traffic kommt in Portionen, Metriken prüfen die Hypothese, und ein Fehlschlag rollt das Release ohne menschliches Zutun zurück. Im CNCF-Stack übernimmt diese Schicht Argo Rollouts.
Rollout statt Deployment
Argo Rollouts besteht aus einem Controller (einmal pro Cluster installiert) und der CRD Rollout: ein Ersatz für das Deployment mit demselben Pod-Template plus dem Feld strategy — blueGreen oder canary. Im GitOps-Zyklus bricht nichts: CI baut das Image und hebt den Tag im GitOps-Repository an, ArgoCD synct die Manifeste, Rollouts entscheidet, wie die neue Version Traffic bekommt. Die Trennung der Verantwortung bleibt sauber: GitOps beantwortet «was deployen wir», Progressive Delivery beantwortet «wie schnell und mit welchem Sicherheitsnetz».
Blue-Green: sofortiges Rollback zum doppelten Preis
Die Strategie blueGreen hält zwei vollständige Versionen gleichzeitig: activeService leitet den Produktions-Traffic auf die Stable-Pods, previewService auf die neuen. Mit autoPromotionEnabled: false wird die Promotion zum manuellen Gate: die neue Version lässt sich über die Preview-Adresse mit Smoke-Tests prüfen, während der Produktions-Traffic sie nie sieht. Promotion ist ein Service-Umschalter; Rollback ist derselbe Umschalter in Gegenrichtung — Sekunden in beide Richtungen. Der Preis: doppelte Infrastruktur für die Dauer des Release und Vorsicht bei Datenbank-Migrationen — beide Versionen schauen auf dasselbe Schema.
Canary: Traffic in Stufen, Urteil per PromQL
Die Strategie canary beschreibt das Release als Folge von Schritten: setWeight: 20 → Pause → 50 → 80 → volle Promotion. Entscheidend ist nicht die Pause, sondern die Analyse: der Block analysis hängt ein AnalysisTemplate an — PromQL-Queries mit Schwellwerten, die der Controller ab dem angegebenen Schritt bei jedem Schritt ausführt. Eine gescheiterte Analyse ist ein automatischer Abort: das Canary-Gewicht wird entfernt, der gesamte Traffic kehrt zu Stable zurück, das Objekt wird als Degraded markiert. Niemand weckt den On-Call für die Entscheidung «zurückrollen oder nicht» — das Rollback ist bereits passiert.
Die Qualität des Gates entscheiden die Metriken. Die Success Rate zählt nur 5xx: 4xx sind Client-Fehler, und sie mitzuzählen heißt, Releases wegen fremder Bugs zurückzurollen. Die Latenz wird am P99 verglichen, nicht am Durchschnitt: P50 versteckt den Tail, und die Nutzer beschweren sich genau über den Tail. Beide Queries existieren im Cluster meist schon — es sind dieselben SLIs, die die SLO-Alerts speisen.
Burn Rate: das SLO als Sicherung für Deployments
Die Kopplung ans SLO hebt das Gate auf die nächste Stufe: die Analyse beobachtet nicht die rohe Error Rate, sondern die Geschwindigkeit, mit der das Error Budget verbrennt. Bei einem SLO von 99,9 % beträgt das monatliche Error Budget 43 Minuten; eine Burn Rate von 10× frisst es in drei Tagen. Daher die Regel «bei 10× — Deployments stoppen»: eine einzige PromQL-Bedingung api:burn_rate:ratio_rate1h > 10 im AnalysisTemplate macht aus dem SLO eine automatische Sicherung statt einer Reporting-Metrik. Ein schlechtes Release brennt das Budget nicht auf null, und ein gesundes wird nicht aus Übervorsicht blockiert: solange das Budget intakt ist, ist ein kleiner Fehleranstieg ein Ticket, kein Rollback.
Strategiewahl und drei Fallen
Die Wahl ist pragmatisch. Blue-Green — wenn Releases selten sind, die Observability bescheiden ist und sofortiges Rollback kritisch; bezahlt wird mit doppelter Infrastruktur. Canary — wenn Releases häufig sind und die Metriken reif: günstiger, gradueller, freundlicher zu Datenbank-Migrationen. Ein bewährtes Promotion-Muster über die Umgebungen: Dev — Blue-Green mit manueller Promotion, Staging und Prod — Canary mit automatischer.
Die Fallen der ersten Einführungen. Erstens: der HPA muss das Rollout targeten (scaleTargetRef mit kind: Rollout), nicht das Deployment — sonst streiten Autoscaling und Rollout um die Replicas. Zweitens: bei der Installation über Kustomize plus Helm zeigt ArgoCD die CRDs ewig als OutOfSync — der API-Server mutiert das Schema nach dem Apply; die Kur ist ignoreDifferences auf .spec, .status und den Annotations. Drittens: während eines Canary leben Secrets in zwei Versionen — Canary-Pods sehen die neue, Stable-Pods die alte, und ein Rollback bringt die alte zurück; die Secret-Rotation muss das in der Checkliste berücksichtigen, statt es während eines Incidents zu entdecken.
Progressive Delivery ist kein Luxus für Plattformen im Google-Maßstab. Ein Controller, eine CRD und ein AnalysisTemplate mit zwei PromQL-Queries — und das Release hört auf, ein Sprung ins Ungewisse zu sein: die Metriken, die Sie ohnehin für Alerts sammeln, schützen jedes Release, bevor es zum Incident wird.