הקצאת 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, פרוקסי ו-Istio CRD) יושקו קודם לאשכולות שרשומים לערוץ המהיר של GKE. לאחר מכן, הן יועברו לערוץ הרגיל של GKE, ולבסוף לערוץ היציב של GKE, אחרי שיוכח שהן יציבות מספיק.
    • השיטה המומלצת היא להקצות קבוצת משנה של אשכולות הצי בערוץ הפצה מוקדם יותר של GKE, כדי להבטיח שהם יקבלו עדכונים לרכיבי Cloud Service Mesh ראשונים.
    • שירות Cloud Service Mesh המנוהל לא תומך בשינוי ערוצי ההפצה של GKE.
    • אם תשנו את ערוץ ההפצה של GKE,‏ Cloud Service Mesh לא ימנע את הפעולה. ‫Cloud Service Mesh מעדכן אוטומטית את הרכיבים בתוך האשכול (CNI, ‏ MDPC, גרסת ה-proxy המוזרקת כברירת מחדל ו-CRD של Istio) כדי להתאים לערוץ ההפצה הנוכחי של GKE.
  • מוודאים שיש באשכול מספיק קיבולת לרכיבים הנדרשים ש-Cloud Service Mesh מנוהל מתקין באשכול.
    • הפריסה mdp-controller במרחב השמות kube-system מבקשת מעבד:‎50m, זיכרון: ‎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

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

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

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

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

שם התפקיד מזהה תפקיד אישור גישה למיקום תיאור
סוכן שירות של Anthos Service Mesh roles/anthosservicemesh.serviceAgent פרויקט Fleet
סוכן שירות של מישור בקרה מנוהל של Mesh (מאמר שמתייחס לגרסה קודמת) 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

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

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

CA Service

  1. פועלים לפי השלבים במאמר בנושא הגדרת שירות רשות האישורים.
  2. מריצים את הפקודה הבאה כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ועם Certificate Authority Service. מזינים את הערכים ב-placeholders שמופיעים.
  ./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, ובקצב שינוי מבוקר.

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

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

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

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

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

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

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

אפשר לשנות את ההגדרות האלה ב-pods ספציפיים באמצעות הגדרה לכל pod. כדי לעשות את זה, מוסיפים istio-proxyמאגר לתא. החדרת ה-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

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

  • ב-Kubernetes, צריך להגדיר את השדה image לפני שההזרקה מופעלת. אפשר להגדיר תמונה ספציפית שתחליף את תמונת ברירת המחדל, אבל מומלץ להגדיר את image ל-auto. כך, רכיב להחדרת 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
    • Aggregator: 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

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

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

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

הפלט הצפוי במקרה של הצלחה:

deployment.apps/istio-ingressgateway rolled back

הסרה

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

פתרון בעיות

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

מה השלב הבא?