Albastru-verde și Canare implementa

Albastru-Verde și Canare implementa

1) Provocare și idei cheie

• Albastru-verde: păstrați două versiuni paralele (albastru - activ, verde - nou), comutați traficul atomic. Un rollback rapid → întoarce instantaneu albastru.
• Canare: activați noua versiune în etape (1% 5% 25% 50% 100%), monitorizați metricile SLO și opriți/rostogoliți înapoi în timpul degradării.

Principiul general este de a separa „livrarea artefactelor” de „incluziunea traficului” și de a automatiza observabilitatea + rollback-urile.

2) Când să alegeți

• au nevoie de comutare instantanee (hard RTO), servicii simple fără stat;
• există ferestre stricte de eliberare/congelare și verificări clare ale fumului;
• este scump să dețină o capacitate dublă lungă - dar este posibil pentru o perioadă scurtă de timp.

• modificări complexe, este necesară validarea pas cu pas a traficului real;
• există telemetrie matură (SLO, metrici de afaceri), capacitate de oprire automată;
• limitează critic raza de deteriorare (fluxuri fintech/iGaming).

Model combo: roll out Green și treceți la ea prin canare-etape (albastru-verde ca un cadru, Canare ca o metodă de transport al traficului).

3) Arhitectura de rutare a traficului

1. L4/L7 balancer (ALB/NLB, Cloud Load Balancer) - grupuri țintă ponderate.

2. API gateway/WAF - traseu/greutate pe versiuni, antete, cookie-uri, regiuni.

3. Service Mesh (Istio/Linkerd/Consul) - distribuție procentuală, injecție defectuoasă, mânere timeout/retray/restricționare.

4. Ingress/NGINX/Envoy - greutăți în amonte și rutarea atributelor.

5. Argo Rollouts/Flagger - operator-controler, progresie automată, integrare cu Prometheus/New Relic/Datadog.

4) Kubernete: șabloane practice

4. 1 albastru-verde (prin selectorul de servicii)

Два Implementare: „app-blue” и „app-green”.
Un serviciu "app-svc' cu un selector pentru" versiunea "dorită.

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}]

Comutare - schimbarea atomică a selectorului (sau a etichetelor) cu scurgere controlată.

4. 2 Canare (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

Modificarea „greutății” cu pas; adăugați retry, timeout, outlier-detector la DestinationRule.

4. 3 Rulouri Argo (Auto Canary Run)

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"]

Analiza șablonului este asociată cu valorile (vezi mai jos).

5) Porți SLO și rollback automat

• Tehnic: 'p95 _ latency', '5xx _ rate', 'error _ budget _ burn',' CPU/Memory throttling '.
• Alimentar: „CR (depozit)”, „succesul plăților”, „fraudă de scoring”, „ARPPU” (pe ferestre reci).

• Dacă '5xx _ rate' a noii versiuni este> 0. 5% pentru 10 min - pauză și rollback.
• Dacă „p95 _ latency” ↑> 20% din baza - rollback.
• Dacă promovarea canar merge, dar bugetul SLO este ars> 2 %/oră - dețin.

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) Date și compatibilitate (cea mai frecventă cauză a durerii)

• Extindeți: adăugați noi coloane/indici nullable, sprijiniți ambele scheme.
• Migrare: Scriere dublă/Citire, Back-Fill.
• Contract: ștergeți câmpurile/codul vechi după ieșirea 100% din trafic.
• Eveniment/cozi: versiunea utilă (v1/v2), suport idempotency.
• Cache/sesiuni: chei versiune; Asigurați compatibilitatea formatului.

7) Integrarea cu CI/CD și GitOps

CI: construi o dată, semnătura imaginii, SBOM, teste.
CD: promovarea artefactelor prin medii; Albastru-Verde/Canare sunt guvernate de manifeste.
GitOps: MR → controller (Argo CD/Flux) aplică greutăți/selectori.
Medii/Aprobari: pentru etapele de productie - porti manuale + decizii de audit.

8) NGINX/Envoy și Cloud LBs: Exemple rapide

8. 1 NGINX (greutăți în amonte)

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 (Grupuri țintă ponderate)

TG-Blue: 90, TG-Green: 10 → schimba greutatea prin IaC/CLI.
Link CloudWatch alerte la scripturi auto rollback (schimbarea greutății la 0/100).

9) Siguranță și conformitate

Zero încredere între versiuni: distinge între secretele de criptare/tastele de rulare.
Policy-as-Code: respingeți implementarea imaginilor nesemnate, „nu există cele mai recente”.
Secrete și configurații ca artefacte de versiune; rollback include rollback de configurații.
Audit: cine, când a ridicat greutatea/a schimbat selectorul, cu ce bilet.

10) Cost și capacitate

Blue-Green necesită dublarea puterii pentru perioada de lansare → planificarea unei ferestre.
Canare poate dura mai mult → costul de telemetrie/supraveghere, conținut paralel de două versiuni.
Optimizare: autoscalare prin HPA/VPA, ferestre scurte Blue-Green, versiuni de noapte pentru servicii „grele”.

11) Runbooks

1. Întrerupeţi promovarea.
2. Reduceți greutatea verde la 0% (canar )/selector de întoarcere la albastru (albastru-verde).
3. Verificați: erorile/latența au revenit la conexiunile de bază, de scurgere.
4. Deschideți un incident, colectați artefacte (jurnale, piste, compararea metricii).
5. Fixați/reprimați în scenă, conduceți fumul, reporniți progresia.

12) Anti-modele

Reconstruirea unui artefact între etapă și prod (încălcarea „construi o dată”).
Canarul "surd' fără SLO/metrici este o formalitate, nu o apărare.
Lipsa steagurilor caracteristice: eliberarea este forțată să includă un comportament 100% simultan.
Controale de sănătate/viață nelucrătoare → funduri „lipicioase” și stabilitate falsă.
Compatibilitatea bazei de date „la întâmplare”: contractul se întrerupe la comutare.
Etichete imagine mutabile/„ cele mai recente ”în prod.

13) Lista de verificare a implementării (0-45 zile)

0-10 zile

Alege o strategie pentru servicii: B/G, Canare sau combinate.
Activați semnarea imaginilor, controalele de sănătate, probele de pregătire, „nici o ultimă”.
Pregătiți tablouri de bord SLO (latență/rata de eroare/metrici de afaceri).

11-25 zile

Greutăți automate (Istio/Argo Rollouts/ALB-greutăți).
Configurați șabloane de analiză, alerte și auto-rollback.
Manifestele de șablon (Helm/Kustomize), se integrează cu GitOps.

26-45 zile

Implementarea strategiei de extindere-migrare-contract pentru baza de date.
Acoperiți steaguri critice kill-switch.
Petreceți „ziua jocului”: simulați un rollback și un incident.

14) Valorile maturității

% din versiuni prin Blue-Green/Canare (țintă> 90%).
Timpul mediu de comutare/revenire (ţintă <3 min).
Cota de versiuni cu SLO auto-stop (și fără incidente).
Acoperirea serviciului prin telemetrie (urme/busteni/metrici)> 95%.
Ponderea migrațiilor DB în conformitate cu schema de extindere-migrare-contract este> 90%.

15) Atașamente: Politica și șabloane de conducte

OPA (respingeți imaginile nesemnate)

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-valori pentru canar (simplificat)

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

Acțiuni GitHub - promovarea greutății (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) Concluzie

Blue-Green și Canare nu se exclud reciproc, ci strategii complementare. Construiți-le pe artefacte semnate, observabilitate SLO, porți automate și control GitOps. Separați livrarea de incluziune, păstrați o disciplină rapidă de retragere și migrare - iar eliberările devin previzibile, sigure și rapide.