‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

הקצאת מישור בקרה מנוהל של Cloud Service Mesh ב-GKE

Cloud Service Mesh הוא רשת Service mesh שמנוהלת על ידי Google, וכל מה שצריך לעשות כדי להשתמש בה זה להפעיל אותה. ‫Google מטפלת באמינות, בשדרוגים, בהתאמה ובאבטחה בשבילכם.

בדף הזה מוסבר איך להשתמש ב-API של Fleet כדי להגדיר Cloud Service Mesh מנוהל באמצעות ממשקי Istio API.

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

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

פרויקט בענן
חשבון לחיוב ב-Cloud
קיבלתם את ההרשאות הנדרשות כדי להקצות את Cloud Service Mesh
הפעלתם את Workload Identity באשכולות ובמאגרי הצמתים.

דרישות

אחד או יותר אשכולות עם גרסה נתמכת של GKE, באחד מהאזורים הנתמכים.
שימו לב ש-Cloud Service Mesh מנוהל ומשתמש בערוצי הפצה של GKE כדי ליצור איזון בין יציבות לבין מהירות השדרוג. שינויים חדשים ברכיבים בתוך האשכול של Cloud Service Mesh (כולל CNI,‏ MDPC,‏ proxies ו-Istio CRDs) יושקו קודם באשכולות שרשומים לערוץ המהיר של GKE. לאחר מכן הן יועברו לערוץ הרגיל של GKE, ולבסוף לערוץ היציב של GKE, אחרי שיוכח שהן יציבות מספיק.
- השיטה המומלצת היא להקצות קבוצת משנה של אשכולות הצי בערוץ הפצה מוקדם יותר של GKE, כדי להבטיח שהם יקבלו עדכונים לרכיבי Cloud Service Mesh קודם.
- שירות Managed Cloud Service Mesh לא תומך בשינוי ערוצי ההפצה של GKE.
- אם תשנו את ערוץ ההפצה של GKE,‏ Cloud Service Mesh לא ימנע את הפעולה. ‫Cloud Service Mesh מעדכן אוטומטית את הרכיבים בתוך האשכול (CNI, ‏ MDPC, גרסת ה-proxy המוזרקת כברירת מחדל ו-CRD של Istio) כדי להתאים לערוץ ההפצה הנוכחי של GKE.
מוודאים שלקלאסטר יש מספיק קיבולת לרכיבים הנדרשים שמוגדרים בהתקנה של Cloud Service Mesh בקלאסטר.
- הפריסה mdp-controller במרחב השמות kube-system מבקשת cpu: 50m, memory: 128Mi.
- ה-daemonset‏ istio-cni-node במרחב השמות kube-system מבקש cpu: 100m,‏ memory: 100Mi בכל צומת.
מוודאים שמדיניות הארגון constraints/compute.disableInternetNetworkEndpointGroup מושבתת. אם המדיניות מופעלת, יכול להיות ש-ServiceEntry לא יפעל.
מוודאים שלמחשב הלקוח שממנו אתם מקצים את Cloud Service Mesh המנוהל יש קישוריות לרשת לשרת ה-API.
האשכולות צריכים להיות רשומים ב-Fleet. ההוראות כוללות את השלב הזה אם המכשיר לא נרשם לפני ההקצאה.
בפרויקט צריך להפעיל את התכונה Service Mesh fleet. ההוראות האלה מופיעות במדריך אם עדיין לא הפעלתם את האפשרות הזו.
‫GKE Autopilot נתמך רק בגרסה GKE 1.21.3 ואילך.
‫Cloud Service Mesh יכול להשתמש בכמה אשכולות GKE בסביבה של פרויקט יחיד ורשת יחידה, או בסביבה של כמה פרויקטים ורשת יחידה.
- אם מצטרפים לאשכולות שלא נמצאים באותו פרויקט, הם צריכים להיות רשומים באותו פרויקט מארח של Fleet, והאשכולות צריכים להיות מוגדרים יחד בVPC משותף באותה רשת.
- בסביבה מרובת אשכולות שמשויכת לפרויקט אחד, פרויקט ה-Fleet יכול להיות זהה לפרויקט האשכול. מידע נוסף על צי רכבים זמין במאמר סקירה כללית על צי רכבים.
- בסביבה מרובת פרויקטים, מומלץ לארח את ה-Fleet בפרויקט נפרד מפרויקטים של אשכולות. אם מדיניות הארגון וההגדרה הקיימת מאפשרות זאת, מומלץ להשתמש בפרויקט ה-VPC המשותף כפרויקט המארח של Fleet. מידע נוסף זמין במאמר בנושא הגדרת אשכולות עם VPC משותף.

התפקידים שנדרשים להתקנת Cloud Service Mesh

בטבלה הבאה מפורטים התפקידים שנדרשים להתקנת Cloud Service Mesh מנוהל.

שם התפקיד	מזהה תפקיד	Grant location	תיאור
אדמין GKE Hub	roles/gkehub.admin	פרויקט Fleet	גישה מלאה ל-GKE Hubs ולמשאבים קשורים.
אדמין של Service Usage	roles/serviceusage.serviceUsageAdmin	פרויקט Fleet	אפשרות להפעיל, להשבית ולבדוק את מצבי השירות, לבדוק פעולות ולצרוך מכסה וחיוב עבור פרויקט צרכן. ^{(הערה 1)}
אדמין של שירות CA‏ ^בטא	roles/privateca.admin	פרויקט Fleet	גישה מלאה לכל המשאבים של שירות CA. ^{(הערה 2)}

תפקידים שנדרשים להפעלת Cloud Service Mesh

בטבלה הבאה מתוארים התפקידים שנדרשים לחשבון השירות כדי להפעיל את Cloud Service Mesh מנוהל. אם פרויקטים של רשת או אשכול שונים מפרויקט המארח של Fleet, צריך לתת לחשבון השירות בפרויקט Fleet גישה לתפקידים האלה בפרויקטים האחרים.

שם התפקיד	מזהה תפקיד	Grant location	תיאור
סוכן שירות של Anthos Service Mesh	roles/anthosservicemesh.serviceAgent	פרויקט Fleet
סוכן שירות מנוהל ברמת הבקרה של רשת (מאמר שמתייחס לגרסה קודמת)	roles/meshcontrolplane.serviceAgent	פרויקט Fleet	זהו תפקיד מדור קודם שהיה חלק מהתקנות ישנות יותר של Cloud Service Mesh. אם בהתקנה שלכם יש את תפקיד השירות הזה, אתם יכולים להשאיר אותו כמו שהוא. בהתקנות חדשות אין צורך בתפקיד הזה.

מגבלות

מומלץ לעיין ברשימת התכונות הנתמכות והמגבלות של Cloud Service Mesh. חשוב לשים לב במיוחד לנקודות הבאות:

אין תמיכה בפודים של עומסי עבודה שפועלים עם hostNetwork: true.
אין תמיכה ב-IstioOperator API כי המטרה העיקרית שלו היא לשלוט ברכיבים בתוך האשכול.

הערה: עדיין אפשר להפעיל תכונות אופציונליות בלי להשתמש ב-IstioOperator API. אפשר לעיין במאמר הפעלה של תכונות אופציונליות ב-Cloud Service Mesh מנוהל.

- כדי להשתמש ב-Certificate Authority Service (CA Service), צריך להגדיר את Cloud Service Mesh לכל אשכול, ולא ניתן להשתמש בו כשמשתמשים בהגדרת ברירת המחדל של הצי ב-GKE Enterprise.

באשכולות GKE Autopilot, הגדרה חוצת-פרויקטים נתמכת רק ב-GKE 1.23 ואילך.
באשכולות GKE Autopilot, כדי להתאים למגבלת המשאבים של GKE Autopilot, בקשות המשאבים ומגבלות ברירת המחדל של ה-proxy מוגדרות ל-500m CPU ול-512MB זיכרון. אפשר לשנות את ערכי ברירת המחדל באמצעות הוספה בהתאמה אישית.
במקרה של אשכולות GKE Autopilot, יכול להיות שיוצגו אזהרות לגבי רכיבי Cloud Service Mesh ‏(DaemonSet has no nodes selected) עד שה-NodePool של האשכולות יתרחב.
במהלך תהליך ההקצאה של מישור בקרה מנוהל, מוקצים CRD של Istio באשכול שצוין. אם יש CRD של Istio באשכול, הם יוחלפו.
‫Istio CNI ו-Traffic Director לא תואמים ל-GKE Sandbox. לכן, Cloud Service Mesh מנוהל עם הטמעה של TRAFFIC_DIRECTOR לא תומך באשכולות שמופעל בהם GKE Sandbox.

לפני שמתחילים

נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

מגדירים את gcloud (גם אם משתמשים ב-Cloud Shell).

מאמתים באמצעות Google Cloud CLI, כאשר FLEET_PROJECT_ID הוא המזהה של פרויקט המארח של הצי. בדרך כלל, התיקייה FLEET_PROJECT_ID נוצרת כברירת מחדל ויש לה את אותו שם כמו לפרויקט.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
מעדכנים את הרכיבים:
```
       gcloud components update
```

מפעילים את ממשקי ה-API הנדרשים בפרויקט המארח של Fleet.
```
  gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID
```

הפעלת mesh.googleapis.com מפעילה את ממשקי ה-API הבאים:

API	מטרה	אפשר להשבית
`meshconfig.googleapis.com`	‫Cloud Service Mesh משתמש ב-Mesh Configuration API כדי להעביר נתוני הגדרה מהרשת שלכם אל Google Cloud. בנוסף, הפעלת Mesh Configuration API מאפשרת לכם לגשת לדפים של Cloud Service Mesh במסוף Google Cloud ולהשתמש ברשות האישורים של Cloud Service Mesh.	לא
`meshca.googleapis.com`	קשור לרשות האישורים של Cloud Service Mesh שמשמשת את Cloud Service Mesh מנוהל.	לא
`container.googleapis.com`	נדרש ליצירת אשכולות Google Kubernetes Engine‏ (GKE).	לא
`gkehub.googleapis.com`	נדרש כדי לנהל את הרשת כצי.	לא
`monitoring.googleapis.com`	נדרש כדי ללכוד טלמטריה עבור עומסי עבודה של רשתות Mesh.	לא
`stackdriver.googleapis.com`	נדרש כדי להשתמש בממשק המשתמש של השירותים.	לא
`opsconfigmonitoring.googleapis.com`	נדרש כדי להשתמש בממשק המשתמש של Services עבור אשכולות לא שלGoogle Cloud.	לא
`connectgateway.googleapis.com`	נדרשת כדי שמישור הבקרה המנוהל של Cloud Service Mesh יוכל לגשת לעומסי עבודה של רשתות.	כן*
`trafficdirector.googleapis.com`	הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס.	כן*
`networkservices.googleapis.com`	הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס.	כן*
`networksecurity.googleapis.com`	הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס.	כן*

אזהרה: השבתה של connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com או networksecurity.googleapis.com גורמת להפסקת הפעולה של מישור הבקרה המנוהל של Cloud Service Mesh. אם הצי לא משתמש ב-Cloud Service Mesh מנוהל באף אשכול, אפשר להשבית את ממשקי ה-API האלה.

הגדרת Cloud Service Mesh מנוהל

השלבים הנדרשים להקצאת Cloud Service Mesh מנוהל באמצעות Fleet API תלויים בהעדפה שלכם: הפעלה לכל אשכול או הפעלה כברירת מחדל לאשכולות חדשים של Fleet.

הגדרה לכל אשכול

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

הפעלת התכונה Cloud Service Mesh fleet

מפעילים את התכונה mesh בפרויקט הצי. אם אתם מתכננים לרשום כמה אשכולות, תצטרכו להפעיל את התכונה Cloud Service Mesh fleet רק פעם אחת, כי היא פועלת ברמת ה-fleet.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

רישום אשכולות ב-Fleet

רישום של אשכול GKE באמצעות Fleet Workload Identity. הדגל --location הוא אזור או אזור מחשוב (כמו us-central1-a או us-central1) של האשכול.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

מוודאים שהאשכול רשום:

gcloud container fleet memberships list --project FLEET_PROJECT_ID

פלט לדוגמה:

NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

חשוב לרשום את MEMBERSHIP_NAME, כי תצטרכו אותו כשתפעילו ניהול אוטומטי.

אם הפרויקט של הרשת של האשכול שונה מהפרויקט המארח של צי, (לדוגמה, אם אתם משתמשים בVPC משותף), אתם צריכים לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט הצי לגשת לפרויקט הרשת. צריך לעשות את זה רק פעם אחת לפרויקט של הרשת.

נותנים לחשבונות שירות בפרויקט הצי גישה לפרויקט הרשת:
```
 gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
```
אם הפרויקט של האשכול שונה מהפרויקט המארח של צי האשכולות, צריך לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט של צי האשכולות לגשת לפרויקט של האשכול, ולהפעיל את ממשקי ה-API הנדרשים בפרויקט של האשכול.

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

מעניקים לחשבונות שירות בפרויקט הצי הרשאה לגשת לפרויקט האשכול:
```
 gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent
```
מפעילים את Mesh API בפרויקט של האשכול:
```
 gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
```

הגדרת Certificate Authority Service (אופציונלי)

אם הפריסה של רשת השירות דורשת את Certificate Authority Service (שירות רשות האישורים), צריך לפעול לפי ההוראות במאמר הגדרת Certificate Authority Service עבור Cloud Service Mesh מנוהל כדי להפעיל אותו עבור הצי. חשוב להשלים את כל השלבים לפני שעוברים לקטע הבא.

הפעלת ניהול אוטומטי

מריצים את הפקודה הבאה כדי להפעיל ניהול אוטומטי:

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

where:

‫MEMBERSHIP_NAME הוא שם החברות שמופיע כשאימתתם שהאשכול רשום ב-Fleet.
‫MEMBERSHIP_LOCATION הוא המיקום של המינוי (אזור או global).

אם יצרתם לאחרונה את החברות באמצעות הפקודה במדריך הזה, זה צריך להיות האזור של האשכול שלכם. אם יש לכם אשכול אזורי, צריך להשתמש באזור שמתאים לאזור של האשכול. לדוגמה, אם יש לכם אשכול אזורי ב-us-central1-c, צריך להשתמש בערך us-central1.

הערך הזה יכול להיות global אם נרשמתם לפני מאי 2023, או אם ציינתם את המיקום global כשנרשמתם למועדון. אפשר לבדוק את המיקום של המינוי ב-gcloud container fleet memberships list --project FLEET_PROJECT_ID.

ממשיכים אל אימות הקצאת משטח הבקרה.

הגדרה ל-Fleet

כדי להפעיל את Cloud Service Mesh מנוהל כהגדרת ברירת מחדל בצי, צריך להפעיל את מהדורת Google Kubernetes Engine‏ (GKE) Enterprise. המשמעות היא שבכל אשכול GKE חדש ב-Google Cloud שנרשם במהלך יצירת האשכול, יופעל ניהול של Cloud Service Mesh באשכול. מידע נוסף על הגדרות ברירת המחדל של צי הרכבים זמין במאמר ניהול תכונות ברמת צי הרכבים.

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

הפעלת Cloud Service Mesh מנוהל כהגדרת ברירת מחדל לצי ורישום אשכולות לצי במהלך יצירת האשכולות תומכת רק ב-Mesh CA. אם אתם רוצים להשתמש ב-Certificate Authority Service, מומלץ להפעיל אותו לכל אשכול.

כדי להפעיל ברירות מחדל ברמת הצי ל-Cloud Service Mesh מנוהל:

המסוף

נכנסים לדף Feature Manager במסוף Google Cloud .

מעבר אל Feature Manager
בחלונית Service Mesh, לוחצים על Configure (הגדרה).
בודקים את ההגדרות שמועברות בירושה לכל האשכולות החדשים שיוצרים במסוף Google Cloud ונרשמים ל-Fleet.

הערה: ההגדרות האלה הן הגדרות של GKE שנדרשות לשימוש ב-Cloud Service Mesh.
כדי להחיל את ההגדרות האלה, לוחצים על הגדרה.
בתיבת הדו-שיח לאישור, לוחצים על אישור.
כדי להפעיל את Cloud Service Mesh המנוהל באשכולות קיימים, צריך לסנכרן את האשכולות הקיימים עם הגדרות ברירת המחדל:
1. ברשימה Clusters in the fleet, בוחרים את האשכולות שרוצים לסנכרן.
2. לוחצים על סנכרון להגדרות של Fleet ואז על אישור בתיבת הדו-שיח לאישור שמופיעה. הפעולה הזו יכולה להימשך כמה דקות.

gcloud

כדי להגדיר ברירות מחדל ברמת הצי באמצעות Google Cloud CLI, צריך להגדיר את ההגדרות הבאות:

הגדרות ברמת כלל המכשירים בארגון

יוצרים קובץ mesh.yaml שמכיל רק את השורה management: automatic:
```
echo "management: automatic" > mesh.yaml
```

מפעילים את Cloud Service Mesh בצי:

gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

אם הודעת השגיאה הבאה מופיעה, צריך להפעיל את GKE Enterprise.

ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

הגדרות ברמת הרשת
- אם הפרויקט של הרשת שונה מהפרויקט המארח של צי הרכבים (לדוגמה, אם אתם משתמשים בVPC משותף), אתם צריכים לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט צי הרכבים לגשת לפרויקט הרשת. צריך לעשות את זה רק פעם אחת לפרויקט של הרשת.
  
  נותנים לחשבונות שירות בפרויקט הצי גישה לפרויקט הרשת:
```
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
הגדרות ברמת האשכול
- כשמוכנים ליצור אשכולות לשימוש עם Cloud Service Mesh, יוצרים אותם ורושמים אותם בשלב אחד באמצעות Google Cloud CLI כדי להשתמש בהגדרת ברירת המחדל. לדוגמה:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  כדי לקבל את מספר הפרויקט של פרויקט Fleet, מריצים את הפקודה הבאה:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  הדגל --location הוא אזור או אזור מחשוב (כמו us-central1-a או us-central1) של האשכול.
- אם הפרויקט של האשכול שונה מהפרויקט המארח של צי האשכולות, צריך לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט של צי האשכולות לגשת לפרויקט של האשכול, ולהפעיל את ממשקי ה-API הנדרשים בפרויקט של האשכול. צריך לעשות את זה רק פעם אחת לכל פרויקט של אשכול.
  
  מעניקים לחשבונות שירות בפרויקט Fleet הרשאה לגשת לפרויקט האשכול:
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
  מפעילים את Mesh API בפרויקט של האשכול:
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  מחליפים את CLUSTER_PROJECT_ID במזהה הייחודי של פרויקט האשכול. אם יצרתם את האשכול באותו פרויקט שבו יצרתם את ה-Fleet, אז CLUSTER_PROJECT_ID זהה ל-FLEET_PROJECT_ID.

ממשיכים אל אימות הקצאת מישור הבקרה.

תמיכה ב-Terraform

‫Cloud Service Mesh תומך בהקצאת משאבים באמצעות Terraform דרך מודול החברות בתכונה GKEHub.

הוראות מפורטות זמינות במדריך להקצאת משאבים של Service mesh מנוהל.

אימות הקצאת מישור הבקרה

אחרי כמה דקות, מוודאים שסטטוס מישור הבקרה הוא ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

הפלט אמור להיראות כך:

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

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

הגדרת `kubectl` כך שיצביע על האשכול

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

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

הערה: שער כניסה לא נפרס אוטומטית עם מישור הבקרה. הפרדה בין הפריסה של שער הכניסה (ingress) לבין מישור הבקרה מאפשרת לכם לנהל את השערים בסביבת ייצור. אם רוצים להשתמש בשער כניסה או בשער יציאה של Istio, אפשר לעיין במאמר פריסת שערים. אם רוצים להשתמש ב-Kubernetes Gateway API, אפשר לעיין במאמר הכנת Gateway ל-Mesh. כדי להפעיל תכונות אופציונליות אחרות, אפשר לעיין במאמר בנושא הפעלת תכונות אופציונליות ב-Cloud Service Mesh.

מישור נתונים מנוהל

אם אתם משתמשים ב-Cloud Service Mesh מנוהל, Google מנהלת באופן מלא את השדרוגים של ה-proxy שלכם.

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

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

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

מישור הנתונים המנוהל משדרג את ה-proxy על ידי הוצאת פודים שמופעלות בהם גרסאות קודמות של ה-proxy. ההוצאות מתבצעות בהדרגה, בהתאם לתקציב ההפרעות של ה-Pod ולשליטה בקצב השינוי.

כשפורסים גרסאות חדשות של מישור הנתונים של Cloud Service Mesh

מישור נתונים מנוהל	אירועים שמפעילים פריסה חדשה של רמת הנתונים ב-Cloud Service Mesh
מישור נתונים מנוהל	עדכונים פעילים של Cloud Service Mesh באופן פעיל, כשיש גרסאות חדשות.¹	יצירת Pod חדש כשאתם או התכונה 'התאמה אופקית של קבוצות Pod לעומס' פורסים עומסי עבודה חדשים	חלונות זמן לתחזוקה ב-GKE כשצמתים מוחלפים במהלך חלון זמן לתחזוקה ב-GKE
מופעל
מושבת

‫¹עדכונים פעילים של Cloud Service Mesh מחליפים באופן אוטומטי את Pods בעומסי עבודה, למעט StatefulSets,‏ Jobs,‏ DaemonSets ו-Pods שהוחדרו באופן ידני. עדכונים פעילים של Cloud Service Mesh מכבדים תקציבי שיבוש של Pod.

עדכונים פעילים בעדיפות נמוכה מתבצעים בחלונות התחזוקה של GKE.
עדכונים פעילים בעדיפות גבוהה יכולים להתבצע ברגע ש-Cloud Service Mesh מאפשר אותם לאשכול, בלי קשר לחלונות התחזוקה של GKE. בדרך כלל יש לפחות CVE אחד שמשויך לעדכונים פעילים בעדיפות גבוהה.

אם אתם לא רוצים לנהל בעצמכם את מחזור החיים של מישור הנתונים של Cloud Service Mesh, ועומסי העבודה שלכם יכולים לסבול החלפה של Pods בכל שלב, כדאי להפעיל את מישור הנתונים המנוהל.

אם רוצים שליטה מלאה על הזמן של כל העדכונים של מישור הנתונים של Cloud Service Mesh, צריך להשבית את מישור הנתונים המנוהל.

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

מגבלות

מישור הנתונים המנוהל לא מנהל את הדברים הבאים:

פודים שלא הוזרקו
הוספת pods באופן ידני
תעסוקה
StatefulSets
DaemonSets

השבתה של מישור הנתונים המנוהל (אופציונלי)

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

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

איתור כל העדכונים של מישור הבקרה:
```
kubectl get controlplanerevisions -n istio-system
```
כדי לשנות את ההערה:
```
kubectl annotate --overwrite controlplanerevision CONTROL_PLANE_REVISION_NAME -n istio-system mesh.cloud.google.com/proxy='{"managed":"false"}'
```
חוזרים על השלב הזה לכל עדכון של מישור הבקרה.

מחליפים את CONTROL_PLANE_REVISION_NAME בפלט מהפקודה הקודמת.

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

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

כדי להשבית את מישור הנתונים המנוהל עבור פוד:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

הפעלת חלונות תחזוקה למישור הנתונים המנוהל

אם הגדרתם חלון זמן לתחזוקה ב-GKE, השדרוגים הפעילים יתחילו בתחילת חלון זמן לתחזוקה הבא שזמין וימשיכו ללא הפסקה עד שכל ה-Pods המנוהלים יעודכנו (בדרך כלל 12 שעות). חלון הזמן לתחזוקה לא חל על השקות שקשורות ל-CVE.

‫Cloud Service Mesh משתמש בחלון זמן לתחזוקה של GKE כדי להתאים את עצמו ל-GKE.

הפעלת התראות על תחזוקה במישור הנתונים המנוהל

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

כדי להביע הסכמה לקבלת התראות על תחזוקה של מישור הנתונים המנוהל:

עוברים לדף תקשורת.

כניסה לדף Communication
בשורה Cloud Service Mesh Upgrade, בעמודה Email, לוחצים על לחצן הבחירה כדי להפעיל את ההתראות על תחזוקה (ON).

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

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

בדוגמה הבאה מוצגת הודעה אופיינית על תחזוקה של מישור נתונים מנוהל:

Subject Line: Upcoming upgrade for your Cloud Service Mesh cluster "<location/cluster-name>"

שלום, משתמש Cloud Service Mesh,

רכיבי Cloud Service Mesh באשכול ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) מתוזמנים לשדרוג בתאריך ${scheduled_date_human_readable} בשעה ${scheduled_time_human_readable}.

בהערות המוצר (https://cloud.google.com/service-mesh/docs/release-notes) מוסבר על העדכון החדש.

אם עבודות התחזוקה יבוטלו, נעדכן אותך באימייל נוסף.

בברכה,

צוות Cloud Service Mesh

‫(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 שלחנו אליך את ההודעה הזו כדי למסור לך עדכון חשוב בקשר לשינויים ב-Google Cloud Platform או בחשבון שלך. לא רוצה לקבל התראות בקשר לחלונות זמנים לתחזוקה? אפשר תמיד לשנות את ההעדפות שלך: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

הגדרת גילוי נקודות קצה (רק בהתקנות מרובות אשכולות)

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

לפני שממשיכים, מוודאים ש-Cloud Service Mesh מוגדר בכל אשכול.

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

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

תמיכה בקבוצה של נקודות קצה ברשת

‫Cloud Service Mesh עם TRAFFIC_DIRECTOR הטמעה של מישור הבקרה דורש קבוצות של נקודות קצה ברשת (NEGs) כדי לייצג נקודות קצה של שירותים ב-GKE.

יצירה אוטומטית של NEG

כשמפעילים את Cloud Service Mesh עם מישור הבקרה של Traffic Director, הרשת מוסיפה באופן אוטומטי את ההערה cloud.google.com/neg לשירותי Kubernetes. כך בקר ה-NEG של GKE יכול ליצור קבוצות NEG עצמאיות לנקודות הקצה של השירות.

קבוצות ה-NEG האלה חיוניות למישור הבקרה כדי לגלות את נקודות הקצה של השירות ולתכנת את הלקוחות כך שיגלו אותן.

מה ישתנה בחשבון

הערות אוטומטיות: כל השירותים (כולל סוגי ClusterIP, NodePort ו-LoadBalancer) במרחב שמות שמופעל בו Mesh מקבלים הערה אוטומטית עם ההערה cloud.google.com/neg.
סטטוס של קבוצת נקודות קצה ברשת: הערה cloud.google.com/neg-status נוספת גם לשירותים שלכם, ומספקת מידע על קבוצות נקודות הקצה ברשת שנוצרו.
התנהגות נדרשת: האוטומציה הזו חיונית כדי שהשירותים יפעלו במישור הבקרה המודרני, ואי אפשר להשבית אותה בשירותי רשת.

אינטראקציה עם כלי CI/CD

אם אתם משתמשים בכלים של CI/CD כדי לנהל את השירותים, יכול להיות שהכלים האלה יזהו את ההערות האוטומטיות כשינוי בהגדרות וינסו להסיר אותן.

כדי למנוע בעיות, צריך להגדיר את כלי ה-CI/CD כך שיתעלמו מההערות cloud.google.com/neg ו-cloud.google.com/neg-status. מידע נוסף ודוגמאות מופיעים במאמר פתרון בעיות ב-NEGs באמצעות כלים ל-CI/CD.

פריסת אפליקציות

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

מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.

מנוהל (TD)

מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

מנוהל (Istiod)

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

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

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

מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
```
kubectl -n istio-system get controlplanerevision
```
הפלט אמור להיראות כך:
```
NAME                AGE
asm-managed-rapid   6d7h
```
הערה: אם ברשימה שלמעלה מופיעות שתי גרסאות של מישור הבקרה, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.

בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.

החלת תווית הגרסה על מרחב השמות:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

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

  kubectl get namespace -L istio-injection

פלט לדוגמה:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

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

התאמה אישית של ההטמעה (אופציונלי)

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

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

לדוגמה, ההגדרה הבאה משנה מגוון הגדרות, כולל הפחתת בקשות המעבד, הוספת נקודת טעינה של נפח והוספת וו preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

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

ב-Kubernetes, צריך להגדיר את השדה image לפני הפעלת ההזרקה. אפשר להגדיר תמונה ספציפית שתחליף את תמונת ברירת המחדל, אבל מומלץ להגדיר את image ל-auto. כך, כלי ה-injector של ה-sidecar יבחר באופן אוטומטי את התמונה לשימוש.
חלק מהשדות ב-containers תלויים בהגדרות קשורות. לדוגמה, הערך חייב להיות קטן ממגבלת השימוש במעבד או שווה לה. אם שני השדות לא מוגדרים בצורה תקינה, יכול להיות שהפוד לא יופעל.
ב-Kubernetes אפשר להגדיר גם requests וגם limits למשאבים ב-Pod spec. ב-GKE Autopilot נלקח בחשבון רק requests. מידע נוסף זמין במאמר בנושא הגדרת מגבלות משאבים ב-Autopilot.

בנוסף, אפשר להגדיר שדות מסוימים באמצעות הערות ב-Pod, אבל מומלץ להשתמש בגישה שלמעלה כדי להתאים אישית את ההגדרות. חשוב לשים לב במיוחד להערות הבאות:

ב-GKE Standard, אם ההגדרה sidecar.istio.io/proxyCPU מוגדרת, חשוב להגדיר באופן מפורש את sidecar.istio.io/proxyCPULimit. אחרת, מגבלת המעבד של ה-sidecar תוגדר ללא הגבלה.
ב-GKE Standard, אם sidecar.istio.io/proxyMemory מוגדר, צריך להגדיר באופן מפורש את sidecar.istio.io/proxyMemoryLimit. אחרת, מגבלת הזיכרון של ה-sidecar תוגדר כבלתי מוגבלת.
ב-GKE Autopilot, הגדרת משאבים requests ו-limits באמצעות הערות עשויה להוביל להקצאת יתר של משאבים. כדי להימנע מכך, אפשר להשתמש בגישה של תבנית תמונה. דוגמאות לשינוי משאבים ב-Autopilot

לדוגמה, אפשר לראות את ההערה על מקורות המידע הבאים:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

העברת אפליקציות ל-Cloud Service Mesh מנוהל

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

החלפת התווית הנוכחית של מרחב השמות. השלבים תלויים בהטמעה של מישור הבקרה.

מנוהל (TD)

מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

מנוהל (Istiod)

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

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
```
kubectl -n istio-system get controlplanerevision
```
הפלט אמור להיראות כך:
```
NAME                AGE
asm-managed-rapid   6d7h
```
הערה: אם ברשימה שלמעלה מופיעות שתי גרסאות של מישור הבקרה, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.

בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.

החלת תווית הגרסה על מרחב השמות:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

מבצעים שדרוג מתגלגל של פריסות במרחב השמות:
```
kubectl rollout restart deployment -n NAMESPACE
```
בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים הקודמים לכל מרחב שמות.
אם פרסתם את האפליקציה בהגדרה של כמה אשכולות, צריך לשכפל את ההגדרה של Kubernetes ו-Istio בכל האשכולות, אלא אם רוצים להגביל את ההגדרה הזו רק לקבוצת משנה של אשכולות. ההגדרה שחלה על אשכול מסוים היא מקור המידע האמין לאשכול הזה.

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

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

מחיקת מישור הבקרה הישן

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

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

אם השתמשתם ב-istioctl kube-inject במקום בהזרקה אוטומטית, או אם התקנתם שערים נוספים, כדאי לבדוק את המדדים של מישור הבקרה ולוודא שמספר נקודות הקצה המחוברות הוא אפס.

הוחזר למצב קודם

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

מעדכנים את עומסי העבודה כך שיוזרקו עם הגרסה הקודמת של רמת הבקרה. בפקודה הבאה, ערך הגרסה asm-191-1 משמש רק כדוגמה. מחליפים את הערך לדוגמה בתווית הגרסה של מישור הבקרה הקודם.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההחדרה, כך שלפרוקסי תהיה הגרסה הקודמת:
```
kubectl rollout restart deployment -n NAMESPACE
```

מישור הבקרה המנוהל יתבצע אוטומטית בהתאמה ל-0 ולא ישתמש בשום משאב כשלא יהיה בשימוש. ה-webhooks וההקצאה של משאבים לשינוי יישארו ולא ישפיעו על התנהגות האשכול.

שער התשלומים מוגדר עכשיו לגרסה asm-managed. כדי לבצע Rollback, מריצים מחדש את פקודת ההתקנה של Cloud Service Mesh, שתפרוס מחדש את השער ותחזיר אותו למישור הבקרה בתוך האשכול:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

אם הפעולה תצליח, הפלט יהיה:

deployment.apps/istio-ingressgateway rolled back

הסרת Cloud Service Mesh

מישור הבקרה המנוהל מתבצע באופן אוטומטי עד לאפס כשאין מרחבי שמות שמשתמשים בו. הוראות מפורטות זמינות במאמר הסרת Cloud Service Mesh.

הקצאת מישור בקרה מנוהל של Cloud Service Mesh ב-GKE

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

דרישות

התפקידים שנדרשים להתקנת Cloud Service Mesh

תפקידים שנדרשים להפעלת Cloud Service Mesh

מגבלות

לפני שמתחילים

הפעלת mesh.googleapis.com מפעילה את ממשקי ה-API הבאים:

הגדרת Cloud Service Mesh מנוהל

הגדרה לכל אשכול

הפעלת התכונה Cloud Service Mesh fleet

רישום אשכולות ב-Fleet

הגדרת Certificate Authority Service (אופציונלי)

הפעלת ניהול אוטומטי

הגדרה ל-Fleet

המסוף

gcloud

תמיכה ב-Terraform

אימות הקצאת מישור הבקרה

הגדרת kubectl כך שיצביע על האשכול

מישור נתונים מנוהל

כשפורסים גרסאות חדשות של מישור הנתונים של Cloud Service Mesh

מגבלות

השבתה של מישור הנתונים המנוהל (אופציונלי)

הפעלת חלונות תחזוקה למישור הנתונים המנוהל

הפעלת התראות על תחזוקה במישור הנתונים המנוהל

הגדרת גילוי נקודות קצה (רק בהתקנות מרובות אשכולות)

תמיכה בקבוצה של נקודות קצה ברשת

יצירה אוטומטית של NEG

מה ישתנה בחשבון

אינטראקציה עם כלי CI/CD

פריסת אפליקציות

מנוהל (TD)

מנוהל (Istiod)

התאמה אישית של ההטמעה (אופציונלי)

העברת אפליקציות ל-Cloud Service Mesh מנוהל

מנוהל (TD)

מנוהל (Istiod)

מחיקת מישור הבקרה הישן

הוחזר למצב קודם

הסרת Cloud Service Mesh

הגדרת `kubectl` כך שיצביע על האשכול