Blau-Grün und Kanarische Deploy

Blau-Grün und Canary deploy

1) Aufgabe und Schlüsselideen

• Blau-Grün: Wir halten zwei parallele Versionen (Blau ist aktiv, Grün ist neu), schalten den Verkehr atomar. Ein schneller Rollback → Blue sofort zurück.
• Canary: Schalten Sie die neue Version schrittweise ein (1% → 5% → 25% → 50% → 100%), überwachen Sie die SLO-Metriken und stoppen/rollen Sie zurück, wenn Sie abgebaut werden.

Das allgemeine Prinzip: „Artefakt-Lieferung“ von „Traffic-Inclusion“ trennen und Beobachtbarkeit + Rollbacks automatisieren.

2) Wann was zu wählen

• Sie benötigen sofortiges Umschalten (starre RTOs), einfache State-less-Dienste;
• es gibt strenge Release/Freeze-Fenster und verständliche Smoke-Checks;
• es ist teuer, eine lange doppelte Kapazität zu halten - aber Sie können es für kurze Zeit.

• komplexe Änderungen, schrittweise Validierung im realen Verkehr erforderlich;
• es gibt eine ausgereifte Telemetrie (SLO, Geschäftsmetriken), die Möglichkeit eines Auto-Stop;
• kritische Begrenzung des Schadensradius (Fintech/iGaming-Streams).

Combo-Muster: Rollen Sie Green aus und schalten Sie über Canary-Stufen darauf um (Blue-Green als Rahmen, Canary als Methode zur Verkehrsverlagerung).

3) Verkehrslenkungsarchitektur

1. L4/L7-Balancer (ALB/NLB, Cloud Load Balancer) sind gewichtete Zielgruppen.

2. API-Gateway/WAF - Route/Gewicht nach Version, Header, Cookie, Region.

3. Service Mesh (Istio/Linkerd/Consul) - Prozentuale Verteilung, Fehlerinjektion, Timeout/Retrave/Limits-Pens.

4. Ingress/NGINX/Envoy - Upstream-Gewichte und Routen nach Attributen.

5. Argo Rollouts/Flagger - Operator-Controller, automatische Progression, Integration mit Prometheus/New Relic/Datadog.

4) Kubernetes: praktische Vorlagen

4. 1 Blau-Grün (über Service Selector)

Два Deployment: `app-blue` и `app-green`.
Ein Service' app-svc' mit Selektor zur gewünschten 'version'.

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

Umschalten - Atomwechsel eines Selektors (oder Labels) mit kontrolliertem Drain.

4. 2 Canary (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

Ändern Sie das „Gewicht“ auf den Stufen; retry, timeout, outlier-detector auf DestinationRule hinzufügen.

4. 3 Argo Rollouts (Auto-Kanarienlauf)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

Die Musteranalyse ist mit Metriken verknüpft (siehe unten).

5) SLO-Gates und Auto-Rollback

• Technische Daten: „p95 _ latency“, „5xx _ rate“, „error _ budget _ burn“, „CPU/Memory throttling“.
• Lebensmittelgeschäft: „CR (Kaution)“, „Erfolg der Zahlungen“, „Scoring-Betrug“, „ARPPU“ (an kalten Fenstern).

• Wenn '5xx _ rate' die neue Version> 0 ist. 5% innerhalb von 10 min - Pause und Rollback.
• Wenn „p95 _ latency“ ↑> 20% der Basis - rollback.
• Wenn die Förderung der Kanarienvögel geht, aber die SLO des Budgets ist verbrannt> 2 %/Stunde - halten.

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6) Daten und Kompatibilität (häufigste Schmerzursache)

• Expand: Fügen Sie neue nullable Spalten/Indizes hinzu, unterstützen Sie beide Schemata.
• Migrate: Doppeltes Schreiben/Lesen, Backfill.
• Vertrag: Entfernen Sie alte Felder/Code, nachdem Sie 100% des Datenverkehrs freigegeben haben.
• Event/Warteschlangen: Versionieren Sie payload (v1/v2), unterstützen Sie idempotency.
• Cache/Sitzungen: Schlüssel versionieren; Stellen Sie die Formatkompatibilität sicher.

7) Integration mit CI/CD und GitOps

CI: Zusammenbau eines einzelnen Artefakts (build once), Bildsignatur, SBOM, Tests.
CD: Förderung von Artefakten durch Umgebungen; Blue-Green/Canary werden durch Manifeste geführt.
GitOps: merge MR → Controller (Argo CD/Flux) wendet Gewichte/Selektoren an.
Environments/Approvals: für Prod Steps - Manual Gate + Solutions Audit.

8) NGINX/Envoy und Cloud LB: schnelle Beispiele

8. 1 NGINX (Upstream-Gewichte)

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8. 2 AWS ALB (Weighted Target Groups)

TG-Blue: 90, TG-Green: 10 → Gewichtswechsel durch IaC/CLI.
Binden Sie die CloudWatch-Warnmeldungen an Rollback-Auto-Skripte (Gewichtsänderung auf 0/100).

9) Sicherheit und Compliance

Zero Trust zwischen den Versionen: Unterscheiden Sie zwischen Geheimnissen/rollenden Verschlüsselungsschlüsseln.
Policy-as-Code: Verbot des Deploys von unsignierten Bildern, „no latest“.
Geheimnisse und Configs als Versionsartefakte; Rollback aktiviert das Rollback von Config.
Audit: Wer, wann das Gewicht angehoben/den Selektor gewechselt hat, mit welchem Ticket.

10) Kosten und Kapazität

Blue-Green benötigt für den Release-Zeitraum doppelte Leistung → Planen Sie ein Fenster.
Canary kann länger dauern → Telemetrie-/Überwachungskosten, paralleler Inhalt der beiden Versionen.
Optimierung: Autoscaling über HPA/VPA, kurze Blue-Green-Fenster, Late-Night-Releases für „schwere“ Dienste.

11) Rollbacks (Runbook)

1. Fortschritt einfrieren (Pause).
2. Reduzieren Sie das Gewicht von Green auf 0% (Canary )/setzen Sie den Selektor wieder auf Blue (Blue-Green).
3. Check: Fehler/Latenz wieder auf Basis, Drainage-Verbindungen.
4. Öffnen Sie den Vorfall, sammeln Sie Artefakte (Protokolle, Spuren, Vergleich von Metriken).
5. Fix/Reprod auf der Bühne, Rauch vertreiben, Progression neu starten.

12) Anti-Muster

Neuzusammenstellung eines Artefakts zwischen stage und prod (Verstoß gegen „build once“).
Canary „taub“ ohne SLO/Metriken ist eine Formalität, keine Verteidigung.
Mangel an Fitch-Flags: Die Veröffentlichung ist gezwungen, das Verhalten sofort zu 100% zu aktivieren.
Nicht funktionierende Health-Checks/Liveness → „festgefahrene“ Herde und falsche Stabilität.
OBD-Kompatibilität „nach Möglichkeit“: Vertrag bricht beim Wechsel zusammen.
Mutierbare Image-Tags/' latest 'im Produkt.

13) Checkliste Umsetzung (0-45 Tage)

0-10 Tage

Wählen Sie eine Strategie für Dienstleistungen: B/G, Canary oder kombiniert.
Aktivieren Sie das Signieren von Bildern, Health-Checks, Readiness-Tests, 'no latest'.
Bereiten Sie SLO-Dashboards (Latenz/Fehlerrate/Geschäftsmetriken) vor.

11-25 Tage

Automatisieren Sie Gewichte (Istio/Argo Rollouts/ALB-Gewichte).
Konfigurieren Sie analysis templates, alerts und auto-rollback.
Pattern Manifeste (Helm/Kustomize), integrieren mit GitOps.

26-45 Tage

Implementieren Sie eine Expand-Migrate-Contract-Strategie für die DB.
Decken Sie kritische Kill-Switch-Flows mit Flags ab.
Halten Sie einen „Spieltag“: Simulieren Sie einen Rollback und einen Vorfall.

14) Reifegradkennzahlen

% der Freigaben über Blue-Green/Canary (Ziel> 90%).
Mittlere Schalt-/Rollback-Zeit (Ziel <3 min).
Anteil der Releases mit Auto-Stop nach SLO (und ohne Zwischenfälle).
Telemetrie-Service-Abdeckung (traces/logs/metrics)> 95%.
Anteil der DB-Migrationen nach dem Expand-Migrate-Contract-Schema> 90%.

15) Anwendungen: Richtlinien- und Pipelinevorlagen

OPA (Verbot unsignierter Bilder)

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

Helm-Werte für Canary (vereinfacht)

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

GitHub-Aktionen - Gewichtsförderung (Pseudo)

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16) Schlussfolgerung

Blue-Green und Canary schließen sich nicht gegenseitig aus, sondern sind komplementäre Strategien. Bauen Sie sie über signierte Artefakte, SLO-Beobachtbarkeit, automatische Gates und GitOps-Steuerung auf. Trennen Sie die Lieferung vom Einschalten, halten Sie einen schnellen Rollback und die Disziplin der Migrationen aufrecht - und Releases werden vorhersehbar, sicher und schnell.