הכנה להגדרת Cloud Service Mesh עם שירותי gRPC ללא proxy

ההגדרה של Cloud Service Mesh כוללת כמה שלבים. במאמר הזה מתואר השלב הראשון: הוראות להכנה להגדרת Cloud Service Mesh עם אפליקציות gRPC ללא proxy. המסמך הזה רלוונטי כשמשתמשים בממשקי API של איזון עומסים. עם זאת, מומלץ מאוד להשתמש בממשקי API לניתוב שירותים. השלבים האחרים מוסברים במדריכים הספציפיים לפלטפורמה שמפורטים בקטע המשך תהליך ההגדרה בהמשך המאמר.

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

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

כדי להכין את הסביבה, צריך לבצע את המשימות הבאות:

  1. מפעילים את החיוב.
  2. נותנים את ההרשאות הנדרשות.
  3. מפעילים בפרויקט את Traffic Director API.
  4. מוודאים שלחשבון השירות יש הרשאות מספיקות לגישה ל-Traffic Director API.

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

הפעלת החיוב

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

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

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

אחרת, צריך להקצות את כל תפקידי ה-IAM שמופיעים בטבלה הבאה. אם יש לכם את התפקידים האלה, יש לכם גם את ההרשאות שמשויכות אליהם, כמו שמתואר במסמכי העזרה של 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)
אם משתמשים ב-Pods, צריך ליצור ולשנות אשכול GKE. אדמין של אשכול
(roles/container.clusterAdmin)
מאפשרת גישה לחשבונות שירות. משתמש בחשבון שירות
(roles/iam.serviceAccountUser

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

ב-xDS v3, צריך להעניק לחשבון השירות שמשמש את לקוחות gRPC של Cloud Service Mesh את התפקיד 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

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

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

במכונה וירטואלית ב-Compute Engine, לקוח xDS משתמש בחשבון השירות שהוקצה למכונה הווירטואלית.

נדרשות ההרשאות הבאות. גרסת פרוטוקול xDS מצוינת בקובץ האתחול. יש תמיכה רק ב-xDS v3.

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

כשמשתמשים ב-xDS v3, לחשבון השירות שבו משתמשות אפליקציות gRPC צריכות להיות ההרשאות trafficdirector.networks.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: כתובת האימייל שמשויכת לחשבון השירות

בהמשך מפורט תהליך כללי להגדרת אפליקציות gRPC בלי שרת Proxy ב-Service mesh:

  1. מעדכנים את לקוחות gRPC לגרסה העדכנית של gRPC, עם הטלאי האחרון.
  2. כשיוצרים ערוץ ומציינים קובץ bootstrap של Cloud Service Mesh, צריך לעדכן את סכימת פותר השמות של gRPC של הלקוחות.
  3. הגדרת משאבי Cloud Service Mesh ו-Cloud Load Balancing.

במסמך הזה מופיע מידע שיעזור לכם להשלים את שני השלבים הראשונים. תהליך ההגדרה שבו משתמשים בשלב 3 תלוי בשאלה אם הפריסה משתמשת במכונות וירטואליות של Compute Engine או בקבוצות של נקודות קצה ברשת (NEGs) של GKE.

גרסאות ושפות נתמכות של gRPC

‫gRPC הוא פרויקט קוד פתוח, ותמיכה בגרסאות שלו מתוארת בשאלות הנפוצות בנושא gRPC. מומלץ להשתמש בגרסה העדכנית ביותר של gRPC כדי לצמצם את הסיכון לפרצות אבטחה ידועות. כך גם תוכלו לוודא שלאפליקציות שלכם תהיה גישה לתכונות העדכניות ביותר שנתמכות על ידי Cloud Service Mesh. רשימת התכונות של Service mesh שנתמכות בהטמעות ובגרסאות שונות של gRPC זמינה ב-GitHub. לקבלת רשימה של שפות gRPC ותכונות שנתמכות ב-Cloud Service Mesh ובשירותי gRPC בלי שרת Proxy, אפשר לעיין במאמר תכונות של Cloud Service Mesh.

‫Cloud Service Mesh שומר על תאימות לגרסאות עדכניות ונתמכות של gRPC, ומשתדל לשמור על תאימות לגרסאות gRPC שגילן פחות משנה, בכפוף לתנאים ולהגבלות של הפלטפורמה.Google Cloud

עדכון של לקוחות gRPC

מעדכנים את ספריית gRPC באפליקציה לגרסה שתומכת בתכונות שנדרשות לכם. פרטים נוספים מופיעים בסעיף הקודם.

מוסיפים את xDS name-resolver כתלות לאפליקציות gRPC. הדרישות לכל שפה ב-Java וב-Go מפורטות בקטעים הבאים. אין דרישות נוספות לשפות אחרות.

דרישות ל-Java

ב-Java, אם משתמשים ב-Gradle, מוסיפים את התלות grpc-xds לקובץ build.gradle. מחליפים את LATEST_GRPC_VERSION בגרסה האחרונה של gRPC.

dependencies {
  runtimeOnly 'io.grpc:grpc-xds:LATEST_GRPC_VERSION'
}

אם משתמשים ב-Maven, מוסיפים את הקוד הבא לקטע <dependencies> של pom.xml. מחליפים את LATEST_GRPC_VERSION בגרסה העדכנית של gRPC.

    <dependency>
      <groupId>io.grpc</groupId>
      <artifactId>grpc-xds</artifactId>
      <version>LATEST_GRPC_VERSION</version>
      <scope>runtime</scope>
    </dependency>

דרישות ל-Go

אם משתמשים ב-Go, מייבאים את חבילת xds Go.

הגדרת פותר שמות gRPC לשימוש ב-xds

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

כוללים את שם השירות שמשמש ב-URI של היעד בהגדרה של Cloud Service Mesh. לדוגמה, ב-Java, יוצרים את הערוץ באמצעות המבנה הזה, שבו שם השירות הוא helloworld:

ManagedChannelBuilder.forTarget("xds:///helloworld[:PORT_NUMBER]")

יצירה והגדרה של קובץ bootstrap

סכמת הפותר xds אומרת לאפליקציית gRPC להתחבר ל-Cloud Service Mesh כדי לקבל מידע על ההגדרות של שירות היעד. לכן, צריך לבצע את הפעולות הבאות:

  • יוצרים קובץ bootstrap, כמו בדוגמה הבאה. הקובץ הזה אומר ל-gRPC להתחבר לשרת xDS ‏ (Cloud Service Mesh) כדי לקבל את ההגדרה של שירותים ספציפיים.
  • מגדירים משתנה סביבה בשם GRPC_XDS_BOOTSTRAP, כששם קובץ האתחול הוא הערך של משתנה הסביבה.

הוראות ההגדרה כוללות דוגמאות שמראות איך ליצור את קובץ ה-bootstrap. לנוחיותכם, אתם יכולים להשתמש בגרסה העדכנית של Cloud Service Mesh gRPC bootstrap generator.

צריך לכלול לצד האפליקציה קובץ bootstrap שמכיל את המידע שנדרש כדי להתחבר ל-Cloud Service Mesh. קובץ bootstrap לדוגמה נראה כך:

{
  "xds_servers": [
    {
      "server_uri": "trafficdirector.googleapis.com:443",
      "channel_creds": [
        {
          "type": "google_default"
        }
      ],
      "server_features": ["xds_v3"]
    }
  ],
  "node": {
    "id": "projects/123456789012/networks/default/nodes/b7f9c818-fb46-43ca-8662-d3bdbcf7ec18",
    "metadata": {
      "TRAFFICDIRECTOR_NETWORK_NAME": "default"
    },
    "locality": {
      "zone": "us-central1-a"
    }
  }
}

בטבלה הבאה מוסבר על השדות בקובץ האתחול.

שדה הערך והתיאור
xds_servers רשימה של שרתי xDS. פרוטוקול gRPC משתמש רק בשרת הראשון ברשימה.
server_uri צריך לציין לפחות אחד. פרוטוקול gRPC מנסה להתחבר רק לשרת ה-xDS הראשון ברשימה של xds_servers. ערך ברירת המחדל הוא trafficdirector.googleapis.com:443.
channel_creds פרטי הכניסה לשימוש בשרת xDS.
type משתמשים בערך google_default. למידע נוסף על האופן שבו מתקבלים פרטי הכניסה, אפשר לקרוא את המאמר הסבר על השימוש ב-Application Default Credentials.
server_features רשימה של תכונות שהשרת תומך בהן, כמו תמיכה ב-xDS v3. ערך ברירת המחדל הוא ריק.
node מידע על הלקוח שמתחבר לשרת xDS.
id

הערך id צריך להיות בפורמט הבא, כמו שמוצג בדוגמה הקודמת:

projects/PROJECT_NUMBER/networks/NETWORK_NAME/nodes/ID

צריך לספק מחרוזת ייחודית כערך של ID. כך אפשר לזהות את לקוח gRPC שמתחבר ל-Cloud Service Mesh.
metadata מידע ספציפי לשרת xDS.
TRAFFICDIRECTOR_NETWORK_NAME אם השדה ריק או לא צוין, הערך שמוגדר הוא default.
locality האזור Google Cloud שבו פועל לקוח gRPC.

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

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