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

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

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

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

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

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

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

מעבר מסודות של Istio ל-multicluster_mode

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

סקירה כללית על סודות של Istio לעומת API דקלרטיבי

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

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

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

מעבר מסודות של Istio ל-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

איחוד זהויות של עומסי עבודה (WIF) הוא השיטה המאובטחת המומלצת לעומסי עבודה ב-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 כשאתם מריצים את הפקודה הזו.
אם הפלט ריק, פועלים לפי ההוראות במאמר עדכון אשכול קיים כדי להפעיל את Workload Identity באשכולות GKE קיימים.

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

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

הצגת רשימה של כל מאגרי הצמתים באשכול רגיל. מריצים את הפקודה 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 מייעל את הרשת של ה-Pod על ידי הגדרת כללי iptables. כך אפשר להפנות את התנועה בין האפליקציות לשרתי ה-proxy של Envoy, בלי צורך בהרשאות מיוחדות ל-init-container שנדרש לניהול iptables.

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

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

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

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

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

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

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

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

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

מסירים את יחסי התלות ברשת ממאגר ה-init. אפשר להשתמש באחת מהאפשרויות הבאות:
- שינוי הלוגיקה של האפליקציה או של הקונטיינרים: אתם יכולים לשנות את השירותים כדי להסיר את התלות בקונטיינרים של init שדורשים בקשות לאחזור מהרשת, או לבצע פעולות ברשת בתוך הקונטיינרים של האפליקציה אחרי שהתחיל לפעול קובץ העזר החיצוני.
- שימוש ב-ConfigMaps או בסודות של Kubernetes: אחסון נתוני הגדרה שאוחזרו על ידי הבקשה לאחזור מהרשת ב-ConfigMaps או בסודות של Kubernetes, והתקנה שלהם בקונטיינרים של האפליקציה. לפתרונות חלופיים, עיינו במסמכי התיעוד של Istio.
מפעילים CNI מנוהל באשכול:
1. מבצעים את השינויים הבאים בהגדרות:
  1. מריצים את הפקודה הבאה כדי לאתר את controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. במשאב המותאם אישית (CR) של 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. ב-ConfigMap של asm-options, מגדירים את הערך של 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. בודקים את מצב התכונה ב-Fleet כולו. מאחזרים את מצב התכונה באמצעות הפקודה הבאה:
```
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 במצב התכונה ב-Fleet כולו של האשכול, מפעילים מחדש את ה-pods.

הפסקת השימוש בקובץ בינארי לא סטנדרטי ב-Sidecar

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

תמונות של שרתי פרוקסי מסוג Envoy ללא הפצה

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

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

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

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

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

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

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

התאמת אשכולות לתמונות ללא הפצה (distroless)

מסירים מההגדרות הפניות לקבצים בינאריים לא נתמכים (כמו bash או curl). במיוחד בתוך בדיקות Readiness,‏ Startup ו-Liveness, ובתוך הוקים של Lifecycle PostStart ו-PreStop במאגרי istio-proxy,‏ istio-init או istio-validation.
במקרים מסוימים, כדאי לשקול חלופות כמו holdApplicationUntilProxyStarts.
כדי לנפות באגים, אתם יכולים להשתמש בקונטיינרים זמניים כדי לצרף לפוד של עומס עבודה שפועל. אחר כך אפשר לבדוק אותו ולהריץ פקודות בהתאמה אישית. לדוגמה, ראו איסוף יומנים של {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.

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

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

הקצאת שער חדש של Istio Ingress Gateway

פורסים שער Ingress חדש לפי השלבים שמפורטים בקטע פריסת שער לדוגמה, ומתאימים אישית את הגדרות הדוגמה לפי הדרישות שלכם. הדוגמאות במאגר anthos-service-mesh מיועדות לפריסת שירות istio-ingressgateway loadBalancer ו-pods תואמים של 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

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

מגדירים את משתנה הסביבה 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

שינוי של Ingress קיים לחלוקת התנועה

אחרי שמוודאים שהשער החדש (למשל 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

מגדילים בהדרגה את אחוז התנועה

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

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

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

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

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

העברה ישירה

הקצאת שער חדש של Istio 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

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

מגדירים את משתנה הסביבה 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.
כדי לוודא שהמערכת יציבה עם Istio Ingress Gateway החדש, עוקבים אחרי מדדים מרכזיים כמו שיעור הבקשות שהצליחו, זמן האחזור, שיעורי השגיאות וניצול המשאבים של Pods של האפליקציה. אחרי שהחיבור יציב, אפשר למחוק את השער הישן ואת המשאבים שמשויכים אליו.
```
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
```

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

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

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

אם אתם רוצים פריסות של גרסה ראשונית (canary) בגרסאות חדשות של רשת בערוץ המהיר לפני שהן יהיו זמינות בערוץ היציב או הרגיל, תצטרכו להשתמש בשני אשכולות שונים, שלכל אחד מהם יש ערוץ נפרד. שימו לב שהערוצים נשלטים על ידי ערוץ אשכול GKE, ול-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.30/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-managed -> REGULAR
- 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 קובע איזו גרסה של רשת תקבלו, ולא הערוץ של הרשת.
- בודקים את ההגדרות של 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.30/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.

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

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

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

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

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

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

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

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

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

בשיטות המומלצות של Cloud Service Mesh לניהול רשת שירות, משתמשים ב-Fleet API של Google Kubernetes Engine כדי להגדיר את השדה Management לערך AUTOMATIC. כך אפשר לנהל באופן אוטומטי לגמרי הרבה תכונות של רשת ה-Mesh, כמו לפעולות לפיתוח Webhook ומישור הבקרה. בנוסף, הוא מגדיר את האשכול כך שיקבל באופן אוטומטי עדכונים ותכונות חדשות כשהם מתפרסמים. בחלק משיטות ההתקנה הקודמות, 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 יוכל לפעול בפרויקט. לפרטים נוספים ולהשפעות אפשריות, קראו את המאמר הקצאת 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. איך קובעים את הערוץ של רשת ה-Mesh

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

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

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

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

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

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

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`	חדשנות

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

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

אם ערוץ הרשת תואם לערוץ של אשכול 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 הצהרתי לזיהוי נקודות קצה לפני שמפעילים את הניהול האוטומטי של מישור הבקרה.

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

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

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 מכיל את הסטטוס של מישור הנתונים. מומלץ להפעיל את האפשרות הזו.