כחול-ירוק ופריסה קנרית

כחול-ירוק ופריסה קנרית

1) אתגר ורעיונות מרכזיים

• כחול-ירוק: שמור שתי גרסאות מקבילות (כחול - פעיל, ירוק - חדש), תחליף את התנועה באופן אטומי. Rollback מהיר פעמים חוזר מיד כחול.
• Canary: הפעל את הגרסה החדשה בשלבים (1% -5% -.ach 25% 50% = 100%), פקח על מדטי SLO ועצור/רול בחזרה במהלך הידרדרות.

העיקרון הכללי הוא להפריד בין ”משלוח חפץ” מ ”הכללת תנועה” לבין יכולת תצפית אוטומטית + גלגולים.

2) מתי לבחור

• צריך החלפה מיידית (RTO קשה), שירותים פשוטים חסרי מדינה;
• יש שחרור קפדני/הקפאת חלונות ובדיקות עשן נקיות;
• זה יקר להחזיק קיבולת כפולה ארוכה - אבל זה אפשרי לזמן קצר.

• שינויים מורכבים, אימות צעד אחר צעד על תנועה אמיתית נדרשת;
• יש טלמטריה בוגרת (SLO, מדדים עסקיים), יכולת עצירה אוטומטית;
• קריטי להגביל את רדיוס הנזק (fintech/iGaming streams).

תבנית משולבת: לגלגל את גרין ולעבור אליו דרך שלבי הקנרית (כחול-ירוק כמסגרת, קנרית כשיטה לנשיאת תנועה).

3) ארכיטקטורת ניתוב תנועה

1. L4/L7 Balancer (ALB/NLB, Cloud Load Balancer) - קבוצות מטרה משוקללות.

2. שער API/WAF - מסלול/משקל לפי גרסאות, כותרות, עוגיות, אזורים.

3. Service Mesh (Istio/Linkerd/Consul) - אחוז התפלגות, הזרקת תקלה, זמן מגש/מגש/ידיות הגבלה.

4. כניסה/NGINX/שליח - משקולות במעלה הזרם וניתוב תכונה.

5. Argo Rollouts/Plagger - מפעיל בקר, התקדמות אוטומטית, אינטגרציה עם Prometheus/New Relic/Datadog.

4) קוברנטס: תבניות מעשיות

4. 1 כחול-ירוק (באמצעות בחירת שירות)

פריסה: "אפליקציה כחולה" אפליקציה ירוקה ".
שירות אחד ”אפליקציה-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 Virtuality Service)

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

שינוי ”משקל” על ידי שלב; תוסיף ניסיון חוזר, פסק זמן, גלאי חיצוני לחוק החיפוש.

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 _ latency", "5xx _ rate", "שגיאה _ budder _ burn'," מעבד/חנק זיכרון ".
• מכולת: CR (הפקדה), ”הצלחה בתשלומים”, ”הונאת ניקוד”, ”ARPU” (על חלונות קרים).

• אם '5xx _ rate' של הגרסה החדשה הוא> 0. 5% עבור 10 דקות - הפסקה וחזרה.
• אם ”p95 _ latency” lung> 20% מהבסיס - rollback.
• אם הקידום בקנרית הולך, אבל התקציב של SLO נשרף> 2 %/שעה - המתן.

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) נתונים ותאימות (הגורם הנפוץ ביותר לכאב)

השתמש באסטרטגיית חוזי ההגירה המתרחבת

התרחב: הוסף טורים חדשים/אינדקסים, תמוך בשתי התכניות.
נדידה: כתיבה כפולה/קריאה, מילוי גב.
חוזה: למחוק שדות/קוד ישנים לאחר יציאת 100% מהתנועה.
אירוע/תורים: מטען גרסה (v1/v2), תמיכה באידמפוטנטיות.
מטמון/הפעלות: מפתחות גרסה; ודא שתאימות לפורמט.

7) אינטגרציה עם CI/CD ו ־ GitOps

CI: לבנות פעם אחת, חתימת תמונה, SBOM, בדיקות.
CD: קידום חפץ דרך סביבות; כחול-ירוק/קנרי נשלטים על ידי מניפסטים.
GitOps: בקר MR ac (Argo CD/Flox) מיישם משקולות/סלקטורים.
סביבות/אישורים: עבור צעדי ייצור - החלטות שער ידני + ביקורת.

8) NGINX/שליח וענן LBs: דוגמאות מהירות

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 (קבוצות יעד משוקללות)

TG-Blue: 90, TG-Green: 10 כפול שינוי משקולות דרך IC/CLI.
התראות Link CloudWatch לתסריטים אוטומטיים (שינוי משקל ל ־ 0/100).

9) בטיחות וציות

אפס אמון בין גרסאות: להבחין בין סודות הצפנה/מפתחות גלגול.
מדיניות-כקוד: לא לאפשר פריסת תמונה לא חתומה, ”לא עדכני”.
סודות ותצורות כחפצי גרסה; rollback כולל rollback של תצורות.
מי, כשהוא הרים את המשקל/החליף את הסלקטור, עם איזה כרטיס.

10) עלות וקיבולת

Blue-Green דורש להכפיל את הכוח עבור תקופת השחרור _ לתכנן חלון.
Canary יכול להימשך יותר = עלות טלמטריה/מעקב, תוכן מקביל של שתי גרסאות.
אופטימיזציה: החלפה אוטומטית של HPA/VPA, חלונות קצרים כחולים-ירוקים, שחרור לילי עבור שירותים ”כבדים”.

11) ספרי ריצה

1. עצור את הקידום.
2. הפחתת המשקל הירוק ל 0% (קנרית )/חזרה סלקטור לכחול (כחול ירוק).
3. בדוק: שגיאות/latency חזר לקשרים בסיסיים, לנקז.
4. פתח תקרית, לאסוף חפצים (יומנים, מסלולים, השוואה של מדדים).
5. תיקון/תוכחה לבמה, לנהוג עשן, התקדמות מחדש.

12) אנטי דפוסים

בנייה מחדש של חפץ בין שלב לדחף (הפרה של ”לבנות פעם אחת”).
קנרית ”חירשת” ללא SLO/Metrics היא עניין פורמלי, לא הגנה.
היעדר דגלי תכונה: השחרור נאלץ לכלול התנהגות 100% בבת אחת.
בדיקת בריאות/לביאה לא עובדת * תחתיות ”דביקות” ויציבות כוזבת.
התאמת מסד הנתונים ”באקראי”: החוזה נשבר בעת ההחלפה.
תגי תמונה מוטוריים/” עדכניים ”בתבנית.

13) רשימת מימושים (0-45 ימים)

0-10 ימים

בחר אסטרטגיה לשירותים: B/G, קנרית או משולבת.
אפשר חתימת תמונות, בדיקות בריאות, דגימות מוכנות, ”לא עדכני”.
הכן לוחות מחוונים של SLO (latency/image rate/business metrics).

11-25 ימים

משקולות אוטומטיות (Istio/Argo Rollouts/ALB-Klights).
הגדרת תבניות ניתוח, התראות וחזרה אוטומטית.
מניפסטים בתבנית (Helm/Kustomize), אינטגרציה עם GitOps.

26-45 ימים

יישום אסטרטגיית חוזה הרחבת ההגירה לבסיס הנתונים.
כסה דגלים קריטיים להחלפה.
לבלות את ”יום המשחק”: לדמות גלגול חוזר ותקרית.

14) מדדי בגרות

% משוחררים דרך Blue-Green/Canary (המטרה> 90%).
זמן החלפה/rollback ממוצע (יעד <3 דקות).
שיתוף של שחרור עם SLO אוטומטי עצירה (וללא תקריות).
כיסוי שירות באמצעות טלמטריה (עקבות/לוגים/מטרים)> 95%.
הנתח של הגירות DB לפי תוכנית חוזה ההגירה הרחבה הוא> 90%.

15) מצורפים: תבניות מדיניות וצינור

אופ "א (תמונות לא חתומות)

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

ערכי הלם לקנרית (מפושט)

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

GitHub פעולות - קידום משקל (פסאודו)

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) מסקנה

כחול-ירוק וקנריים אינם בלעדיים, אלא אסטרטגיות משלימות. לבנות אותם על גבי חפצים חתומים, תצפית SLO, שערים אוטומטיים ושליטה GitOps. משלוח נפרד מהכללה, שמירה על גלגיליות מהירות ומשמעת נדידה - ושחרורים הופכים להיות צפויים, בטוחים ומהירים.