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

‪

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

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

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

מעבר מ-Istio secrets ל-multicluster_mode

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

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

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

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

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

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

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

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

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

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

        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 ללא הפצה

‫Cloud Service Mesh משתמש בשני סוגים של קובצי אימג' של Envoy proxy sidecar על סמך הגדרת מישור הבקרה, קובץ אימג' מבוסס-Ubuntu שמכיל קבצים בינאריים שונים וקובץ אימג' Distroless. תמונות בסיסיות ללא הפצה הן תמונות מינימליות של קונטיינרים שמתמקדות באבטחה ובאופטימיזציה של משאבים, וכוללות רק רכיבים חיוניים. שטח ההתקפה מצטמצם כדי למנוע פגיעויות. מידע נוסף זמין במסמכי התיעוד בנושא תמונת proxy ללא הפצה.

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

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

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

שינוי של 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

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

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

  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

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

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

  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.
    • בודקים את ההגדרה של 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.

במאמר Modernize EnvoyFilter compressor configurations מוסבר איך לעדכן את משאבי 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, יצירת קבוצות 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 כדי לבצע את השינויים האלה.