הצגת מסמכי עזרה מארכיון בנושא Service Mesh בגרסה 1.21.

גרסאות זמינות

הגרסה האחרונה של Cloud Service Mesh
ארכיון של Cloud Service Mesh 1.26
ארכיון של Cloud Service Mesh 1.24
ארכיון של Cloud Service Mesh 1.24
ארכיון של Cloud Service Mesh 1.23
ארכיון של Cloud Service Mesh 1.22
ארכיון של Cloud Service Mesh 1.21
ארכיון של Cloud Service Mesh 1.20
ארכיון של Anthos Service Mesh 1.19

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הקצאת מישור בקרה מנוהל של 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 בקלאסטר.
- הפריסה 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. חשוב לשים לב במיוחד לנקודות הבאות:

אין תמיכה ב-IstioOperator API כי המטרה העיקרית שלו היא לשלוט ברכיבים בתוך האשכול.

הערה: עדיין אפשר להפעיל תכונות אופציונליות בלי להשתמש ב-IstioOperator API. אפשר לעיין במאמר הפעלת תכונות אופציונליות ב-Cloud Service Mesh מנוהל. אפשר גם להשתמש בכלי ההעברה שכלול ב-asmcli כדי להמיר באופן אוטומטי תכונות אופציונליות אחרות של IstioOperator כך שיהיו תואמות למישור הבקרה המנוהל. מידע נוסף זמין במאמר בנושא העברה מ-IstioOperator.
כדי להשתמש ב-Certificate Authority Service (CA Service), צריך להגדיר את Cloud Service Mesh לכל אשכול. אי אפשר להשתמש ב-CA Service כשמשתמשים בהגדרת ברירת המחדל של הצי ב-GKE Enterprise.
באשכולות GKE Autopilot, הגדרה חוצת-פרויקטים נתמכת רק ב-GKE 1.23 ואילך.
באשכולות GKE Autopilot, כדי להתאים למגבלת המשאבים של GKE Autopilot, בקשות המשאבים ומגבלות ברירת המחדל של ה-proxy מוגדרות ל-500m CPU ול-512MB זיכרון. אפשר לשנות את ערכי ברירת המחדל באמצעות הוספה בהתאמה אישית.
במהלך תהליך ההקצאה של מישור בקרה מנוהל, מוקצים 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 או הפעלה לכל אשכול.

הגדרה ל-Fleet

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

הפעלת 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.
כדי להחיל את ההגדרות האלה, לוחצים על הגדרה.
בתיבת הדו-שיח לאישור, לוחצים על אישור.
אופציונלי: סנכרון של אשכולות קיימים עם הגדרות ברירת המחדל:
1. ברשימה Clusters in the fleet, בוחרים את האשכולות שרוצים לסנכרן. אפשר לבחור רק אשכולות שמותקן בהם Cloud Service Mesh.
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.

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

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

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

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

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

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.

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

אחרי כמה דקות, מוודאים שסטטוס מישור הבקרה הוא 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 מנהלת באופן מלא את השדרוגים של ה-proxies שלכם, אלא אם משביתים את האפשרות הזו.

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

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

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

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

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

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

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

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

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

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

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. כשההתראות מופעלות, הן נשלחות לפחות יומיים לפני פעולת השדרוג.

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

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

כניסה לדף 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.

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

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

מנוהל (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

בשלב הזה, הגדרתם בהצלחה את 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

מגבלות

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

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

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

הגדרה ל-Fleet

המסוף

gcloud

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

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

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

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

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

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

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

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

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

הפעלת התראות לגבי פעולות תחזוקה

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

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

מנוהל (TD)

מנוהל (Istiod)

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

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

מנוהל (TD)

מנוהל (Istiod)

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

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

הסרת Cloud Service Mesh

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