הכנה להגדרת Cloud Service Mesh עם Envoy

ההגדרה של Cloud Service Mesh כוללת את השלבים הבאים:

  1. צריך לתת הרשאות, להפעיל את Traffic Director API, ואם משתמשים ב-Compute Engine, צריך להגדיר את Cloud DNS.
  2. פריסת האפליקציות באמצעות שרתי proxy של Envoy.
  3. יצירת שירותים וכללי ניתוב שקובעים איך התנועה עוברת דרך ה-Service mesh.

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

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

דרישות מוקדמות

בין אם אתם מתכננים להשתמש ב-Cloud Service Mesh כדי להגדיר שרתי proxy של Envoy שפועלים לצד אפליקציות במכונות וירטואליות (VM), בקונטיינרים או בשילוב של שניהם, אתם צריכים קודם לבצע את המשימות הבאות:

  1. מפעילים את החיוב.
  2. מחליטים איך רוצים להתקין את Envoy.
  3. נותנים את ההרשאות הנדרשות.
  4. מפעילים בפרויקט את Traffic Director API.
  5. אם אתם משתמשים ב-Compute Engine, אתם צריכים להפעיל את Cloud DNS API ולהגדיר את Cloud DNS.
  6. מוודאים שלחשבון השירות שמשמש את שרתי ה-proxy של Envoy יש הרשאות מספיקות לגישה ל-Traffic Director API.

בקטעים הבאים מוסבר איך מבצעים כל משימה.

הפעלת החיוב

מוודאים שהחיוב מופעל בפרויקט Google Cloud . מידע נוסף זמין במאמר הפעלה, השבתה ושינוי של חיוב בפרויקט.

קובעים איך להתקין את Envoy

באמצעות Cloud Service Mesh אפשר להתקין שרתי proxy של Envoy ולנהל את שכבת התשתית הזו:

  • ב-Compute Engine, אפשר להוסיף את Envoy באופן אוטומטי לאפליקציות שפועלות במכונות הווירטואליות. אתם משתמשים בתבנית של מכונה וירטואלית שמתקינה את Envoy, מחברת אותה ל-Cloud Service Mesh ומגדירה את הרשת של המכונה הווירטואלית.

  • ב-Google Kubernetes Engine‏ (GKE), אתם יכולים להוסיף באופן אוטומטי פרוקסי מסוג Envoy sidecar לפודים של השירותים שלכם. מתקינים Envoy sidecar injector באשכול, שמוסיף Envoy sidecar proxies, מחבר אותם ל-Cloud Service Mesh ומגדיר את הרשת של הקונטיינר.

לבסוף, אפשר גם להשתמש בפתרונות פריסה של Envoy מספקי צד שלישי עם Cloud Service Mesh. דוגמה לפתרון כזה היא GetEnvoy, שמספק גישה מבוססת-מנהל חבילות להתקנה ולעדכון של שרתי ה-proxy של Envoy.

מידע על ניהול גרסאות של Envoy

כדי להשתמש ב-Envoy עם Cloud Service Mesh, צריך להשתמש בגרסה 1.9.1 ואילך. מומלץ להשתמש תמיד בגרסה העדכנית ביותר של Envoy כדי למנוע חולשות אבטחה ידועות.

אם תבחרו לפרוס את Envoy באמצעות אחת מהשיטות האוטומטיות שלנו, אנחנו נבצע את המשימה הזו בשבילכם באופן הבא:

  • כשמשתמשים בפריסה אוטומטית של Envoy עם מכונות וירטואליות ב-Compute Engine, הגרסה של Envoy שמותקנת היא גרסה שאומתה על ידינו כגרסה שעובדת עם Cloud Service Mesh. כשיוצרים מכונת VM חדשה באמצעות תבנית של הגדרות מכונה, המכונה מקבלת את הגרסה העדכנית ביותר שאימתנו. אם יש לכם מכונה וירטואלית שפועלת לאורך זמן, אתם יכולים להשתמש בעדכון בהדרגה (rolling) כדי להחליף את המכונות הווירטואליות הקיימות ולהוריד את הגרסה העדכנית.

  • כשמשתמשים ב-Envoy sidecar injector עם GKE, ה-injector מוגדר להשתמש בגרסה עדכנית של Envoy שאימתנו את התאימות שלה ל-Cloud Service Mesh. כשקובץ sidecar מוזרק לצד עומס העבודה שלכם ב-Pod, הוא מקבל את הגרסה הזו של Envoy. אם רוצים להשתמש בגרסה עדכנית יותר של Envoy, צריך לעדכן את Envoy sidecar injector.

מידע על גרסאות ספציפיות של Envoy זמין במאמר בנושא היסטוריית הגרסאות. מידע על נקודות חולשה באבטחה זמין במאמר בנושא המלצות אבטחה.

הענקת הרשאות IAM נדרשות

צריכות להיות לכם הרשאות מספיקות לניהול זהויות והרשאות גישה (IAM) כדי ליצור מכונות וירטואליות ולשנות רשת כדי להגדיר את Cloud Service Mesh. אם יש לכם את התפקיד בעלים או עורך (roles/owner או roles/editor) בפרויקט שבו אתם מפעילים את Cloud Service Mesh, יש לכם באופן אוטומטי את ההרשאות הנכונות.

אחרת, אתם צריכים לקבל את כל תפקידי ה-IAM של Compute Engine שמופיעים בטבלה הבאה. אם יש לכם את התפקידים האלה, יש לכם גם את ההרשאות שמשויכות אליהם, כמו שמתואר במסמכי העזרה של IAM ב-Compute Engine.

משימה תפקיד נדרש
הגדרת מדיניות IAM לחשבון שירות. אדמין בחשבון שירות
(roles/iam.serviceAccountAdmin)
מפעילים את Cloud Service Mesh. אדמין של שימוש בשירות
(roles/serviceusage.serviceUsageAdmin)
יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים. אדמין של רשתות ב-Compute
(roles/compute.networkAdmin)
להוסיף ולהסיר כללים של חומת האש. אדמין לענייני אבטחה ב-Compute
(roles/compute.securityAdmin)
ליצור מופעים. אדמין מכונות של Compute
(roles/compute.instanceAdmin)

למאגר הצמתים של GKE או למכונות הווירטואליות ב-Compute Engine צריך להיות היקף https://www.googleapis.com/auth/cloud-platform. מידע נוסף זמין במאמר בנושא פתרון בעיות בפריסות שמשתמשות ב-Envoy.

ב-xDS v3, צריך לתת לחשבון השירות שבו משתמשים לקוחות Cloud Service Mesh Envoy את התפקיד roles/trafficdirector.client.

הפעלת Traffic Director API

המסוף

  1. במסוף Google Cloud , נכנסים לדף API Library של הפרויקט.

    לדף API Library

  2. בשדה Search for APIs & Services (חיפוש ממשקי API ושירותים), מזינים Traffic Director.

  3. ברשימת תוצאות החיפוש, לוחצים על Traffic Director API. אם ה-API של Traffic Director לא מופיע ברשימה, סימן שאין לכם את ההרשאות הנדרשות להפעלת ה-API של Traffic Director.

  4. בדף Traffic Director API, לוחצים על Enable.

gcloud

מריצים את הפקודה הבאה:

gcloud services enable trafficdirector.googleapis.com

הפעלת Cloud DNS API והגדרת Cloud DNS

ההוראות האלה מיועדות להגדרת Cloud Service Mesh ב-Compute Engine. צריך להפעיל את Cloud DNS API ולהגדיר את Cloud DNS לרזולוציית שמות DNS.

מידע נוסף על Cloud Service Mesh ועל פתרון DNS זמין במאמר Cloud Service Mesh ופתרון שמות DNS.

קודם כל, צריך להשתמש בהוראות הבאות כדי להפעיל את Cloud DNS API.

המסוף

  1. במסוף Google Cloud , נכנסים לדף API Library של הפרויקט.

    לדף API Library

  2. בשדה Search for APIs & Services (חיפוש ממשקי API ושירותים), מזינים DNS.

  3. ברשימת תוצאות החיפוש, לוחצים על Cloud DNS API. אם Cloud DNS API לא מופיע ברשימה, סימן שאין לכם את ההרשאות הנדרשות להפעלת Cloud DNS API.

  4. בדף Cloud DNS API, לוחצים על Enable (הפעלה).

gcloud

מריצים את הפקודה הבאה:

gcloud services enable dns.googleapis.com

לאחר מכן, מגדירים תחום פרטי מנוהל ב-Cloud DNS. פועלים לפי ההוראות במאמר יצירת אזור פרטי.

מתן אפשרות לחשבון השירות לגשת אל Traffic Director API

כשמגדירים את מישור הנתונים ומקשרים אותו ל-Cloud Service Mesh, לקוחות ה-xDS (לדוגמה, שרתי proxy של Envoy) מתחברים לtrafficdirector.googleapis.comשרת ה-xDS. לקוחות xDS האלה מציגים זהות של חשבון שירות לשרת xDS כדי לוודא שהתקשורת בין מישור הנתונים למישור הבקרה מורשית כראוי:

  • במכונה וירטואלית ב-Compute Engine, לקוח ה-xDS משתמש בחשבון השירות שהוקצה למכונה הווירטואלית.
  • ב-GKE, אם האפשרות Workload Identity לא מופעלת, לקוח xDS משתמש בחשבון השירות שהוקצה לצומת GKE הבסיסי.
  • אם האפשרות Workload Identity מופעלת, לקוח xDS משתמש בחשבון השירות של Google שמקושר לחשבון השירות של Kubernetes שהוקצה לקבוצת ה-Pod.

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

כשמשתמשים ב-xDS v3, לחשבון השירות שבו הלקוחות משתמשים צריכות להיות ההרשאות trafficdirector.networks.reportMetrics, trafficdirector.rateLimitDomains.reportMetrics ו-trafficdirector.networks.getConfigs. אפשר להשתמש בתפקיד הלקוח של Traffic Director (roles/trafficdirector.client) ב-IAM, שכולל את ההרשאות האלה.

המסוף

  1. במסוף Google Cloud , נכנסים לדף IAM & Admin.

    כניסה לדף IAM & Admin

  2. בוחרים את הפרויקט הרצוי.

  3. מזהים את חשבון השירות שרוצים להוסיף לו תפקיד:

    • אם חשבון השירות לא מופיע ברשימת החברים, לא הוקצו לו תפקידים. לוחצים על הוספה ומזינים את כתובת האימייל של חשבון השירות.
    • אם חשבון השירות כבר מופיע ברשימה Members, יש לו תפקידים קיימים. בוחרים את חשבון השירות ולוחצים על הכרטיסייה Roles.

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

  5. בוחרים בתפקיד Other > Cloud Service Mesh Client.

  6. כדי להחיל את התפקיד על חשבון השירות, לוחצים על Save.

gcloud

מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding PROJECT \
    --member serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role=roles/trafficdirector.client

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT: הקלדת gcloud config get-value project
  • ‫SERVICE_ACCOUNT_EMAIL: כתובת האימייל שמשויכת לחשבון השירות

המשך תהליך ההגדרה

אחרי שמשלימים את השלבים הנדרשים, אפשר להתחיל להגדיר את Service mesh.