הקצאת Cloud Service Mesh מנוהל באמצעות asmcli

‪

סקירה כללית

‫Managed Cloud Service Mesh עם asmcli הוא מישור בקרה מנוהל ומישור נתונים מנוהל שפשוט מגדירים. ‫Google מטפלת באמינות, בשדרוגים, בהתאמה ובאבטחה שלהם באופן שתואם לאחור. במדריך הזה מוסבר איך להגדיר או להעביר אפליקציות ל-Cloud Service Mesh מנוהל בהגדרה של אשכול יחיד או של כמה אשכולות באמצעות asmcli.

במאמר תכונות נתמכות של Managed Cloud Service Mesh מפורטות התכונות הנתמכות והמגבלות של Managed Cloud Service Mesh.

דרישות מוקדמות

כנקודת מוצא, במדריך הזה אנחנו מניחים שיש לכם:

דרישות

  • אחד או יותר אשכולות עם גרסה נתמכת של GKE, באחד מהאזורים הנתמכים.
  • שימו לב ש-Cloud Service Mesh מנוהל ומשתמש בערוצי הפצה של GKE כדי ליצור איזון בין יציבות לבין מהירות השדרוג. שינויים חדשים ברכיבים בתוך האשכול של Cloud Service Mesh (כולל CNI,‏ MDPC,‏ proxies ו-Istio CRDs) יושקו קודם באשכולות שרשומים לערוץ המהיר של GKE. לאחר מכן הן יועברו לערוץ הרגיל של GKE, ולבסוף לערוץ היציב של GKE, אחרי שיוכח שהן יציבות מספיק.
    • השיטה המומלצת היא להקצות קבוצת משנה של אשכולות הצי בערוץ הפצה מוקדם יותר של GKE, כדי להבטיח שהם יקבלו עדכונים לרכיבי Cloud Service Mesh קודם.
    • שירות Managed Cloud Service Mesh לא תומך בשינוי ערוצי ההפצה של GKE.
    • אם תשנו את ערוץ ההפצה של GKE,‏ Cloud Service Mesh לא ימנע את הפעולה. ‫Cloud Service Mesh מעדכן אוטומטית את הרכיבים בתוך האשכול (CNI, ‏ MDPC, גרסת ה-proxy המוזרקת כברירת מחדל ו-CRD של Istio) כדי להתאים לערוץ ההפצה הנוכחי של GKE.
  • מוודאים שלקלאסטר יש מספיק קיבולת לרכיבים הנדרשים שמוגדרים בהתקנה של Cloud Service Mesh בקלאסטר.
    • הפריסה mdp-controller במרחב השמות kube-system מבקשת cpu: 50m, memory: 128Mi.
    • ה-daemonset‏ istio-cni-node במרחב השמות kube-system מבקש cpu: 100m,‏ memory: 100Mi בכל צומת.
  • מוודאים שמדיניות הארגון constraints/compute.disableInternetNetworkEndpointGroup מושבתת. אם המדיניות מופעלת, יכול להיות ש-ServiceEntry לא יפעל.
  • מוודאים שלמחשב הלקוח שממנו אתם מקצים את Cloud Service Mesh המנוהל יש קישוריות לרשת לשרת ה-API.
  • האשכולות צריכים להיות רשומים ב-Fleet. אפשר לבצע את השלב הזה בנפרד לפני הקצאת הרישיון, או כחלק מהקצאת הרישיון באמצעות הדגלים --enable-registration ו---fleet-id.

  • בפרויקט צריך להפעיל את התכונה Service Mesh fleet. אפשר להפעיל אותו כחלק מההקצאה על ידי העברת --enable-gcp-components, או על ידי הרצת הפקודה הבאה:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID

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

  • ‫GKE Autopilot נתמך רק בגרסה GKE 1.21.3 ואילך.

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

    • אם מצטרפים לאשכולות שלא נמצאים באותו פרויקט, הם צריכים להיות רשומים באותו פרויקט מארח של Fleet, והאשכולות צריכים להיות מוגדרים יחד בVPC משותף באותה רשת.
    • בסביבה מרובת אשכולות של פרויקט יחיד, פרויקט ה-Fleet יכול להיות זהה לפרויקט האשכול. מידע נוסף על צי רכבים זמין במאמר סקירה כללית על צי רכבים.
    • בסביבה מרובת פרויקטים, מומלץ לארח את Fleet בפרויקט נפרד מפרויקטים של אשכולות. אם מדיניות הארגון וההגדרה הקיימת מאפשרות זאת, מומלץ להשתמש בפרויקט ה-VPC המשותף כפרויקט המארח של Fleet. מידע נוסף זמין במאמר בנושא הגדרת אשכולות עם VPC משותף.
    • אם בארגון שלכם משתמשים ב-VPC Service Controls ואתם מקצים Cloud Service Mesh באשכולות GKE עם גרסה גדולה או שווה ל-1.22.1-gke.10, יכול להיות שתצטרכו לבצע שלבי הגדרה נוספים:
      • אם אתם מקצים Cloud Service Mesh בערוץ ההפצה הרגיל או היציב , אתם צריכים להשתמש בדגל --use-vpcsc הנוסף כשאתם מחילים את מישור הבקרה המנוהל, ולפעול לפי המדריך בנושא VPC Service Controls (גרסת Preview). אחרת, ההקצאה תיכשל בבדיקות של אמצעי הבקרה לאבטחה.
      • אם אתם מקצים Cloud Service Mesh במהיר ערוץ ההפצה, אתם לא צריכים להשתמש בדגל הנוסף --use-vpcsc כשאתם מחילים את מישור הבקרה המנוהל, אבל אתם כן צריכים לפעול לפי המדריך ל-VPC Service Controls (זמינות כללית).

התפקידים שנדרשים להתקנת Cloud Service Mesh

בטבלה הבאה מפורטים התפקידים שנדרשים להתקנת Cloud Service Mesh מנוהל.

שם התפקיד מזהה תפקיד Grant location תיאור
אדמין GKE Hub roles/gkehub.admin פרויקט Fleet גישה מלאה ל-GKE Hubs ולמשאבים קשורים.
אדמין של Service Usage roles/serviceusage.serviceUsageAdmin פרויקט Fleet אפשרות להפעיל, להשבית ולבדוק את מצבי השירות, לבדוק פעולות ולצרוך מכסה וחיוב עבור פרויקט צרכן. (הערה 1)
אדמין של שירות CA‏ בטא roles/privateca.admin פרויקט Fleet גישה מלאה לכל המשאבים של שירות CA. (הערה 2)

תפקידים שנדרשים להפעלת Cloud Service Mesh

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

שם התפקיד מזהה תפקיד Grant location תיאור
סוכן שירות של Anthos Service Mesh roles/anthosservicemesh.serviceAgent פרויקט Fleet
סוכן שירות מנוהל ברמת הבקרה של רשת (מאמר שמתייחס לגרסה קודמת) roles/meshcontrolplane.serviceAgent פרויקט Fleet זהו תפקיד מדור קודם שהיה חלק מהתקנות ישנות יותר של Cloud Service Mesh. אם בהתקנה שלכם יש את תפקיד השירות הזה, אתם יכולים להשאיר אותו כמו שהוא. בהתקנות חדשות אין צורך בתפקיד הזה.

מגבלות

מומלץ לעיין ברשימת התכונות הנתמכות והמגבלות של Cloud Service Mesh. חשוב לשים לב במיוחד לנקודות הבאות:

  • באשכולות GKE Autopilot, הגדרה חוצת-פרויקטים נתמכת רק ב-GKE 1.23 ואילך.

  • באשכולות GKE Autopilot, כדי להתאים למגבלת המשאבים של GKE Autopilot, בקשות המשאבים ומגבלות ברירת המחדל של ה-proxy מוגדרות ל-500m CPU ול-512 Mb זיכרון. אפשר לשנות את ערכי ברירת המחדל באמצעות הוספה בהתאמה אישית.

  • במקרה של אשכולות GKE Autopilot, יכול להיות שיוצגו אזהרות לגבי רכיבי Cloud Service Mesh ‏(DaemonSet has no nodes selected) עד שה-NodePool של האשכולות יתרחב.

  • במהלך תהליך ההקצאה של מישור בקרה מנוהל, מוקצים CRD של Istio באשכול שצוין. אם יש CRD של Istio קיימים באשכול, הם יוחלפו.

  • ‫Istio CNI ו-Traffic Director לא תואמים ל-GKE Sandbox. לכן, Cloud Service Mesh מנוהל עם הטמעה של TRAFFIC_DIRECTOR לא תומך באשכולות שמופעל בהם GKE Sandbox.

  • לכלי asmcli צריכה להיות גישה לנקודת הקצה של Google Kubernetes Engine‏ (GKE). אפשר להגדיר גישה דרך שרת מעבר, כמו מכונה וירטואלית של Compute Engine בענן וירטואלי פרטי (VPC), כדי לתת גישה ספציפית.

לפני שמתחילים

הגדרת gcloud

מבצעים את השלבים הבאים גם אם משתמשים ב-Cloud Shell.

  1. מאמתים באמצעות Google Cloud CLI:

    gcloud auth login --project PROJECT_ID

    כאשר PROJECT_ID הוא המזהה הייחודי של פרויקט האשכול. מריצים את הפקודה הבאה כדי לקבל את PROJECT_ID:

       gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

  2. מעדכנים את הרכיבים:

    gcloud components update

  3. מגדירים את kubectl כך שיצביע על האשכול.

    gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

הורדה של כלי ההתקנה

  1. מורידים את הגרסה העדכנית של הכלי לספריית העבודה הנוכחית:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. הופכים את הכלי לקובץ הפעלה:

    chmod +x asmcli

הגדרת כל אשכול

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

החלה של מישור הבקרה המנוהל

לפני שמחילים את מישור הבקרה המנוהל, צריך לבחור ערוץ הפצה. הערוץ של Cloud Service Mesh נקבע לפי הערוץ של אשכול GKE בזמן הקצאת Cloud Service Mesh מנוהל. שימו לב: אי אפשר להשתמש בכמה ערוצים באותו אשכול בו-זמנית.

מריצים את כלי ההתקנה לכל אשכול שבו ישתמשו ב-Cloud Service Mesh מנוהל. מומלץ לכלול את שתי האפשרויות הבאות:

  • ‫--enable-registration --fleet_id FLEET_PROJECT_ID שני הדגלים האלה רושמים את האשכול ב-Fleet, כאשר FLEET_ID הוא מזהה הפרויקט של פרויקט המארח של ה-Fleet. אם משתמשים בפרויקט יחיד, FLEET_PROJECT_ID זהה ל-PROJECT_ID, פרויקט המארח של ה-Fleet ופרויקט האשכול זהים. בהגדרות מורכבות יותר, כמו הגדרות של כמה פרויקטים, מומלץ להשתמש בפרויקט נפרד של מארח Fleet.

  • ‫--enable-all. הפלאג הזה מפעיל גם את הרכיבים הנדרשים וגם את הרישום.

asmcli הכלי מגדיר את מישור הבקרה המנוהל ישירות באמצעות כלים ולוגיקה בתוך כלי ה-CLI. פועלים לפי ההוראות שבהמשך בהתאם לרשות האישורים המועדפת.

רשויות אישורים

בוחרים רשות אישורים לשימוש ברשת.

Mesh CA

מריצים את הפקודה הבאה כדי להתקין את מישור הבקרה עם תכונות ברירת מחדל ו-Mesh CA. מזינים את הערכים במשתני המיקום שמופיעים.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

שירות CA

  1. פועלים לפי השלבים במאמר הגדרת Certificate Authority Service.
  2. מריצים את הפקודה הבאה כדי להתקין את מישור הבקרה עם תכונות ברירת מחדל ועם Certificate Authority Service. מזינים את הערכים במשתני המיקום שמופיעים.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

הכלי מוריד את כל הקבצים להגדרת מישור הבקרה המנוהל אל --output_dir שצוין, מתקין את הכלי istioctl ואת אפליקציות הדוגמה. השלבים במדריך הזה מניחים שאתם מריצים את istioctl מהמיקום --output_dir שציינתם כשאתם מריצים את asmcli install, וש-istioctl נמצא בספריית המשנה <Istio release dir>/bin שלו.

אם מריצים מחדש את asmcli באותו אשכול, הוא מחליף את ההגדרה הקיימת של מישור הבקרה. כדי לקבל את אותה ההגדרה, צריך לציין את אותן האפשרויות והדגלים.

אימות הקצאת מישור הבקרה

אחרי כמה דקות, מוודאים שסטטוס מישור הבקרה הוא ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

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

שדרוגים ללא מגע

אחרי שמתקינים את מישור הבקרה המנוהל, Google תשדרג אותו באופן אוטומטי כשיהיו גרסאות חדשות או תיקוני באגים זמינים.

מישור נתונים מנוהל

אם אתם משתמשים ב-Cloud Service Mesh מנוהל, Google מנהלת באופן מלא את השדרוגים של ה-proxy שלכם.

כשהתכונה 'מישור נתונים מנוהל' מופעלת, שרתי ה-proxy של sidecar והשערים המוזרקים מתעדכנים באופן פעיל ואוטומטי בשילוב עם מישור הבקרה המנוהל, על ידי הפעלה מחדש של עומסי העבודה כדי להזריק מחדש גרסאות חדשות של ה-proxy. התהליך הזה מתחיל אחרי שדרוג מישור הבקרה, ובדרך כלל מסתיים תוך שבועיים מתחילתו.

אם המדיניות מושבתת, ניהול ה-proxy מתבצע באופן פסיבי – הוא מונע על ידי מחזור החיים הטבעי של ה-pods באשכול, והמשתמש צריך להפעיל אותו באופן ידני כדי לשלוט בקצב העדכון.

מישור הנתונים המנוהל משדרג את ה-proxy על ידי הוצאת פודים שמופעלות בהם גרסאות קודמות של ה-proxy. הפינויים מתבצעים בהדרגה, בהתאם לתקציב לשיבוש Pod, ובקצב שינוי מבוקר.

מידע נוסף זמין במאמר בנושא מישור נתונים מנוהל.

הגדרת גילוי נקודות קצה (רק בהתקנות מרובות אשכולות)

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

לפני שממשיכים, צריך לוודא ש-Cloud Service Mesh מוגדר בכל אשכול.

אשכולות ציבוריים

הגדרת גילוי נקודות קצה בין אשכולות ציבוריים

אם אתם פועלים באשכולות ציבוריים (אשכולות לא פרטיים), אתם יכולים להגדיר גילוי נקודות קצה בין אשכולות ציבוריים או פשוט להפעיל גילוי נקודות קצה בין אשכולות ציבוריים.

אשכולות פרטיים

הגדרת גילוי נקודות קצה בין אשכולות פרטיים

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

דוגמה לאפליקציה עם שני אשכולות מופיעה במאמר דוגמה לשירות HelloWorld.

פריסת אפליקציות

מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.

מנוהל (TD)

  1. מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

מנוהל (Istiod)

מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:

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

    kubectl -n istio-system get controlplanerevision

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

    NAME                AGE
asm-managed-rapid   6d7h

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

    בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.

  2. החלת תווית הגרסה על מרחב השמות:

    kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

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

  kubectl get namespace -L istio-injection

פלט לדוגמה:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

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

התאמה אישית של ההטמעה (אופציונלי)

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

אפשר לשנות את האפשרויות האלה ב-pods ספציפיים באמצעות הגדרה לכל pod. כדי לעשות את זה, מוסיפים מאגר תגים istio-proxy ל-pod. הזרקת ה-sidecar תתייחס לכל הגדרה שמוגדרת כאן כהחלפה של תבנית ההזרקה שמוגדרת כברירת מחדל.

לדוגמה, ההגדרה הבאה משנה מגוון הגדרות, כולל הפחתת בקשות המעבד, הוספת נקודת טעינה של נפח והוספת וו preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

באופן כללי, אפשר להגדיר כל שדה בתרמיל. עם זאת, צריך לשים לב לשדות מסוימים:

  • ב-Kubernetes, צריך להגדיר את השדה image לפני שההזרקה מופעלת. אפשר להגדיר תמונה ספציפית שתחליף את ברירת המחדל, אבל מומלץ להגדיר את image ל-auto. כך, כלי ה-injector של ה-sidecar יבחר באופן אוטומטי את התמונה לשימוש.
  • חלק מהשדות ב-containers תלויים בהגדרות קשורות. לדוגמה, הערך חייב להיות קטן ממגבלת השימוש במעבד או שווה לה. אם שני השדות לא מוגדרים בצורה תקינה, יכול להיות שהפוד לא יופעל.
  • ב-Kubernetes אפשר להגדיר גם requests וגם limits למשאבים ב-Pod spec. ב-GKE Autopilot נלקח בחשבון רק requests. מידע נוסף זמין במאמר בנושא הגדרת מגבלות משאבים ב-Autopilot.

בנוסף, אפשר להגדיר שדות מסוימים באמצעות הערות ב-Pod, אבל מומלץ להשתמש בגישה שלמעלה כדי להתאים אישית את ההגדרות. חשוב לשים לב במיוחד להערות הבאות:

  • ב-GKE Standard, אם ההגדרה sidecar.istio.io/proxyCPU מוגדרת, חשוב להגדיר באופן מפורש את sidecar.istio.io/proxyCPULimit. אחרת, מגבלת המעבד של ה-sidecar תוגדר כבלתי מוגבלת.
  • ב-GKE Standard, אם sidecar.istio.io/proxyMemory מוגדר, צריך להגדיר באופן מפורש את sidecar.istio.io/proxyMemoryLimit. אחרת, מגבלת הזיכרון של ה-sidecar תוגדר כבלתי מוגבלת.
  • ב-GKE Autopilot, הגדרת משאבים requests ו-limits באמצעות הערות עשויה להוביל להקצאת יתר של משאבים. כדי להימנע מכך, אפשר להשתמש בגישה של תבנית תמונה. דוגמאות לשינוי משאבים ב-Autopilot

לדוגמה, אפשר לראות את ההערה על מקורות המידע הבאים:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

אימות המדדים של מישור הבקרה

אפשר לראות את הגרסה של מישור הבקרה ומישור הנתונים ב-Metrics Explorer.

כדי לוודא שההגדרה פועלת כמצופה:

  1. במסוף Google Cloud , צופים במדדים של מישור הבקרה:

    לדף Metrics Explorer

  2. בוחרים את סביבת העבודה ומוסיפים שאילתה מותאמת אישית באמצעות הפרמטרים הבאים:

    • Resource type: Kubernetes Container
    • מדד: לקוחות שרת proxy
    • מסנן: container_name="cr-REVISION_LABEL"
    • Group By: revision label and proxy_version label
    • פונקציית אגרגציה: sum
    • תקופה: דקה אחת

    כשמריצים את Cloud Service Mesh עם מישור בקרה בניהול Google ומישור בקרה בתוך האשכול, אפשר להבחין בין המדדים לפי שם המאגר שלהם. לדוגמה, למדדים מנוהלים יש container_name="cr-asm-managed", ולמדדים לא מנוהלים יש container_name="discovery". כדי להציג מדדים משני המקורות, צריך להסיר את המסנן ב-container_name="cr-asm-managed".

  3. כדי לאמת את הגרסה של מישור הבקרה ואת גרסת ה-proxy, בודקים את השדות הבאים ב-Metrics Explorer:

    • השדה revision מציין את הגרסה של מישור הבקרה.
    • השדה proxy_version מציין את proxy_version.
    • בשדה value מצוין מספר השרתים הפרוקסי המחוברים.

    במאמר גרסאות Cloud Service Mesh לפי ערוץ מפורטת המיפוי הנוכחי של ערוצים לגרסאות Cloud Service Mesh.

העברת אפליקציות ל-Cloud Service Mesh מנוהל

הכנות להעברה

כדי להתכונן להעברת אפליקציות מ-Cloud Service Mesh בתוך אשכול ל-Cloud Service Mesh מנוהל, מבצעים את השלבים הבאים:

  1. מריצים את הכלי כמו שמתואר בקטע החלת מישור הבקרה שמנוהל על ידי Google.

  2. (אופציונלי) אם רוצים להשתמש במישור הנתונים שמנוהל על ידי Google, מפעילים את ניהול מישור הנתונים:

      kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

העברת אפליקציות

כדי להעביר אפליקציות מ-Cloud Service Mesh בתוך האשכול ל-Cloud Service Mesh מנוהל, צריך לבצע את השלבים הבאים:

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

מנוהל (TD)

  1. מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

מנוהל (Istiod)

מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:

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

    kubectl -n istio-system get controlplanerevision

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

    NAME                AGE
asm-managed-rapid   6d7h

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

    בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.

  2. החלת תווית הגרסה על מרחב השמות:

    kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

  1. מבצעים שדרוג הדרגתי של פריסות במרחב השמות:

    kubectl rollout restart deployment -n NAMESPACE

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

  3. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים הקודמים לכל מרחב שמות.

  4. אם פרסתם את האפליקציה בהגדרה מרובת אשכולות, שכפלו את התצורה של Kubernetes ו-Istio בכל האשכולות, אלא אם אתם רוצים להגביל את התצורה הזו לקבוצת משנה של אשכולות בלבד. ההגדרה שחלה על אשכול מסוים היא מקור המידע האמין לגבי האשכול הזה.

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

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

מחיקת מישור הבקרה הישן

אחרי שמתקינים את מישור הבקרה שמנוהל על ידי Google ומוודאים שכל מרחבי השמות משתמשים בו, אפשר למחוק את מישור הבקרה הישן.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

אם השתמשתם ב-istioctl kube-inject במקום בהזרקה אוטומטית, או אם התקנתם שערים נוספים, כדאי לבדוק את המדדים של מישור הבקרה ולוודא שמספר נקודות הקצה המחוברות הוא אפס.

הוחזר למצב קודם

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

  1. מעדכנים את עומסי העבודה כך שיוזרקו עם הגרסה הקודמת של רמת הבקרה. בפקודה הבאה, ערך הגרסה asm-191-1 משמש רק כדוגמה. מחליפים את הערך לדוגמה בתווית הגרסה של מישור הבקרה הקודם.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite

  2. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההחדרה, כך שלפרוקסי תהיה הגרסה הקודמת:

    kubectl rollout restart deployment -n NAMESPACE

מישור הבקרה המנוהל יתבצע אוטומטית בהתאמה ל-0 ולא ישתמש בשום משאב כשלא יהיה בשימוש. ה-webhooks וההקצאה של משאבים לשינוי יישארו ולא ישפיעו על התנהגות האשכול.

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

kubectl -n istio-system rollout undo deploy istio-ingressgateway

אם הפעולה תצליח, הפלט יהיה:

deployment.apps/istio-ingressgateway rolled back

הסרה

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

פתרון בעיות

כדי לזהות ולפתור בעיות כשמשתמשים במישור בקרה מנוהל, אפשר לעיין במאמר פתרון בעיות במישור בקרה מנוהל.

מה השלב הבא?