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

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

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

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

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

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

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

מעבר מ-Istio secrets ל-multicluster_mode

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמה למשאב 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. לדוגמה, אם ל-pods של 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) דרך 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

שינוי של 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 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 כדי להגדיר את המשקל של העורף של השער הישן ל-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

דוגמה למשאב 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. לדוגמה, אם ל-pods של 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) דרך 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 Channel, ול-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/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 קובע איזו גרסה של mesh תקבלו, ולא ערוץ ה-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/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, יצירת 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`	חדשנות

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

כדי להשבית את גילוי נקודות הקצה של כמה אשכולות, צריך לפעול לפי ההוראות שבקטע 'השבתה' במאמר בנושא Endpoint discovery declarative 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, לכל מינוי בצי יש מפרט נפרד. חשוב לוודא שהניהול של כל מינוי מוגדר כMANAGEMENT_AUTOMATIC.
לכל מועדון יש רשימה של תנאי סטטוס שמשויכים אליו. מוודאים שאין כאן שגיאות או אזהרות, ופועלים לפי הקישורים למסמכים שמופיעים כדי לפתור בעיות.
השדה controlPlaneManagement מכיל את הסטטוס של מישור הבקרה. מוודאים שמטוס הבקרה נמצא במצב ACTIVE.
השדה dataPlaneManagement מכיל את הסטטוס של מישור הנתונים. מומלץ להפעיל את ההגדרה הזו.