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

‪

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

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

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

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

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

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

1. מפעילים את ה-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"}}'
   

2. מוחקים את הסודות הישנים.

   אחרי שמגדירים את 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.

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

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

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

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

   gcloud container clusters describe CLUSTER_NAME \
     --format="value(workloadIdentityConfig.workloadPool)"
   

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

2. אם הפלט ריק, פועלים לפי ההוראות במאמר עדכון של אשכול קיים כדי להפעיל את זהות עומס העבודה באשכולות GKE קיימים.

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

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

1. הצגת רשימה של כל מאגרי הצמתים באשכול Standard. מריצים את הפקודה gcloud container node-pools list:

   gcloud container node-pools list --cluster CLUSTER_NAME
   

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

2. מוודאים שכל מאגר צמתים משתמש בשרת המטא-נתונים של GKE:

   gcloud container node-pools describe NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --format="value(config.workloadMetadataConfig.mode)"
   

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

   • ‫NODEPOOL_NAME בשם של מאגר הצמתים.
   • CLUSTER_NAME בשם של אשכול GKE.

3. אם הפלט לא מכיל את 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 plugin מחליף את מאגר התגים istio-init. בעבר, קונטיינר istio-init היה אחראי להגדרת סביבת הרשת של ה-pod כדי לאפשר יירוט תעבורה עבור ה-sidecar של Istio. תוסף ה-CNI מבצע את אותה פונקציית הפניה מחדש של הרשת, אבל עם היתרון הנוסף של צמצום הצורך בהרשאות גבוהות, וכך משפר את האבטחה.

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

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

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

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

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

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

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

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

1. מסירים את התלות ברשת מהקונטיינר של init. אפשר לנסות את החלופות הבאות:

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

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

      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 על סמך הגדרת מישור הבקרה, קובץ אימג' מבוסס Ubuntu שמכיל קבצים בינאריים שונים וקובץ אימג' 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:

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

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

2. העברה ישירה

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

1. מבצעים פריסה של שער 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"
   

2. החלת ההגדרה Gateway לניהול התנועה:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   מוודאים שהערך של 'spec.selector' במשאב Gateway תואם לתוויות של תרמילי ingress-gateway. לדוגמה, אם ל-pods של ingress-gateway יש את התווית istio=ingressgateway, בהגדרת השער צריך לבחור גם את התווית istio=ingressgateway.

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

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

2. מחילים את VirtualService:

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

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

1. מגדירים את משתנה הסביבה Ingress Host לכתובת ה-IP החיצונית שמשויכת למאזן העומסים istio-ingressgateway שנפרס לאחרונה:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. מוודאים שאפשר לגשת לאפליקציה (httpbin) באמצעות השער החדש:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

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

   HTTP/1.1 200 OK
   

שינוי של Ingress קיים לצורך פיצול תנועה

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

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

   kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
   

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

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

   כדי לאפשר ל-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
   

4. החלת מענק קובץ העזר:

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

5. אימות בקשות לכתובת 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
   

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

   chmod +x check-traffic-flow.sh
   ./check-traffic-flow.sh
   

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

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

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

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

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

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

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

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

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

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

העברה ישירה

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

1. מבצעים פריסה של שער 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"
   

2. החלת ההגדרה Gateway לניהול התנועה:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   מוודאים שהערך של 'spec.selector' במשאב Gateway תואם לתוויות של תרמילי ingress-gateway. לדוגמה, אם ל-pods של ingress-gateway יש את התווית istio=ingressgateway, בהגדרת השער צריך לבחור גם את התווית istio=ingressgateway.

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

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

2. מחילים את VirtualService:

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

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

1. מגדירים את משתנה הסביבה Ingress Host לכתובת ה-IP החיצונית שמשויכת למאזן העומסים istio-ingressgateway שנפרס לאחרונה:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. מוודאים שאפשר לגשת לאפליקציה (httpbin) באמצעות השער החדש:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

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

   HTTP/1.1 200 OK
   

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

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

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

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

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

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

   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
   ...
   

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

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

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

1. כדי לראות את כל התוויות שבהן אתם משתמשים באשכול:

   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
   

   שימו לב שבדוגמה הזו, מרחב השמות שמוגדר כברירת מחדל מוזרק לערוץ הרגיל.

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

2. משנים את התוויות כך שרק ערוץ אחד יהיה בשימוש:

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

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

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

1. מוחקים את המשאב הנוסף של ControlPlaneRevision:

   kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system
   

   מחליפים את RELEASE_CHANNEL ב-asm-managed-stable, ב-asm-managed או ב-asm-managed-rapid.

2. מחיקת MutatingWebhookConfiguration:

   kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL
   

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

   kubectl delete configmap istio-RELEASE_CHANNEL
   

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

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

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

   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.

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

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

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

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

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

1. אשכולות GKE נמצאים בפרויקט שירות.
2. האשכולות האלה משתמשים ברשת VPC משותפת שמארחת בפרויקט אחר (פרויקט מארח של VPC).
3. לסוכן השירות של 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'

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