עדכונים במישור הבקרה של Cloud Service Mesh

הדף הזה רלוונטי לISTIOD הטמעות של מישור הבקרה בתוך האשכול ובניהול. הדף הזה לא רלוונטי להטמעה של מישור הבקרה TRAFFIC_DIRECTOR, שהוא מישור בקרה גלובלי עם דיירים רבים, ללא עדכונים נפרדים.

בדף הזה מוסבר איך פועלות גרסאות של מישור הבקרה, ולמה כדאי להשתמש בהן כדי לשדרג (ולבטל שדרוגים) את Service mesh בצורה בטוחה.

הגדרות יסוד להתקנת Service mesh

באופן כללי, התקנת Cloud Service Mesh מורכבת משני שלבים עיקריים:

  1. קודם משתמשים בכלי asmcli כדי להתקין מישור בקרה בתוך האשכול או כדי להגדיר את מישור הבקרה המנוהל. מישור הבקרה מורכב מקבוצה של שירותי מערכת שאחראים לניהול ההגדרות של רשת השירותים.

  2. לאחר מכן, פורסים פרוקסי מסוג sidecar מיוחד בכל הסביבה, שמיירט את התקשורת ברשת אל כל עומס עבודה וממנו. הפרוקסיים מתקשרים עם מישור הבקרה כדי לקבל את ההגדרה שלהם, וכך אתם יכולים לנהל את התנועה (תנועה במישור הנתונים) ברשת בלי לבצע שינויים בעומסי העבודה.

    כדי לפרוס את ה-proxies, משתמשים בתהליך שנקרא הזרקת sidecar אוטומטית (auto-injection) כדי להריץ proxy כקונטיינר sidecar נוסף בכל אחד מ-Pods של עומסי העבודה. אין צורך לשנות את קובצי המניפסט של Kubernetes שבהם אתם משתמשים כדי לפרוס את עומסי העבודה, אבל אתם צריכים להוסיף תווית למרחבי השמות ולהפעיל מחדש את ה-Pods.

שימוש בגרסאות כדי לשדרג את הרשת בצורה בטוחה

היכולת לשלוט בתעבורת הנתונים היא אחד היתרונות העיקריים של השימוש ב-Service mesh. לדוגמה, אתם יכולים להעביר בהדרגה תנועה לגרסה חדשה של אפליקציה כשאתם פורסים אותה לראשונה בסביבת ייצור. אם מזהים בעיות במהלך השדרוג, אפשר להעביר את התנועה בחזרה לגרסה המקורית. כך אפשר לבצע שחזור פשוט עם סיכון נמוך. התהליך הזה נקרא הפצה קנרית, והוא מפחית באופן משמעותי את הסיכון שקשור לפריסות חדשות.

כשמשתמשים בשינויים של רמת הבקרה בשדרוג קנרי, מתקינים רמת בקרה חדשה ונפרדת והגדרה לצד רמת הבקרה הקיימת. תוכנת ההתקנה מקצה מחרוזת שנקראת 'גרסה' כדי לזהות את מישור הבקרה החדש. בהתחלה, שרתי ה-proxy מסוג sidecar ממשיכים לקבל הגדרות מהגרסה הקודמת של מישור הבקרה. אתם מקשרים בהדרגה את עומסי העבודה למישור הבקרה החדש על ידי תיוג של מרחבי השמות או של ה-Pods שלהם בגרסה החדשה של מישור הבקרה. אחרי שמסמנים מרחב שמות או Pods בגרסה החדשה, מפעילים מחדש את ה-Pods של עומס העבודה כדי שמערכת תזריק באופן אוטומטי sidecars חדשים, והם יקבלו את ההגדרה שלהם ממישור הבקרה החדש. אם יש בעיות, אפשר לחזור בקלות אחורה על ידי שיוך עומסי העבודה למישור הבקרה המקורי.

איך פועלת ההחדרה האוטומטית?

ההזרקה האוטומטית מתבססת על תכונה של Kubernetes שנקראת בקרת כניסה. ווּבְּהוּק קבלה לשינוי רשום כדי לעקוב אחרי Pod חדש שנוצר. ה-webhook מוגדר עם בורר מרחב שמות, כך שהוא מתאים רק ל-Pods שנפרסים למרחבי שמות עם תווית מסוימת. אם יש התאמה ל-Pod, ה-webhook מתייעץ עם שירות הוספה שסופק על ידי מישור הבקרה כדי לקבל הגדרה חדשה שעברה שינוי עבור ה-Pod, שמכילה את הקונטיינרים והנפחים שנדרשים להרצת ה-sidecar.

רכיב להחדרת sidecar אוטומטית

  1. הגדרת webhook נוצרת במהלך ההתקנה. ה-webhook רשום בשרת ה-API של Kubernetes.
  2. שרת ה-API של Kubernetes עוקב אחרי פריסות של Pod במרחבי שמות שתואמים ל-Webhook‏ namespaceSelector.
  3. מרחב שמות מתויג כך שהוא יתאים ל-namespaceSelector.
  4. הפודים שנפרסו במרחב השמות מפעילים את ה-webhook.
  5. שירות inject שמופעל במישור הבקרה משנה את מפרטי ה-Pod כדי להוסיף אוטומטית את ה-sidecar.

מהי גרסה?

התווית שמשמשת להחדרה אוטומטית היא כמו כל תווית אחרת של Kubernetes שהוגדרה על ידי המשתמש. תווית היא בעצם צמד מפתח/ערך שאפשר להשתמש בו כדי לתמוך במושג של תיוג. התוויות משמשות באופן נרחב לתיוג ולעדכונים. לדוגמה, תגי Git, תגי Docker ועדכוני Knative.

תהליך ההתקנה הנוכחי של Cloud Service Mesh מאפשר לכם לתייג את רמת הבקרה שהותקנה באמצעות מחרוזת של מספר גרסה. תוכנת ההתקנה מתייגת כל אובייקט של מישור הבקרה בגרסה. המפתח בצמד מפתח/ערך הוא istio.io/rev, אבל הערך של תווית הגרסה שונה ברמת הבקרה המנוהלת וברמות הבקרה בתוך האשכול.

  • במישורי בקרה בתוך האשכול, בדרך כלל לשירות ולפריסה istiod יש תווית של גרסה שדומה ל-istio.io/rev=asm-1305-8, כאשר asm-1305-8 מציין את הגרסה של Cloud Service Mesh. מספר הגרסה הופך לחלק משם השירות, לדוגמה: istiod-asm-1305-8.istio-system

  • במישור הבקרה המנוהל, תווית הגרסה מתאימה לערוץ הפצה:

    תווית הגרסה ערוץ
    istio.io/rev=asm-managed Regular
    istio.io/rev=asm-managed-rapid חדשנות
    istio.io/rev=asm-managed-stable יציב

בנוסף, יש לכם אפשרות להשתמש בתוויות ברירת מחדל להוספה (לדוגמה, istio-injection=enabled).

כדי להפעיל הזרקה אוטומטית, מוסיפים תווית של עדכון למרחבי השמות, שתואמת לתווית של העדכון במישור הבקרה. לדוגמה, מישור בקרה עם עדכון istio.io/rev=asm-1305-8 בוחר פודים במרחבי שמות עם התווית istio.io/rev=asm-1305-8 ומזריק קבצים מצורפים.

תהליך השדרוג של Canary

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

שדרוג בגרסה ראשונית

השלבים הבאים מתארים את התהליך:

  1. מתחילים עם התקנה קיימת של Cloud Service Mesh או של Istio בקוד פתוח. אין חשיבות לתווית הגרסה או לתווית istio-injection=enabled במרחבי השמות.
  2. משתמשים במחרוזת של עדכון כשמתקינים את הגרסה החדשה של מישור הבקרה. בגלל מחרוזת התיקון, רמת הבקרה החדשה מותקנת לצד הגרסה הקיימת. ההתקנה החדשה כוללת הגדרה חדשה של webhook עם namespaceSelector שמוגדרת למעקב אחרי מרחבי שמות עם תווית התיקון הספציפית הזו.
  3. כדי להעביר את ה-sidecar proxies למישור הבקרה החדש, צריך להסיר את התווית הישנה ממרחב השמות, להוסיף את תווית הגרסה החדשה ואז להפעיל מחדש את ה-Pods. אם אתם משתמשים בגרסאות עם Cloud Service Mesh, אתם צריכים להפסיק להשתמש בתווית istio-injection=enabled. מישור בקרה עם עדכון לא בוחר פודים במרחבי שמות עם התווית istio-injection, גם אם יש תווית עדכון. ה-webhook של מישור הבקרה החדש מחדיר sidecar ל-Pods.
  4. צריך לבדוק בקפידה את עומסי העבודה שמשויכים לרמת הבקרה המשודרגת, ולהמשיך בהשקת השדרוג או לחזור לרמת הבקרה המקורית.

אחרי שמשייכים את ה-Pods למישור הבקרה החדש, מישור הבקרה הקיים וה-webhook עדיין מותקנים. לווב-הוק הישן אין השפעה על Pods במרחבי שמות שהועברו למישור הבקרה החדש. אפשר להחזיר את ה-Pods במרחב השמות למישור הבקרה המקורי על ידי הסרת התווית של הגרסה החדשה, הוספה מחדש של התווית המקורית והפעלה מחדש של ה-Pods. כשבטוחים שהשדרוג הושלם, אפשר להסיר את מישור הבקרה הישן.

הוראות מפורטות לשדרוג באמצעות עדכונים זמינות במדריך לשדרוג.

הסבר מפורט על הגדרת תגובה לפעולה מאתר אחר (webhook) שמשנה את המשאב

כדי להבין טוב יותר את ה-webhook לשינוי לצורך החדרת sidecar אוטומטית, כדאי לבדוק את ההגדרה בעצמכם. משתמשים בפקודה הבאה:

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

אמורה להופיע הגדרה נפרדת לכל מישור בקרה שהתקנתם. בורר מרחב שמות למישור בקרה מבוסס-עדכון נראה כך:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1305-8

הבורר עשוי להשתנות בהתאם לגרסה של Cloud Service Mesh או של Istio שמופעלת. הבורר הזה מתאים למרחבי שמות עם תווית ספציפית של גרסה, כל עוד אין להם גם תווית istio-injection.

כשפריט Pod נפרס במרחב שמות שתואם לסלקטור, מפרט ה-Pod שלו נשלח לשירות ההזרקה לצורך שינוי. שירות ה-injector שצריך להפעיל מוגדר כך:

     service:
        name: istiod-asm-1305-8
        namespace: istio-system
        path: /inject
        port: 443

השירות נחשף על ידי מישור הבקרה ביציאה 443 בנתיב כתובת ה-URL ‏inject.

בקטע rules מצוין שצריך להחיל את ה-webhook על יצירת Pod:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

המאמרים הבאים