‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

הסרת 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, משתמשים בפקודות הבאות.

כדי למנוע שיבוש בתנועת הנתונים של האפליקציה:
- מבצעים שדרוג לאחור של כל כללי מדיניות mTLS מסוג STRICT ל-PERMISSIVE.
- מסירים את כל כללי המדיניות AuthorizationPolicy שעלולים לחסום תנועה.
צריך להשבית את התכונה 'ריבוי אשכולות' אם יש אשכולות אחרים שמריצים גילוי נקודות קצה באשכול שממנו מסירים את ההתקנה.
```
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
```
מאתרים סודות שצריך לנקות ומוחקים אותם:
```
kubectl get secrets -n istio-system -l istio/multiCluster=true
```
```
kubectl delete secret SECRET_NAME
```
כאשר SECRET_NAME הוא שם הסוד. חוזרים על השלב הזה לכל סוד שמופיע ברשימה.
אם האפשרות הזו מופעלת, משביתים את ההזרקה האוטומטית של 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, סימן שההחדרה האוטומטית לא הופעלה במרחב השמות.
הערה: כדאי לבדוק גם משאבים אחרים, כולל Deployments,‏ StatefulSets,‏ ReplicaSets,‏ DaemonSets,‏ Jobs ו-CronJobs, כדי לוודא שלא בוצעה בהם הזרקה.
מפעילים מחדש את עומסי העבודה שהוחדרו להם קבצי sidecar כדי להסיר את ה-proxies.

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

  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)"
  '

עדכון של ניהול מפרט החברות בתכונת הרשת ל-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).

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

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

אופציונלי: מסירים את Istio CRs,‏ Istio CRDs,‏ istio-(revision) configmap,‏ asm-options configmap ואת מרחב השמות istio-system כדי להסיר את Service mesh מהאשכול או להשתמש בהם ברשת שירות אחרת שתואמת ל-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
```
אם אתם משתמשים ב-Certificate Authority Service, צריך לנקות את ההרשאות ואת מאגר רשויות האישורים שנוצרו במהלך ההגדרה של Certificate Authority Service ל-Managed Cloud Service Mesh.
אם הפעלתם את ההגדרה של צי Cloud Service Mesh מנוהל שמוגדרת כברירת מחדל, ואתם רוצים להשבית אותה באשכולות עתידיים, אתם יכולים להשבית אותה. אפשר לדלג על השלב הזה אם מסירים את התוסף רק מאשכול אחד.
```
 gcloud container hub mesh disable --fleet-default-member-config --project FLEET_PROJECT_ID
```
כאשר FLEET_PROJECT_ID הוא מזהה פרויקט Fleet Host שלך.
אם אתם מתכננים להפסיק להשתמש ב-Cloud Service Mesh ברמת הצי, אתם צריכים להשבית את התכונה של רשת השירות בפרויקט המארח של הצי.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
כאשר FLEET_PROJECT_ID הוא מזהה פרויקט Fleet Host שלך.

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