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

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

עדכוני הגדרות למודרניזציה

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

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

Multi-cluster
הפעלת איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE
הפעלת CNI מנוהל
שימוש בינארי לא סטנדרטי ב-Sidecar
העברה אל Istio Ingress Gateway
עדכון של הגדרות דחיסה ב-EnvoyFilter
הפעלת קבוצות של נקודות קצה ברשת האינטרנט
הרשאות ב-VPC משותף
חסרה הגדרה של Control Plane

מידע נוסף על תהליך העבודה של המודרניזציה זמין בדף בנושא מודרניזציה של מישור הבקרה המנוהל.

מעבר מ-Istio secrets ל-multicluster_mode

אין תמיכה בסודות של כמה אשכולות כשמשתמשים במישור הבקרה TRAFFIC_DIRECTOR של אשכול. במאמר הזה מוסבר איך אפשר לעבור משימוש בסודות של Istio בכמה אשכולות לשימוש ב-multicluster_mode.

סקירה כללית על ערכי Istio Secret לעומת API הצהרתי

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

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

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

מעבר מ-Istio secrets ל-declarative API

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

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

כדי לעבור משימוש בסודות של Istio ל-API הצהרתי, צריך לבצע את השלבים הבאים. מבצעים את השלבים הבאים בו-זמנית או ברצף מהיר:

מפעילים את ה-API הדקלרטיבי לכל אשכול ב-Fleet שרוצים להפעיל בו גילוי של נקודות קצה מרובות אשכולות. לשם כך, מגדירים את multicluster_mode=connected. שימו לב: אם לא רוצים שהאשכול יהיה ניתן לגילוי, צריך להגדיר במפורש את הערך multicluster_mode=disconnected.

כדי להפעיל את האפשרות של גילוי נקודות קצה של כמה אשכולות באשכול, משתמשים בפקודה הבאה:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
השתמש בפקודה הבאה כדי לבטל את תהליך גילוי נקודות הקצה של אשכול:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
מוחקים את הסודות הישנים.

לאחר הגדרת multicluster_mode=connected באשכולות שלך, לכל אשכול ייווצר סוד חדש עבור כל אשכול אחר שגם לו מוגדר multicluster_mode=connected. הסוד ממוקם במרחב השמות istio-system ויש לו את הפורמט הבא:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
בנוסף, תתווסף לכל סוד התווית istio.io/owned-by: mesh.googleapis.com.

אחרי שיוצרים את הסודות החדשים, אפשר למחוק באופן ידני את כל הסודות שנוצרו באמצעות istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

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

הפעלת איחוד זהויות של עומסי עבודה ל-GKE

איחוד שירותי אימות הזהות של עומסי עבודה הוא השיטה המאובטחת המומלצת לעומסי עבודה של Google Kubernetes Engine. הגישה הזו מאפשרת שימוש ב Google Cloud שירותים כמו Compute Engine,‏ BigQuery וממשקי API של למידת מכונה. איחוד שירותי אימות הזהות של עומסי עבודה לא דורש הגדרה ידנית או שיטות פחות מאובטחות כמו קובצי מפתחות של חשבונות שירות, כי הוא משתמש במדיניות IAM. לפרטים נוספים על איחוד שירותי אימות הזהות של עומסי עבודה, אפשר לקרוא את המאמר איך פועל איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

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

הפעלת איחוד שירותי אימות הזהות של עומסי עבודה באשכולות

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

כדי לבדוק את מאגר הזהויות של עומסי עבודה שהוגדר לאשכול, מריצים את הפקודה הבאה:
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
מחליפים את CLUSTER_NAME בשם של אשכול GKE. אם עוד לא ציינתם אזור או תחום ברירת מחדל ל-gcloud, יכול להיות שתצטרכו לציין גם את הדגל --region או --zone כשמריצים את הפקודה הזו.
אם הפלט ריק, פועלים לפי ההוראות במאמר עדכון של אשכול קיים כדי להפעיל את זהות עומס העבודה באשכולות GKE קיימים.

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

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

הצגת רשימה של כל מאגרי הצמתים באשכול Standard. מריצים את הפקודה gcloud container node-pools list:
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם של אשכול GKE. אם עוד לא ציינתם אזור או תחום ברירת מחדל ל-gcloud, יכול להיות שתצטרכו לציין גם את הדגל --region או --zone כשמריצים את הפקודה הזו.
מוודאים שכל מאגר צמתים משתמש בשרת המטא-נתונים של GKE:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
מחליפים את מה שכתוב בשדות הבאים:
- NODEPOOL_NAME בשם של מאגר הצמתים.
- CLUSTER_NAME בשם של אשכול GKE.
אם הפלט לא מכיל את GKE_METADATA, מעדכנים את מאגר הצמתים באמצעות המדריך עדכון של מאגר צמתים קיים.

הפעלה של ממשק רשת מנוהל של מאגר (CNI)

בקטע הזה מוסבר איך להפעיל CNI מנוהל עבור Cloud Service Mesh ב-Google Kubernetes Engine.

סקירה כללית של CNI מנוהל

ממשק רשת קונטיינרים (CNI) מנוהל הוא הטמעה של Istio CNI שמנוהלת על ידי Google. התוסף CNI מייעל את יצירת רשתות פודים על ידי הגדרת כללי iptables. זה מאפשר ניתוב מחדש של תעבורה בין אפליקציות לשרתים פרוקסיים של Envoy, ובכך מבטל את הצורך בהרשאות מועדפות עבור init-container הנדרש לניהול iptables.

‫Istio CNI plugin מחליף את מאגר התגים istio-init. בעבר, המכולה istio-init הייתה אחראית על הגדרת סביבת הרשת של הפוד כדי לאפשר יירוט תנועה עבור הצד של Istio. תוסף ה-CNI מבצע את אותה פונקציית הפניה מחדש של הרשת, אבל עם היתרון הנוסף של צמצום הצורך בהרשאות גבוהות, וכך משפר את האבטחה.

לכן, כדי לשפר את האבטחה והאמינות, ולפשט את הניהול ואת פתרון הבעיות, נדרש CNI מנוהל בכל הפריסות של Managed Cloud Service Mesh.

ההשפעה על קונטיינרים של init

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

תהליך ההגדרה של ה-Pod עם CNI מנוהל הוא כזה:

תוסף ה-CNI מגדיר ממשקי רשת של Podים, מקצה כתובות IP של Podים ומנתב מחדש תעבורת נתונים לפרוקסי קובץ העזר החיצוני של Istio שעדיין לא התחיל לפעול.
כל קונטיינרי ה-init מופעלים ומושלמים.
פרוקסי ה-sidecar של Istio מופעל לצד קונטיינרים של אפליקציות.

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

הפעלת CNI מנוהל באשכול

כדי להפעיל CNI מנוהל באשכול, פועלים לפי השלבים שמפורטים בקטע הזה.

מסירים את התלות ברשת מהקונטיינר של init. אפשר לנסות את החלופות הבאות:
- שינוי לוגיקת האפליקציה או הקונטיינרים: ניתן לשנות את השירותים שלכם כדי להסיר את התלות בקונטיינרים init הדורשים בקשות רשת או המבצעות פעולות רשת בתוך הקונטיינרים של האפליקציה, לאחר שקובץ העזר החיצוני הופעל.
- השתמש ב-Kubernetes ConfigMaps או סודות: אחסן נתוני תצורה שנאספו על ידי בקשה לאחזור מהרשת ב-Kubernetes ConfigMaps או סודות והרכב אותם לתוך מכולות האפליקציה שלך. פתרונות חלופיים מפורטים במסמכי התיעוד של Istio.
הפעל CNI מנוהל באשכול שלך:
1. מבצעים את שינויי ההגדרה הבאים:
  1. הפעל את הפקודה הבאה כדי לאתר את ה-controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. במשאב המותאם אישית ControlPlaneRevision (CPR), מגדירים את התווית mesh.cloud.google.com/managed-cni-enabled לערך true.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    החלף את CPR_NAME בערך שמתחת לעמודה NAME מהפלט של השלב הקודם.
  3. ב-asm-options ConfigMap, הגדר את הערך ASM_OPTS ל-CNI=on.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. במשאב המותאם אישית (CR) ControlPlaneRevision (CPR), מגדירים את ההערה mesh.cloud.google.com/force-reprovision לערך true. הפעולה הזו מפעילה מחדש את מישור הבקרה.
    
    הערה: שיטה זו אינה השיטה המומלצת להפעלה מחדש של מישור הבקרה, ויש להשתמש בה רק למאמצי מודרניזציה של Cloud Service Mesh.
```
kubectl annotate controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. בדוק את מצב התכונה. אפשר לאחזר את מצב התכונה באמצעות הפקודה הבאה:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet. בדרך כלל, השם של FLEET_PROJECT_ID זהה לשם הפרויקט.
  - ודא שהתנאי MANAGED_CNI_NOT_ENABLED הוסר מ-servicemesh.conditions.
  - הערה: יכולות לעבור 15-20 דקות עד שהסטטוס יתעדכן. כדאי להמתין כמה דקות ולהריץ מחדש את הפקודה.
3. לאחר שה-controlPlaneManagement.state נמצא במצב תכונה של האשכול Active, הפעל מחדש את הפודים.

מעבר משימוש בינארי לא סטנדרטי ב-Sidecar

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

תמונות של קובץ עזר חיצוני של Envoy Proxy ללא הפצה

ב-Cloud Service Mesh נעשה שימוש בשני סוגים של תמונות Envoy proxy sidecar, בהתאם להגדרת מישור הבקרה: תמונת ה-proxy‏ default (שכוללת קובצי הפעלה שונים לניפוי באגים) ותמונת ה-proxy‏ distroless.

עבור אשכולות עם מישור בקרה מנוהל TRAFFIC_DIRECTOR:

אשכולות שצורפו ישירות: ברירת המחדל היא שימוש בתמונות distroless.
אשכולות שהועברו מ-CSM-ISTIOD: נעשה שימוש בתמונות default כברירת מחדל. כדי לשפר את מצב האבטחה, אתם יכולים להביע הסכמה מפורשת לשימוש בתמונות distroless.

כדי להצטרף לשימוש בתמונות distroless עבור אשכול שהועבר מ-CSM-ISTIOD, אפשר להגדיר את התכונה באופן גלובלי באמצעות defaultConfig.image.imageType: distroless ב-MeshConfig, או לפי עומס עבודה באמצעות הערת ה-pod‏ sidecar.istio.io/proxyImageType: distroless.

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

תאימות בינארית

השיטה המומלצת היא להגביל את התוכן של זמן ריצה של קונטיינר רק לחבילות הנדרשות. הגישה הזו משפרת את האבטחה ואת יחס האות לרעש של סורקי חשיפות ופגיעויות נפוצות (CVE). תמונת ה-Sidecar של Distroless כוללת קבוצה מינימלית של תלות, ללא קובצי הפעלה, ספריות וכלי ניפוי באגים לא חיוניים. לכן אי אפשר להריץ פקודת shell או להשתמש ב-curl, ב-ping או בכלי ניפוי באגים אחרים כמו kubectl exec בתוך הקונטיינר.

התאמת אשכולות לתמונות distroless

מסירים מההגדרה הפניות לקבצים בינאריים לא נתמכים (כמו bash או curl). במיוחד בתוך בדיקות של מוכנות, הפעלה ופעילות, וווים של מחזור החיים PostStart ו-PreStop בתוך מאגרי istio-proxy,‏ istio-init או istio-validation.
במקרים מסוימים, כדאי לשקול חלופות כמו holdApplicationUntilProxyStarts.
לצורך ניפוי באגים, אפשר להשתמש בקונטיינרים זמניים כדי לצרף אותם ל-Pod של עומס עבודה שפועל. אחר כך תוכלו לבדוק אותו ולהריץ פקודות מותאמות אישית. לדוגמה, אפשר לעיין במאמר בנושא איסוף יומנים של {service_mesh_name}.

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

מעבר אל Istio Ingress Gateway

בקטע הזה מוסבר איך לבצע מיגרציה אל Istio Ingress Gateway. יש שתי שיטות להעברה אל Istio Ingress Gateway:

העברה בשלבים עם חלוקת תנועה

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

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

בדוגמאות הבאות להעברה מניחים שיש לכם שירות HTTP ‏(httpbin) שפועל במרחב השמות של האפליקציה (ברירת מחדל) וחשוף חיצונית באמצעות Kubernetes Gateway API. ההגדרות הרלוונטיות הן:

שער: k8-api-gateway (במרחב השמות istio-ingress) – מוגדר להאזין לתנועת HTTP ביציאה 80 לכל שם מארח שמסתיים ב-.example.com.
‫HTTPRoute: httpbin-route (במרחב השמות default) – מפנה כל בקשת HTTP עם שם המארח httpbin.example.com ונתיב שמתחיל ב-/get לשירות httpbin במרחב השמות default.
אפשר לגשת לאפליקציית httpbin באמצעות כתובת ה-IP החיצונית 34.57.246.68.

תרשים שער בסיסי

העברה הדרגתית עם חלוקת תנועה

הקצאת שער חדש לתעבורת נתונים נכנסת (ingress) של Istio

מבצעים פריסה של שער Ingress חדש לפי השלבים שמפורטים בקטע בנושא פריסת שער לדוגמה, ומתאימים אישית את הגדרות הדוגמה לדרישות שלכם. הדוגמאות במאגר anthos-service-mesh מיועדות לפריסת שירות istio-ingressgateway loadBalancer ותרמילי ingress-gateway התואמים.

משאב שער לדוגמה (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

החלת ההגדרה Gateway לניהול התנועה:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
ודא שה-'spec.selector' במשאב ה-Gateway שלך תואם לתוויות של הפודים של ingress-gateway שלך. לדוגמה, אם לפודים של ingress-gateway יש את התווית istio=ingressgateway, תצורת השער שלך חייבת לבחור גם את התווית istio=ingressgateway הזו.

הגדרת ניתוב ראשוני לשער החדש

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

דוגמה ל-VirtualService ‏ (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

מחילים את VirtualService:

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

גישה לשירות ה-backend (httpbin) דרך Istio Ingress Gateway שנפרס לאחרונה

הגדר את משתנה הסביבה של Ingress Host לכתובת ה-IP החיצונית המשויכת למאזן העומסים של istio-ingressgateway שנפרס לאחרונה:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
מוודאים שאפשר לגשת לאפליקציה (httpbin) באמצעות השער החדש:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
הפלט אמור להיראות כך:
```
HTTP/1.1 200 OK
```

תהליך הבקשה עם שער הכניסה החדש של Istio

שינוי כניסה קיימת לצורך פיצול תעבורה

אחרי שמאשרים שההגדרה של שער חדש (לדוגמה, istio-api-gateway) הושלמה בהצלחה, אפשר להתחיל להפנות חלק מהתנועה דרכו. כדי לעשות זאת, מעדכנים את HTTPRoute הנוכחי כדי להפנות אחוז קטן של תנועה אל השער החדש, בזמן שהחלק הגדול יותר ממשיך להשתמש בשער הקיים (k8-api-gateway).

פותחים את ה-HTTPRoute לעריכה:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

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

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

נותנים הרשאה להפניה בין מרחבי שמות באמצעות מתן הרשאה להפניה.

כדי לאפשר ל-HTTPRoute שלך במרחב השמות של האפליקציה (ברירת מחדל) גישה לשירות loadbalancer במרחב השמות של השער (istio-ingress), ייתכן שתצטרך ליצור הענקת ייחוס. המשאב הזה משמש כאמצעי בקרה אבטחתי, ומגדיר באופן מפורש אילו הפניות בין מרחבי שמות מותרות.

בדוגמה הבאה של istio-ingress-grant.yaml מתואר מענק הפניה:
```
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway
```

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

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

אימות בקשות לכתובת IP חיצונית קיימת (לדוגמה, ‫34.57.246.68) לא נכשלות. ה-check-traffic-flow.sh הבא מתאר סקריפט לבדיקת כשלים בבקשות:

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

מריצים את הסקריפט כדי לוודא שאף בקשה לא נכשלת, ללא קשר לנתיב התנועה:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

בקשת זרימה עם פיצול תנועה בין שער קיים לשער חדש של Istio Ingress

הגדלה הדרגתית של אחוז התנועה

אם לא רואים כשלים בבקשות עבור כתובת ה-IP החיצונית הקיימת (לדוגמה, 34.57.246.68), מעבירים בהדרגה יותר תנועה ל-Istio Ingress Gateway החדש על ידי שינוי המשקלים של ה-backend ב-HTTPRoute. מגדילים את המשקל של istio-ingressgateway ומקטינים את המשקל של השער הישן במרווחים קטנים, כמו 10%, 20% וכן הלאה.

השתמש בפקודה הבאה כדי לעדכן את ה-HTTPRoute הקיים שלך:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

העברה מלאה של התנועה והסרת השער הישן

כשהביצועים של שער הכניסה החדש של Istio יהיו יציבים והטיפול בבקשות יהיה מוצלח, צריך להעביר אליו את כל התנועה. עדכן את ה-HTTPRoute שלך כדי להגדיר את משקל ה-backend של השער הישן ל-0 ואת משקל השער החדש ל-100.
אחרי שתעבורת הנתונים תנותב באופן מלא לשער החדש, צריך לעדכן את רשומות ה-DNS החיצוניות של שם המארח של האפליקציה (לדוגמה, httpbin.example.com) כך שיצביעו על כתובת ה-IP החיצונית של שירות מאזן העומסים שנוצר בשלב הקצאת שער חדש של Istio Ingress.

לבסוף, מוחקים את השער הישן ואת המשאבים שמשויכים אליו:

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

העברה ישירה

הקצאת שער חדש לתעבורת נתונים נכנסת (ingress) של Istio

משאב שער לדוגמה (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

החלת ההגדרה Gateway לניהול התנועה:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
ודא שה-'spec.selector' במשאב ה-Gateway שלך תואם לתוויות של הפודים של ingress-gateway שלך. לדוגמה, אם ל-pods של ingress-gateway יש את התווית istio=ingressgateway, בהגדרת השער צריך לבחור גם את התווית istio=ingressgateway.

הגדרת ניתוב ראשוני לשער החדש

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

דוגמה ל-VirtualService ‏ (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

מחילים את VirtualService:

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

גישה לשירות ה-backend (httpbin) דרך Istio Ingress Gateway שנפרס לאחרונה

הגדר את משתנה הסביבה של Ingress Host לכתובת ה-IP החיצונית המשויכת למאזן העומסים של istio-ingressgateway שנפרס לאחרונה:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
מוודאים שאפשר לגשת לאפליקציה (httpbin) באמצעות השער החדש:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
הפלט אמור להיראות כך:
```
HTTP/1.1 200 OK
```

תהליך הבקשה עם שער הכניסה החדש של Istio

בדיקה ומעקב אחרי שער חדש

בודקים את כל כללי הניתוב, מאמתים את הגדרות ה-TLS, את מדיניות האבטחה ותכונות אחרות. בצע בדיקות עומס כדי לוודא שהשער החדש יכול להתמודד עם התעבורה הצפויה.
אחרי שבודקים את השער החדש באופן מלא, מעדכנים את רשומות ה-DNS החיצוניות של שם המארח של האפליקציה (לדוגמה, httpbin.example.com) כך שיפנו לכתובת ה-IP החיצונית של שירות מאזן העומסים שנוצר בשלב הקצאת שער חדש של Istio Ingress.
כדי לוודא שהיציבות נשמרת עם Istio Ingress Gateway החדש, צריך לעקוב אחרי מדדים מרכזיים כמו שיעור ההצלחה של הבקשות, זמן האחזור, שיעורי השגיאות וניצול המשאבים של תרמילי האפליקציה. לאחר שהשער יציב, ניתן למחוק אותו ואת המשאבים הנלווים אליו.
```
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
```

שיקולים חשובים: אם האפליקציה שלכם דורשת HTTPS, חשוב לוודא שאישורי ה-TLS וההגדרות מוגדרים בצורה נכונה ב-Istio Ingress Gateway החדש. פרטים נוספים זמינים במאמר בנושא הגדרת סיום TLS בשער כניסה.

תיקון של כמה מישורי בקרה

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

אם רוצים פריסות קנרית בגרסאות חדשות של mesh ב-rapid לפני שהן יהיו זמינות ב-stable או ב-regular, צריך להשתמש בשני אשכולות שונים, שלכל אחד מהם יש ערוץ נפרד. שימו לב: הערוצים נשלטים על ידי ערוץ GKE Cluster, ול-Mesh אין ערוץ נפרד שמשויך אליו.

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

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

gcloud container fleet mesh describe

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

...
projects/.../locations/global/memberships/my-membership:
    servicemesh:
      conditions:
      - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
        details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
        documentationLink: https://cloud.google.com/service-mesh/v1.29/docs/migrate/modernization-configuration-updates#multiple_control_planes
        severity: WARNING
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-stable'
        implementation: ISTIOD
        state: ACTIVE
...

אם הופיע התנאי UNSUPPORTED_MULTIPLE_CONTROL_PLANES, קבע אילו ערוצים קיימים עבור האשכול שלך:
```
kubectl get controlplanerevisions -n istio-system
```
הפלט אמור להיראות כך:
```
NAME                 RECONCILED   STALLED   AGE
asm-managed-stable   True         False     97d
asm-managed          True         False     97d
asm-managed-rapid    True         False     97d
```
בדוגמה הזו, שלושת הערוצים הוקצו:
- asm-managed-stable -> STABLE
- מנוהל על ידי asm -> רגיל
- asm-managed-rapid -> RAPID
אם מופיעה תוצאה אחת בלבד, אז רק ערוץ אחד הוקצה באשכול שלך, ותוכל לדלג על שאר השלבים הללו.

אם מופיעות 2 תוצאות או יותר, בצע את שאר השלבים כדי להסיר את הערוצים העודפים.

איחוד עומסי עבודה לערוץ אחד

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

כדי למצוא את כל התוויות שבהן אתם משתמשים באשכול:
```
kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL
```
בהתאם לפלט מהפקודה הקודמת, מחליפים את RELEASE_CHANNEL ב-asm-managed-stable, ב-asm-managed או ב-asm-managed-rapid. חוזרים על השלב הזה לכל ערוץ שהוקצה.

הפלט אמור להיראות כך:
```
NAME      STATUS   AGE
default   Active   110d
```
שימו לב שבדוגמה הזו, מרחב השמות שמוגדר כברירת מחדל מוזרק לערוץ הרגיל.

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

שימו לב: לפני שמשנים תוויות, כדאי לשים לב לנקודות הבאות.
- במקרים מסוימים אפשר גם להחדיר פודים ישירות באמצעות התווית sidecar.istio.io/inject. חשוב לבדוק גם את השימוש הזה.
- אפשר להתעלם מתוויות istio-injection=enabled בשלב הזה. מרחבי שמות עם התווית הזו ישתנו אוטומטית בהתאם לערוץ שיישאר באוסף.
- כשבוחרים ערוץ להשאיר, כדאי לבחור את הערוץ שזהה לערוץ של אשכול GKE. אם הערוץ הזה לא קיים, בוחרים אחד מהערוצים הפעילים.
- לא משנה איזה ערוץ בוחרים. הערוץ של אשכול GKE קובע איזו גרסה של רשת תקבלו, ולא הערוץ של רשת ה-Mesh.
- בודקים את ההגדרה של meshconfig בין כל הערוצים הפעילים שנמצאים בשימוש כדי לוודא שאין הבדלים ביניהם. כל ערוץ משתמש ב-configmap נפרד להגדרה, ולכן איחוד של שני ערוצים לערוץ אחד אמור להבטיח התנהגות עקבית בין שני הערוצים. kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml
```
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
```
מחליפים את NAMESPACE בשם של מרחב השמות.

השיטה הטובה ביותר היא להשתמש ב-istio-injection=enabled. אבל אם אתם לא רוצים להשתמש בתווית הזו, אתם יכולים להשתמש גם בתווית istio.io/rev=RELEASE_CHANNEL.

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

הסר את הערוצים הנוספים

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

מוחקים את המשאב הנוסף של ControlPlaneRevision:
```
kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system
```
מחליפים את RELEASE_CHANNEL ב-asm-managed-stable, ב-asm-managed או ב-asm-managed-rapid.

מחיקת MutatingWebhookConfiguration:

kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL

מחיקת ה-configmap של meshconfig:

kubectl delete configmap istio-RELEASE_CHANNEL

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

מריצים את הפקודה הבאה כדי להפעיל ניהול אוטומטי:
```
gcloud container fleet mesh update \
    --management automatic \
    --memberships MEMBERSHIP_NAME \
    --project PROJECT_ID \
    --location MEMBERSHIP_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MEMBERSHIP_NAME הוא שם החברות שמופיע כשאימתתם שהאשכול רשום ב-Fleet.
- PROJECT_ID הוא מזהה הפרויקט שלך.
- MEMBERSHIP_LOCATION הוא מיקום החברות שלך (אזור, או global). תוכל לבדוק את מיקום החברות שלך באמצעות gcloud container fleet memberships list --project PROJECT_ID.

מוודאים שהניהול האוטומטי מופעל:

gcloud container fleet mesh describe

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

...
membershipSpecs:
  projects/.../locations/us-central1/memberships/my-member:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/.../locations/us-central1/memberships/my-member:
    servicemesh:
      conditions:
      - code: VPCSC_GA_SUPPORTED
        details: This control plane supports VPC-SC GA.
        documentationLink: http://cloud.google.com/service-mesh/v1.29/docs/managed/vpc-sc
        severity: INFO
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
...

מודרניזציה של הגדרות המדחס של EnvoyFilter

אם אתם משתמשים במסנן envoy.extensions.filters.http.compressor.v3.Compressor, כמה שדות ברמה העליונה הוצאו משימוש ב-Envoy ועברו אל response_direction_config.common_config ואל request_direction_config.common_config.

במאמר Modernize EnvoyFilter compressor configurations מוסבר איך לעדכן את משאבי EnvoyFilter לפורמט מודרני ונתמך.

הפעלה של מדיניות ארגון נדרשת

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

מדיניות נדרשת

compute.disableInternetNetworkEndpointGroup

כדי להשתמש ב-Cloud Service Mesh, צריך ליצור קבוצות של נקודות קצה ברשת (NEGs) באינטרנט. קבוצות ה-NEG האלה הן רכיבים חיוניים לניתוב תנועת גולשים לשירותים מחוץ ל- Google Cloud.

האילוץ constraints/compute.disableInternetNetworkEndpointGroup יכול למנוע את יצירתן של רשתות ה-NEG הנחוצות הללו באינטרנט.

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

אם המדיניות Enforced מוגדרת לערך true, יצירת קבוצות NEGs של אינטרנט מושבתת.

איך אפשר לדעת אם השינוי הזה משפיע עליי?

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

לדוגמה, ניתן להשתמש בפקודה זו של Google Cloud CLI:

gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective

אם המדיניות מציגה את הערך enforced: true, אז אתה מושפע.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
  enforced: true

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

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

פתרון הבעיה

אם המדיניות נאכפת, תצטרכו להשבית אילוץ זה (מוגדר כ-false) ברמת הארגון, התיקייה או הפרויקט.

הוראות מפורטות כיצד לשנות מדיניות ארגון, כולל אילוצים בוליאניים כמו זה, ניתן למצוא במדריך יצירה וניהול של מדיניות ארגון. בדרך כלל נדרשת הרשאת roles/orgpolicy.policyAdmin כדי לבצע את השינויים האלה.

הרשאות ב-VPC משותף

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

כחלק מההעברה לTRAFFIC_DIRECTOR control plane,‏ Cloud Service Mesh דורש הרשאות לניהול כללי חומת אש בפרויקט המארח כדי להבטיח בדיקות תקינות תקינות ופונקציונליות תקינה של הרשת. הפעולה הזו לא נדרשה במישור הבקרה הקודם, ISTIOD.

איך אפשר לדעת אם השינוי הזה משפיע עליי?

אתה מושפע אם:

אשכולות GKE נמצאים בפרויקט שירות.
האשכולות האלה משתמשים ברשת VPC משותפת שמארחת בפרויקט אחר (פרויקט מארח של VPC).
לסוכן השירות של Cloud Service Mesh של פרויקט Fleet אין הרשאה לנהל כללי חומת אש בפרויקט המארח של VPC.

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

חסרה הגדרה של מישור הבקרה

בשיטות המומלצות לניהול רשת שירותים ב-Cloud Service Mesh נעשה שימוש ב-Google Kubernetes Engine Fleet API כדי להגדיר את השדה Management לערך AUTOMATIC. האפשרות הזו מספקת ניהול אוטומטי מלא של תכונות רבות של רשתות Mesh, כמו ווּבּהוקים ורמת הבקרה. בנוסף, הוא מגדיר את האשכול כך שיקבל באופן אוטומטי עדכונים ותכונות חדשים כשהם יפורסמו. חלק משיטות ההתקנה מדור קודם לא הגדירו את Cloud Service Mesh בצורה הזו, ולכן צריך לבצע כמה שלבים ידניים כדי לתקן אותן.

איך אפשר לדעת אם השינוי הזה משפיע עליי?

בודקים אם יש לכם ControlPlaneRevision באשכול:

kubectl get controlplanerevisions -n istio-system

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

אם קיבלתם את האזהרה MISSING_CONTROL_PLANE_CONFIG ואתם לא רוצים להשתמש ב-Cloud Service Mesh, אתם צריכים להשבית את Cloud Service Mesh.

שלבי המודרניזציה

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

gcloud container fleet mesh describe --project PROJECT_ID

פועלים לפי השלבים בהתאם לפלט:

תשובה	השלב לביצוע
`API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)?`	צריך להגיב `y` ולנסות שוב.
`ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled`	ממשיכים לשלב 1. הפעלת התכונה 'רשת'.
`... resourceState: state: ACTIVE ...`	עוברים לשלב 2. רושמים את האשכול ב-Fleet.

1. הפעלת תכונת הרשת

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

gcloud container fleet mesh enable --project PROJECT_ID

לאחר הפעלת תכונת הרשת, המשך ל-2. רשום את האשכול שלך ל-Fleet.

2. רישום האשכול ב-Fleet

בודקים אם האשכול כבר רשום ב-Fleet:

gcloud container fleet memberships list --project PROJECT_ID

אם האשכול לא מופיע ברשימה, פועלים לפי ההוראות האלה כדי לרשום אותו: רישום אשכול ב-Fleet.

רישום אשכול ל-Fleet מאפשר לאשכול לנהל תכונות, כמו Cloud Service Mesh, דרך ה-Fleet.

3. קביעת ערוץ הרשת

‫Cloud Service Mesh תלוי בערוץ Google Kubernetes Engine של האשכול ולא בערוץ mesh עצמאי. בעבר, Cloud Service Mesh תמך בבחירה של ערוצי רשת אחד או יותר (שונים מערוץ האשכול של Google Kubernetes Engine). יכול להיות שעדיין יהיו הפניות לערוצים האלה בהגדרות הרשת.

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

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

kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"

אם יצרתם באופן ידני תגים מותאמים אישית או ווּבְּהוּקים, אתם צריכים לבדוק גם אותם.

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

namespace/default                                 Active   153d   istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments                                Active   42d    istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default    pod/frontend-847f569874-v9kjz          2/2      Running  0   2m     app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments   pod/checkout-0                         2/2      Running  0   5d     app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default    deployment.apps/frontend               1/1      1        1   153d   app=frontend,istio.io/rev=asm-managed
payments   statefulset.apps/checkout              1/1      1        1   42d    app=checkout,istio.io/rev=asm-managed-stable

שימו לב לערכים המופיעים עבור istio.io/rev={channel}. השמות תואמים לערוצים באופן הבא. אם נעשה שימוש בכמה ערוצים, צריך לפעול לפי ההוראות במאמר תיקון של כמה מישורי בקרה כדי לצמצם את מספר הערוצים לערוץ אחד:

ערך	ערוץ
`asm-managed-stable`	יציב
`asm-managed`	Regular
`asm-managed-rapid`	חדשנות

אם ערוץ ה-mesh שלך תואם לערוץ אשכול Google Kubernetes Engine שלך, דלג לשלב 5.

4. יצירת משאב ControlPlaneRevision עבור ערוץ הרשת

אם הערוץ של הרשת תואם לערוץ של אשכול Google Kubernetes Engine, אפשר לדלג על השלב הזה. הפעלת ניהול אוטומטי של מישור הבקרה תיצור באופן אוטומטי את המשאב ControlPlaneRevision הזה אם הערוץ שלכם תואם לערוץ האשכול.

יוצרים ControlPlaneRevision משאב לערוץ הרשת שבו משתמשים:

יציב

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-stable
  namespace: istio-system
spec:
  type: managed_service
  channel: stable
EOF

Regular

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed
  namespace: istio-system
spec:
  type: managed_service
  channel: regular
EOF

חדשנות

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-rapid
  namespace: istio-system
spec:
  type: managed_service
  channel: rapid
EOF

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

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

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

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

gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID

מחליפים את MY_CLUSTER_MEMBERSHIP בשם החברות של האשכול.

6. אימות ההתקנה

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

gcloud container fleet mesh describe --project PROJECT_ID

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

createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    servicemesh:
      conditions: [] # See item 2 below
      controlPlaneManagement: # See item 3 below
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement: # See item 4 below
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
      updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'

ב-membershipSpecs, לכל חבר ב-Fleet יש מפרט נפרד. חשוב לוודא שההגדרה של כל חבר היא MANAGEMENT_AUTOMATIC.
לכל חברות משויכת רשימה של תנאי סטטוס. חשוב לוודא שלא מופיעות כאן שגיאות או אזהרות, ולעיין בקישורים למסמכים שמופיעים כדי לפתור בעיות.
השדה controlPlaneManagement מכיל את הסטטוס של מישור הבקרה. מוודאים שממשק השליטה נמצא במצב ACTIVE.
השדה dataPlaneManagement מכיל את הסטטוס של מישור הנתונים. מומלץ להפעיל את ההגדרה הזו.