הסרת Cloud Service Mesh בתוך האשכול

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

אם פועלים לפי ההוראות האלה להסרת Cloud Service Mesh בתוך האשכול, כל ההגדרות יוסרו.

אם אתם מסירים את Cloud Service Mesh המנוהל, אתם צריכים לפעול לפי מדריך ההסרה המנוהלת.

אם אתם עוברים מ-in-cluster ל-managed, עדיף שתפעלו לפי מדריך ההעברה.

ההשפעה של הסרת Cloud Service Mesh

לפני שמסירים את Cloud Service Mesh, כדאי לשקול את היכולות שיוסרו מהאשכול ועומסי העבודה. כשמסירים את ה-proxies של Cloud Service Mesh מעומסי העבודה ומפעילים אותם מחדש, האפליקציות חוזרות להתנהגות הרגילה של רשת Kubernetes.

אבטחה

כשמסירים את Cloud Service Mesh, מאבדים את תכונות האבטחה הבאות:

• הצפנת Mutual TLS ‏ (mTLS): תעבורת הנתונים בין השירותים לא מוצפנת יותר במהלך ההעברה באמצעות אישורי mTLS שמנוהלים על ידי הרשת.
• מדיניות הרשאות: אכיפת המשאבים המותאמים אישית של Mesh AuthorizationPolicy הופסקה. כדי להגביל את התעבורה, צריך להגדיר משאבי Kubernetes NetworkPolicy או אימות והרשאה ברמת האפליקציה.

ניראות (observability)

כשמסירים את Cloud Service Mesh, מאבדים את תכונות הנראות הבאות:

• טלמטריה ומדדים: האיסוף האוטומטי של מדדים בשכבה 7 (כמו שיעורי בקשות, שיעורי שגיאות וחביון) נפסק. נתוני טלמטריה של רשתות Mesh לא מוזנים יותר באופן אוטומטי ל-Cloud Monitoring. אין השפעה על מדדים רגילים של GKE.
• לוחות בקרה ויעדים למדידת רמת השירות (SLO): לוחות הבקרה שהוגדרו מראש ב-Cloud Service Mesh והמעקב אחרי היעדים למדידת רמת השירות (SLO) במסוףGoogle Cloud לא מתעדכנים יותר.
• רישום ביומן ומעקב אחר גישה: יומני גישה של קובץ עזר חיצוני עם זהויות mTLS של לקוחות ומעקבים מבוזרים אוטומטיים לא נוצרים יותר.

זיהוי שירותים וחוסן של רשתות

כשמסירים את Cloud Service Mesh, מאבדים את התכונות הבאות של רשתות ועמידות:

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

הסרת Cloud Service Mesh

כדי להסיר את כל הרכיבים של Cloud Service Mesh, משתמשים בפקודות הבאות.

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

   • מבצעים שדרוג לאחור של כל כללי מדיניות mTLS מסוג STRICT ל-PERMISSIVE.
   • מסירים את כל כללי AuthorizationPolicy שעלולים לחסום תנועה.

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

    kubectl get namespace YOUR_NAMESPACE --show-labels
   

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

    NAME   STATUS   AGE     LABELS
    demo   Active   4d17h   istio.io/rev=asm-181-5

   אם מופיע istio.io/rev= בפלט בעמודה LABELS, צריך להסיר אותו:

    kubectl label namespace YOUR_NAMESPACE istio.io/rev-
   

   אם מופיע istio-injection בפלט בעמודה LABELS, צריך להסיר אותו:

    kubectl label namespace YOUR_NAMESPACE istio-injection-
   

   אם לא מופיעות התוויות istio.io/rev או istio-injection, סימן שההוספה האוטומטית לא הופעלה במרחב השמות.

3. מפעילים מחדש את עומסי העבודה שהוחדרו להם קבצים מצורפים כדי להסיר את ה-proxies.

4. אם קיימים validatingwebhooksconfiguration ו-mutatingwebhookconfiguration במקבץ, מוחקים אותם:

     kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot,istio.io/owned-by!=mesh.googleapis.com
   

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

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

   istioctl uninstall --purge
   

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

6. אופציונלית, מסירים את Istio CRs, ‏ Istio CRDs, ‏ istio-(revision) configmap,‏ asm-options configmap, ‏ istio-system ומרחבי שמות של asm-system כדי להסיר את רשת השירות מהאשכול או להשתמש בהם ברשת שירות אחרת שתואמת ל-Istio API.

   1. הסרת Istio CRs:

      kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces
      

   2. הסרת CRD של Istio:

      kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete
      

   3. מסירים את ה-configmap‏ istio-(revision). אפשר לדלג על השלב הזה אם מוחקים את istio-systemמרחב השמות.

      kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
      

      מחליפים את RELEASE_CHANNEL בערוץ ההפצה שלכם

   4. הסרת מרחב השמות istio-system:

      kubectl delete namespace istio-system --ignore-not-found=true
      

   5. הסרת מרחב השמות asm-system:

      kubectl delete namespace asm-system --ignore-not-found=true
      

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

          kubectl get ns
          ```
         
         The output should indicate a `Terminating` state and return as shown,
         otherwise you might have to manually delete any remaining resources in
         the namespaces and try again.
         
         ```sh
          NAME                 STATUS       AGE
          istio-system         Terminating  71m
          asm-system           Terminating  71m
          ```
         

7. אם אתם מתכוונים למחוק את האשכולות, או שכבר מחקתם אותם, ודאו שכל אשכול לא רשום ב-Fleet.

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

    gcloud container hub mesh disable --project FLEET_PROJECT_ID
   

   כאשר FLEET_PROJECT_ID הוא מזהה פרויקט המארח של ה-Fleet.

אחרי שמבצעים את השלבים האלה, כל הרכיבים של Cloud Service Mesh, כולל שרתי proxy, רשויות אישורים באשכול ותפקידים וקשרים של RBAC, מוסרים מהאשכול באופן שיטתי. במהלך תהליך ההתקנה, לחשבון שירות בבעלות Google ניתנות ההרשאות הנדרשות ליצירת משאבי Service mesh באשכול. ההוראות האלה להסרת ההתקנה לא מבטלות את ההרשאות האלה, כך שבעתיד אפשר יהיה להפעיל מחדש את Cloud Service Mesh בצורה חלקה.