ממשקי API של מישור הבקרה xDS

‫Cloud Service Mesh והלקוחות שלו (Envoy proxies או ספריות gRPC בלי שרת Proxy) משתמשים ב-open source xDS API כדי להחליף מידע. כשמגדירים את Cloud Service Mesh – למשל, באמצעות משאבים כמו כללי העברה ושירותי קצה עורפיים – Cloud Service Mesh ממיר את המשאבים האלה להגדרת xDS, שאותה הוא משתף עם הלקוחות שלו.

תמיכה בגרסת xDS

‫Cloud Service Mesh תומך רק ב-xDS v3.

כדי לדעת אילו גרסאות של Envoy ו-gRPC תומכות ב-xDS v3, אפשר לעיין במאמרי העזרה של Envoy ושל gRPC.

אם אתם עדיין משתמשים ב-xDS v2, תוכלו להיעזר בהוראות הבאות כדי לעבור ל-xDS v3.

העברה מ-xDS v2 ל-xDS v3

תהליך ההעברה כולל שני שלבים:

  1. עדכון ההרשאות לניהול הזהויות והגישה (IAM) שניתנו לחשבון השירות שבו הלקוחות (Envoy proxies או ספריות gRPC ללא שרת Proxy) משתמשים כשהם מתחברים ל-Cloud Service Mesh.
  2. מעדכנים ופורסים מחדש את האפליקציות. השלבים הספציפיים משתנים בהתאם לפריסה שלכם, והם מוסברים בקטעים הבאים.

עדכון הרשאות IAM של חשבון השירות

מוודאים שלחשבון השירות שבו משתמשים הלקוחות של Cloud Service Mesh (Envoy, ‏ proxyless gRPC) יש את ההרשאות trafficdirector.networks.reportMetrics ו-trafficdirector.networks.getConfigs. ההרשאות האלה כלולות ב-IAM בתפקיד Traffic Director Client (roles/trafficdirector.client).

אם אתם משתמשים בתפקיד IAM בהתאמה אישית, אתם יכולים להוסיף את ההרשאות האלה לתפקיד בהתאמה אישית. אחרי שמוסיפים את ההרשאות, אפשר להסיר את התפקיד 'צפייה ברשת של Compute' (roles/compute.networkViewer), את התפקיד 'אדמין רשת של Compute' (roles/compute.networkAdmin) או את שניהם מחשבון השירות.

מומלץ להשתמש בתפקיד 'לקוח Cloud Service Mesh' במקום בתפקיד 'צפייה ברשת Compute' (roles/compute.networkViewer) או בתפקיד 'אדמין של רשת Compute' (roles/compute.networkAdmin). שימוש בתפקיד 'לקוח Cloud Service Mesh' מגביל את ההרשאות שניתנות לחשבון השירות ומונע מתן הרשאות רחבות מדי.

עדכון האפליקציות

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

‫Envoy ב-Compute Engine

כדי לעדכן את האפליקציות ב-Envoy באמצעות Compute Engine, צריך לבצע הפעלה מחדש הדרגתית או החלפה של קבוצות המופעים המנוהלות. גרסה של Envoy שתומכת ב-xDS v3 מתווספת באופן אוטומטי למכונות הווירטואליות.

‫Envoy ב-GKE

אם אתם משתמשים בהזרקת Envoy אוטומטית עם Google Kubernetes Engine ‏ (GKE), צריך להתקין מחדש את מזרים ה-sidecar באשכולות GKE שבהם אתם משתמשים עם Cloud Service Mesh. כשנוצר Pod חדש, פרוקסי Envoy קובץ עזר חיצוני שתומך ב-xDS v3 מוזרק באופן אוטומטי לצד ה-Pod של עומס העבודה.

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

Proxyless gRPC

תהליך ההעברה כולל שני שלבים:

  1. מוודאים שגרסת gRPC שבה אתם משתמשים תומכת ב-xDS v3. מידע נוסף זמין במאמר בנושא תכונות xDS ב-gRPC.

  2. כדי לעדכן את הגדרות ה-bootstrap, פועלים לפי השלבים הבאים:

    1. בשדה "xds_servers" מוסיפים את הערך "server_features": ["xds_v3"] כמו שמופיע בדוגמה הזו של קובץ bootstrap.

    2. מזהה הצומת צריך להיות בפורמט הבא, כמו בדוגמה הקודמת:

      "projects/PROJECT_NUMBER/networks/NETWORK_NAME/nodes/ID"

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

השינויים הקודמים בהגדרת ה-bootstrap לא משפיעים על גרסאות gRPC שלא תומכות ב-xDS v3. בנוסף, אם השינויים הקודמים לא מופיעים בהגדרת ה-bootstrap, גרסאות gRPC שתומכות ב-xDS v3 משתמשות ב-xDS v2.

לנוחיותכם, אתם יכולים להשתמש בCloud Service Mesh gRPC bootstrap generator גרסה 0.16.0 או בגרסה מאוחרת יותר כדי ליצור הגדרת bootstrap שתואמת ל-xDS v3.

אימות שלקוחות Cloud Service Mesh משתמשים ב-xDS v3

כדי לבדוק את ההגדרה ש-Cloud Service Mesh יוצר עבור הלקוחות שלו, אפשר להשתמש בכלי לבדיקת סטטוס הלקוח. בכלי הזה מצוין אם ההגדרה היא xDS v2 או xDS v3.

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