הכנה להגדרה של Cloud Service Mesh עם Envoy
ההגדרה של Cloud Service Mesh כוללת את השלבים הבאים:
- צריך לתת הרשאות, להפעיל את Traffic Director API ולהגדיר את Cloud DNS (אם משתמשים ב-Compute Engine).
- פריסת האפליקציות באמצעות שרתי proxy של Envoy.
- יצירת שירותים וכללי ניתוב שקובעים איך התנועה עוברת דרך ה-Service mesh.
במאמר הזה מתוארת הפאזה הראשונה, והוא רלוונטי אם אתם משתמשים בגרסאות קודמות של ממשקי ה-API. השלבים השני והשלישי מוסברים במדריכים שספציפיים לפלטפורמה, שמפורטים בהמשך המאמר בקטע המשך תהליך ההגדרה.
לפני שתקראו את המדריך הזה, מומלץ לעיין בסקירה הכללית על Cloud Service Mesh. אם אתם משתמשים בממשקי ה-API לניתוב שירותים, כדאי לעיין בסקירה הכללית של ממשקי ה-API לניתוב שירותים.
דרישות מוקדמות
בין אם אתם מתכננים להשתמש ב-Cloud Service Mesh כדי להגדיר שרתי proxy של Envoy שפועלים לצד אפליקציות במכונות וירטואליות (VM), בקונטיינרים או בשילוב של שניהם, אתם צריכים קודם לבצע את המשימות הבאות:
- מפעילים את החיוב.
- מחליטים איך רוצים להתקין את Envoy.
- נותנים את ההרשאות הנדרשות.
- מפעילים בפרויקט את Traffic Director API.
- אם אתם משתמשים ב-Compute Engine, אתם צריכים להפעיל את Cloud DNS API ולהגדיר את Cloud DNS.
- צריך לוודא שלחשבון השירות שמשמש את שרתי ה-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 ל-Pods של השירותים. מתקינים 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. כשיוצרים מכונה וירטואלית חדשה באמצעות תבנית של הגדרות מכונה, המכונה הווירטואלית מקבלת את הגרסה העדכנית ביותר שאימתנו. אם יש לכם מכונה וירטואלית שפועלת לאורך זמן, אתם יכולים להשתמש בעדכון בהדרגה כדי להחליף את המכונות הווירטואליות הקיימות ולהוריד את הגרסה העדכנית.
כשמשתמשים ב-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
המסוף
במסוף Google Cloud , עוברים לדף API Library של הפרויקט.
בשדה Search for APIs & Services, מזינים
Traffic Director.ברשימת תוצאות החיפוש, לוחצים על Traffic Director API. אם ה-API של Traffic Director לא מופיע ברשימה, סימן שאין לכם את ההרשאות הנדרשות להפעלת ה-API של Traffic Director.
בדף 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 באמצעות ההוראות הבאות.
המסוף
במסוף Google Cloud , עוברים לדף API Library של הפרויקט.
בשדה Search for APIs & Services, מזינים
DNS.ברשימת תוצאות החיפוש, לוחצים על Cloud DNS API. אם Cloud DNS API לא מופיע ברשימה, סימן שאין לכם את ההרשאות הנדרשות להפעלת Cloud DNS API.
בדף 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, שכולל את ההרשאות האלה.
המסוף
במסוף Google Cloud , נכנסים לדף IAM & Admin.
בוחרים את הפרויקט הרצוי.
מזהים את חשבון השירות שרוצים להוסיף לו תפקיד:
- אם חשבון השירות לא מופיע ברשימת החברים, לא הוקצו לו תפקידים. לוחצים על הוספה ומזינים את כתובת האימייל של חשבון השירות.
- אם חשבון השירות כבר מופיע ברשימה Members, יש לו תפקידים קיימים. בוחרים את חשבון השירות ולוחצים על הכרטיסייה Roles.
מרחיבים את התפקיד. ליד חשבון השירות שרוצים לערוך, לוחצים על עריכה.
בוחרים בתפקיד Other > Cloud Service Mesh Client.
כדי להחיל את התפקיד על חשבון השירות, לוחצים על 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.