הסרת Cloud Service Mesh מנוהל

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

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

אין תמיכה בהסרת מישורי בקרה שמנוהלים על ידי asmcli, אבל יש תמיכה באשכולות שיש להם מישורי בקרה שמנוהלים על ידי asmcli --managed או על ידי mesh API. אם אתם לא בטוחים מהו מישור הבקרה, מריצים את הפקודה הבאה:

kubectl get controlplanerevisions -n istio-system -l 'app.kubernetes.io/created-by!=asmcli'

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

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

    kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
    
  3. מאתרים סודות שצריך לנקות ומוחקים אותם:

    kubectl get secrets -n istio-system -l istio/multiCluster=true
    
    kubectl delete secret SECRET_NAME
    

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

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

     kubectl get namespace YOUR_NAMESPACE --show-labels
    

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

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

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

       kubectl label namespace YOUR_NAMESPACE istio.io/rev-
      
    2. אם מופיע istio-injection בפלט בעמודה LABELS, צריך להסיר אותו:

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

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

  6. מוודאים שלא מחוברים פרוקסי למישור הבקרה המנוהל:

      kubectl get pods --all-namespaces -o json | jq -r '
      .items[] |
      select(
         .spec.containers[].env[]? |
         select(.name == "PROXY_CONFIG" and (.value | contains("\"discoveryAddress\":\"meshconfig.googleapis.com:443\"")))
      ) |
      "\(.metadata.namespace)\t\(.metadata.name)"
      '
    
  7. עדכון של ניהול מפרט החברות בתכונת הרשת ל-not-installed:

     gcloud alpha container fleet mesh update \
       --project FLEET_PROJECT_ID \
       --memberships MEMBERSHIP_NAME \
       --location MEMBERSHIP_LOCATION \
       --management not-installed
    

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

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

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

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

     servicemesh:
       controlPlaneManagement:
         details:
         - code: DISABLED
           details: Control Plane Management is not enabled.
         state: DISABLED
       dataPlaneManagement:
         details:
         - code: DISABLED
           details: Data Plane Management is not enabled.
         state: DISABLED
     state:
       description: 'Please see https://cloud.google.com/service-mesh/docs/install for instructions to onboard to Anthos Service Mesh.'
    ...
    

    אם מצב מישור הבקרה הוא DEPROVISIONING, כדאי לבדוק שוב אחרי כמה דקות.

    1. אם מצב מישור הבקרה הוא STALLED, ההסרה נחסמת בגלל שגיאה פנימית. אם הבעיה נמשכת, אפשר לפנות לתמיכה.
  9. אופציונלית, אפשר להסיר את Istio CRs, ‏ Istio CRDs, ‏ istio-(revision) configmap,‏ asm-options configmap ומרחב השמות istio-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 בערוץ ההפצה הרצוי (asm-managed, ‏asm-managed-stable או asm-managed-rapid).

    4. מסירים את ה-ConfigMap ‏asm-options:

      kubectl delete configmap asm-options -n istio-system
      
    5. הסרת מרחב השמות istio-system:

      kubectl delete namespace istio-system --ignore-not-found=true
      
    6. כדי לבדוק אם המחיקות בוצעו בהצלחה:

      kubectl get ns
      

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

      NAME                 STATUS       AGE
      istio-system         Terminating  71m
      
  10. אם אתם משתמשים ב-Certificate Authority Service, צריך לנקות את ההרשאות ואת מאגר רשויות האישורים שנוצרו במהלך ההגדרה של Certificate Authority Service ל-Managed Cloud Service Mesh.

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

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

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

  12. אם אתם מתכננים להפסיק להשתמש ב-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 בעתיד.