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

חשוב לדעת: השימוש ב-Cloud Service Mesh באשכול באמצעות מישור הבקרה של ISTIOD ב-GKE ב- Google Cloud הוצא משימוש. אנחנו ממשיכים לתמוך ב-Cloud Service Mesh עם מישור בקרה בתוך האשכול ב-Google Distributed Cloud (תוכנה בלבד), כמו שמתואר במאמר פלטפורמות נתמכות.

שימו לב: הגרסה המנוהלת של Cloud Service Mesh שמשתמשת בהטמעה של מישור הבקרה ISTIOD הוצאה משימוש. צריך לשדרג את כל הציים המנוהלים של ISTIOD להטמעה של מישור הבקרה של TRAFFIC_DIRECTOR.

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

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

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

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

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

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

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

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

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

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

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

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

איך פועלת ההזרקה האוטומטית?

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

1. הגדרת ה-webhook נוצרת במהלך ההתקנה. ה-webhook רשום בשרת ה-API של Kubernetes.
2. שרת ה-API של Kubernetes עוקב אחרי פריסות של Pods במרחבי שמות שתואמים ל-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-1298-11, כאשר asm-1298-11 מזהה את הגרסה של Cloud Service Mesh. הגרסה הופכת לחלק משם השירות, לדוגמה: istiod-asm-1298-11.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-1298-11 בוחר פודים במרחבי שמות עם התווית istio.io/rev=asm-1298-11 ומזריק קובצי sidecar.

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

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

ככה זה עובד:

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

אחרי שמשייכים את ה-Pods למישור הבקרה החדש, מישור הבקרה הקיים וה-webhook עדיין מותקנים. ל-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-1298-11

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

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

     service:
        name: istiod-asm-1298-11
        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
• החדרת קובצי עזר חיצוניים