Blue-Green და Canary Deple

Blue-Green და Canary Deple

1) ამოცანა და ძირითადი იდეები

• Blue-Green: ჩვენ ორი პარალელური ვერსია გვაქვს (ცისფერი - აქტიური, მწვანე - ახალი), გადართეთ ტრაფიკი ატომურად. სწრაფი გამოტოვება დაუყოვნებლივ დაბრუნდება Blue.
• Canary: ჩვენ ჩართავთ ახალ ვერსიას ეტაპობრივად (1%) 5% - 25% - 50% - 100%), ვაკვირდებით SLO მეტრებს და ვჩერდებით/ვტოვებთ დეგრადაციის დროს.

ზოგადი პრინციპი: „არტეფაქტის მიწოდება“ „ტრაფიკის ჩართვისგან“ და დაკვირვების + გამოტოვების ავტომატიზაცია.

2) არჩევნის გაკეთებისას

• თქვენ გჭირდებათ მყისიერი გადართვა (მყარი RTO), მარტივი სახელმწიფო სერვისები;
• არსებობს მკაცრი გამოშვების/გაყინვის ფანჯრები და გასაგები smoke შემოწმებები;
• ძვირია გრძელი ორმაგი კონტეინერის შენარჩუნება - მაგრამ მოკლედ შეგიძლიათ.

• რთული ცვლილებები, საჭიროა რეალურ ტრაფიკზე ეტაპობრივი მონიტორინგი;
• აქ არის სექსუალური ტელემეტრია (SLO, ბიზნეს მეტრიკა), მანქანის გაჩერების შესაძლებლობა;
• კრიტიკულად შეზღუდულია დამარცხების სხივი (fintech/iGaming Stream).

Combo aptern: the Green- ის გადატანა და მასზე გადასვლა კანარის საფეხურებზე (Blue-Green, როგორც ჩარჩო, კანარი, როგორც ტრეფიკის გადაცემის მეთოდი).

3) ტრეფიკის არქიტექტურა

1. L4/L7 დაბალანსება (ALB/NLB, Cloud Load Balancer) - შეჩერებული target groups.

2. API კარიბჭე/WAF - მარშრუტი/შაბათ ვერსიების, სათაურების, ქუქი-ფაილების, რეგიონების მიხედვით.

3. Service Mesh (Istio/Linkerd/Consul) - პროცენტული განაწილება, fault ინექცია, Taimauts/Retraev/შეზღუდვები.

4. Ingress/NGINX/Envoy - upstream წონა და მარშრუტიზაცია ატრიბუტით.

5. Argo Rollouts/Flagger - კონტროლერის ოპერატორი, ავტომატური პროგრესი, ინტეგრაცია Prometheus/New Relic/Datadog- თან.

4) Kubernetes: პრაქტიკული შაბლონები

4. 1 ცისფერი-მწვანე (სერვისის სელექტორის მეშვეობით)

Два Deployment: `app-blue` и `app-green`.
ერთი სერვისი 'app-svc' სელექტორით სასურველი 'ვერსიისთვის ".

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

გადართვა - სელექტორის (ან ეტიკეტების) ატომური ცვლილება კონტროლირებადი დასხივებით.

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

შეცვალეთ 'კვირის' ნაბიჯები; დაამატეთ retry, timeout, outlier detector DestinationRule- ზე.

4. 3 Argo Rollouts (მანქანის კანარის პროგონი)

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

შაბლონის ანალიზი დაკავშირებულია მეტრიკებთან (იხ. ქვემოთ).

5) SLO კარიბჭე და მანქანა

• ტექნიკური: 'p95 _ latence', '5xx _ rate', 'error _ budget _ burn', 'CPU/Memory throttling'.
• სასურსათო: 'CR (ანაბარი)', 'გადახდების წარმატება', "მორიელის ფროდა", 'ARPPU "(ცივ ფანჯრებზე).

• თუ '5xx _ rate' ახალი ვერსია> 0. 5% 10 წუთში - სახლი და როლბაკი.
• თუ 'p95 _ latency'> ბაზის 20% - rollback.
• თუ კანარის პოპულარიზაცია ხდება, მაგრამ ბიუჯეტის SLO იწვის> 2 %/საათში - hold.

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) მონაცემები და თავსებადობა (ტკივილის ყველაზე გავრცელებული მიზეზი)

• Expand: დაამატეთ ახალი nullable სვეტები/ინდექსები, მხარი დაუჭირეთ ორივე სქემას.
• Migrate: ორმაგი ჩანაწერი/კითხვა, სარეზერვო ფილმი.
• კონტრაქტი: ძველი ველების/კოდის ამოღება 100% ტრაფიკის მიღწევის შემდეგ.
• ღონისძიება/რიგები: ვერსია payload (v1/v2), მხარი დაუჭირეთ idempotence.
• ქეში/სესიები: კლავიშების ვერსია; უზრუნველყავით ფორმატის თავსებადობა.

7) ინტეგრაცია CI/CD და GitOps

CI: ერთი არტეფაქტის შეკრება, გამოსახულების ხელმოწერა, SBOM, ტესტები.
CD: არტეფაქტი დაწინაურდა გარემოთი; Blue-Green/Canary მართავს მანიფესტებს.
GitOps: mergMR კონტროლერი (Argo CD/Flux) იყენებს წონას/სელექტორს.
Environments/Approvals: სარეკლამო სტეპებისთვის - სახელმძღვანელო გეტა + გადაწყვეტილებების აუდიტი.

8) NGINX/Envoy და ღრუბლოვანი LB: სწრაფი მაგალითები

8. 1 NGINX (აფსიდის წონა)

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 - შეცვალეთ წონა IaC/CLI- ს მეშვეობით.
მიიპყრო CloudWatch ალერტები rollback მანქანის სკრიპტებზე (წონის შეცვლა 0/100).

9) უსაფრთხოება და შესაბამისობა

Zero trust ვერსიებს შორის: განასხვავეთ დაშიფვრის საიდუმლოებები/როლის გასაღებები.
Policy-as-Code: გაუგებარი სურათების ზეპირი აკრძალვა, 'no latest'.
საიდუმლოებები და კონფისკაცია, როგორც ვერსიის არტეფაქტები; გამოტოვება მოიცავს ჩამორთმევის დაბრუნებას.
აუდიტი: ვინ, როდესაც მან წონა/სელექციონერი ასწია, რომელი თიკეტით.

10) ღირებულება და მოცულობა

Blue-Green მოითხოვს ორმაგ სიმძლავრეს გამოშვების პერიოდისთვის - დაგეგმეთ ფანჯარა.
Canary- ს შეუძლია უფრო დიდხანს მიაღწიოს ტელემეტრიის/დაკვირვების ღირებულებას, ორი ვერსიის პარალელურ შინაარსს.
ოპტიმიზაცია: HPA/VPA autoscaling, მოკლე Blue-Green ფანჯრები, ღამის გამოშვებები „მძიმე“ სერვისებისთვის.

11) გამოტოვება (runbook)

1. გაყინვა წინსვლა.
2. მწვანე წონის შემცირება 0% -მდე (კანარი )/სელექტორის ცისფერი (ცისფერი-მწვანე) დაბრუნება.
3. შემოწმება: შეცდომები/ლატენტობა დაუბრუნდა ბაზას, დაარღვია ნაერთები.
4. ინციდენტის გახსნა, არტეფაქტების შეგროვება (ლოგოები, ბილიკები, მეტრული შედარება).
5. Fix/reprode სცენაზე, გადაიტანეთ smoke, განაახლეთ პროგრესი.

12) ანტი შაბლონები

არტეფაქტის გადაკეთება სცენაზე და მილის შორის (დარღვევა „მომარაგება“).
„ყრუ“ კანი SLO/მეტრიკის გარეშე არის ფორმალობა და არა დაცვა.
Fich დროშების არარსებობა: გამოშვება იძულებულია ქცევა დაუყოვნებლივ შეიტანოს 100% -ით.
არასამუშაო health-checks/liveness არის „ჩაძირული“ გადასახადები და ცრუ სტაბილურობა.
BD- ს თავსებადობა „Avos- ზე“: კონტრაქტი იშლება გადართვის დროს.
Mutable სურათების ჭდეები/' latest 'გაყიდვაში.

13) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

სტრატეგიის არჩევა სერვისებისთვის: B/G, Canary ან კომბინირებული.
ჩართეთ სურათების ხელმოწერა, health checks, რეალობის ტესტები, 'no latest'.
მოამზადეთ dashbords SLO (latency/error/ბიზნეს მეტრიკა).

11-25 დღე

წონის ავტომატიზაცია (Istio/Argo Rollouts/ALB-weights).
Analysis templates, alertes და auto-rollback კონფიგურაცია.
მანიფესტების შაბლონიზაცია (Helm/Kustomize), ინტეგრირება GitOps- თან.

26-45 დღე

შემოიღეთ BD- სთვის ექსპერიმენტული-საკონტროლო სტრატეგია.
დაფარეთ კრიტიკული flow-switch დროშებით.
გამართეთ „თამაშის დღე“: გამოტოვეთ დაბრუნება და ინციდენტი.

14) სიმწიფის მეტრიკა

% გამოშვებები Blue-Green/Canary- ის საშუალებით (მიზანი> 90%).
გადართვის/გამოტოვების საშუალო დრო (მიზანი <3 წუთი).
SLO (და ინციდენტების გარეშე) მანქანების გაჩერების გამოშვების წილი.
ტელემეტრიული სერვისების დაფარვა (traces/logs/metrics)> 95%.
BD- ს მიგრაციის წილი ექსპანსიური-საკრედიტო-კონტრაქტის სქემის მიხედვით> 90%.

15) პროგრამები: პოლიტიკის შაბლონები და პლაკატები

OPA (გაუგებარი სურათების აკრძალვა)

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 values for canary (გამარტივებული)

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

GitHub Actions - წონის პოპულარიზაცია (ფსევდო)

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) დასკვნა

Blue-Green და Canary არ არის ურთიერთგამომრიცხავი, არამედ კომბინირებული სტრატეგიები. ააშენეთ ისინი ხელმოწერილი არტეფაქტების თავზე, დაკვირვებით SLO, ავტომატური კარიბჭეები და GitOps მენეჯმენტი. გამოყავით მიტანა ჩართვისგან, შეინარჩუნეთ სწრაფი დაბრუნება და მიგრაციის დისციპლინა - და გამოშვებები გახდება პროგნოზირებული, უსაფრთხო და სწრაფი.