הסרת Cloud Service Mesh

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

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

הסרת Cloud Service Mesh

כדי להסיר את כל הרכיבים של Cloud Service Mesh, משתמשים בפקודות הבאות. הפקודות האלה מוחקות גם את מרחב השמות istio-system ואת כל ההגדרות של משאבים מותאמים אישית (CRD), כולל כל ה-CRD שהחלתם.

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

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

  2. משביתים את הניהול האוטומטי באשכול הזה (אם הפעלתם אותו ישירות או באמצעות הגדרת ברירת המחדל של הצי):

      gcloud container fleet mesh update \
     --management manual \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

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

    • ‫MEMBERSHIP_NAME הוא שם החברות שמופיע כשמאמתים שהאשכול רשום ב-Fleet.
    • ‫MEMBERSHIP_LOCATION הוא המיקום של המינוי (אזור או global).

  3. אם האפשרות הזו מופעלת, משביתים את ההזרקה האוטומטית של 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, סימן שההוספה האוטומטית לא הופעלה במרחב השמות.

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

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

  6. אם אתם משתמשים ב-Cloud Service Mesh מנוהל, צריך להסיר את כל controlplanerevisionהמשאבים באשכול:

    kubectl delete controlplanerevision asm-managed asm-managed-rapid asm-managed-stable -n istio-system --ignore-not-found=true

    בודקים את הסטטוס של משאבי controlplanerevision כדי לוודא שהם נמחקו:

    kubectl get controlplanerevision -n istio-system

    אם הפלט מראה שמשאב controlplanerevision עדיין קיים, יכול להיות שהוא תקוע עם mesh.cloud.google.com/deprovision finalizer. במקרה כזה, אפשר להסיר באופן ידני את ה-finalizer מהמשאב כדי לאפשר את המחיקה שלו:

    kubectl patch controlplanerevision CPR_NAME -n istio-system -p '{"metadata":{"finalizers":null}}' --type=merge

    מחליפים את CPR_NAME בשם של עדכון מישור הבקרה שהוחזר בשלב הקודם, לדוגמה, asm-managed.

  7. מוחקים את ה-webhook מהאשכול, אם הוא קיים.

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

    מוחקים את validatingwebhooksconfiguration ואת mutatingwebhookconfiguration.

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

    Managed Cloud Service Mesh

    א. מוחקים את validatingwebhooksconfiguration.

    kubectl delete validatingwebhookconfiguration istiod-istio-system-mcp

    ב. מחיקת כל mutatingwebhookconfiguration.

    kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL

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

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

    istioctl uninstall --purge

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

  9. מחיקת מרחבי השמות istio-system ו-asm-system:

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

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

     kubectl get ns

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

     NAME                 STATUS       AGE
 istio-system         Terminating  71m
 asm-system           Terminating  71m

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

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

     gcloud container hub mesh disable --fleet-default-member-config --project FLEET_PROJECT_ID

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

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

     gcloud container hub mesh disable --project FLEET_PROJECT_ID

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

  14. אם הפעלתם את Cloud Service Mesh מנוהל, כדאי לבדוק ולמחוק משאבים מנוהלים אם הם מופיעים:

    1. מוחקים את הפריסה mdp-controller:

        kubectl delete deployment mdp-controller -n kube-system

    2. מקבלים ואז מוחקים את המשאב המותאם אישית של בקרת מישור הנתונים:

      1. מקבלים את ה-CR של מישור הבקרה של הנתונים:

        kubectl get dataplanecontrol

      2. מוחקים את ה-CR של בקרת מישור הנתונים:

        kubectl delete dataplanecontrol DATA_PLANE_CONTROL_CR_NAME

        מחליפים את DATA_PLANE_CONTROL_CR_NAME בפלט מהפקודה הקודמת.

      3. מחיקת ה-CRD של controlplanerevision ושל dataplanecontrol:

        kubectl delete crd controlplanerevisions.mesh.cloud.google.com dataplanecontrols.mesh.cloud.google.com

    3. אם יש לכם הטמעה של מישור הבקרה TRAFFIC_DIRECTOR, צריך לנקות את המשאבים של בדיקת התקינות השקופה. בדרך כלל המערכת מסירה את הקבצים האלה באופן אוטומטי, אבל כדי לוודא שהם יוסרו, אפשר לבצע את הפעולות הבאות:

      1. מוחקים את ה-daemonset‏ snk.

           kubectl delete daemonset snk -n kube-system

      2. מוחקים את כלל חומת האש.

           gcloud compute firewall-rules delete gke-csm-thc-FIRST_8_CHARS_OF_CLUSTER_ID

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

        • ‫FIRST_8_CHARS_OF_CLUSTER_ID הוא 8 התווים הראשונים של מזהה האשכול עבור האשכול הספציפי שלכם.

    4. בודקים אם קובץ ה-configmap‏ istio-cni-plugin-config קיים:

        kubectl get configmap istio-cni-plugin-config -n kube-system

      אם הוא קיים, מוחקים את ה-configmap‏ istio-cni-plugin-config:

        kubectl delete configmap istio-cni-plugin-config -n kube-system

    5. מוחקים את ה-daemonset‏ istio-cni-node:

        kubectl delete daemonset istio-cni-node -n kube-system

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

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

.