גרסאות של מישור הבקרה ב-Cloud Service Mesh

הערה: המדריך הזה תומך רק ב-Cloud Service Mesh עם ממשקי Istio API, ולא תומך בממשקי Google Cloud API. מידע נוסף זמין במאמר סקירה כללית על Cloud Service Mesh.

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

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

היסודות של התקנת Service mesh

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

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

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

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

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

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

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

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

איך פועל הוספה אוטומטית של תגי מעקב?

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

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

מהי גרסה?

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

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

• במישורי בקרה בתוך האשכול, בדרך כלל ל-istiod Service ול-Deployment יש תווית של גרסת תיקון שדומה ל-istio.io/rev=asm-1282-4, כאשר asm-1282-4 מציין את הגרסה של Cloud Service Mesh. מספר הגרסה הופך לחלק משם השירות, לדוגמה: istiod-asm-1282-4.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-1282-4 בוחר תרמילים במרחבי שמות עם התווית istio.io/rev=asm-1282-4 ומזריק תהליכים משניים.

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

תוויות של גרסאות מאפשרות לבצע שדרוגים של גרסה ראשונית (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-1282-4

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

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

     service:
        name: istiod-asm-1282-4
        namespace: istio-system
        path: /inject
        port: 443

הערה: ב-Cloud Service Mesh מנוהל, השירות שמנוהל על ידי Google מצוין על ידי url: במקום service:.

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

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

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

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

• שדרוג של Cloud Service Mesh
• הוספת שרתי proxy מסוג sidecar