הסרת 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הופסקה. כדי להגביל את התעבורה, צריך להגדיר משאבי KubernetesNetworkPolicyאו אימות והרשאה ברמת האפליקציה.
ניראות (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, משתמשים בפקודות הבאות.
כדי למנוע הפרעה לתנועת נתונים של אפליקציות:
- מבצעים שדרוג לאחור של כל כללי מדיניות 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=truekubectl 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
אם מופיע
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, סימן שההוספה האוטומטית לא הופעלה במרחב השמות.
מפעילים מחדש את עומסי העבודה שהוחדרו להם קבצים מצורפים כדי להסיר את ה-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כדי להסיר את רשת השירות מהאשכול או להשתמש בהם ברשת שירות אחרת שתואמת ל-Istio API.הסרת Istio CRs:
kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespacesהסרת CRD של Istio:
kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl deleteמסירים את ה-configmap istio-(revision). אפשר לדלג על השלב הזה אם מוחקים את
istio-systemמרחב השמות.kubectl delete configmap istio-RELEASE_CHANNEL -n istio-systemמחליפים את RELEASE_CHANNEL בערוץ ההפצה הרצוי (
asm-managed, asm-managed-stableאוasm-managed-rapid).מסירים את ה-ConfigMap asm-options:
kubectl delete configmap asm-options -n istio-systemהסרת מרחב השמות
istio-system:kubectl delete namespace istio-system --ignore-not-found=trueכדי לבדוק אם המחיקות בוצעו בהצלחה:
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.
אם אתם מתכננים להפסיק להשתמש ב-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 בעתיד.