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

  • במקרה של אשכולות 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 ושערי הכניסה (gateways) שמוזרקים מתעדכנים באופן פעיל ואוטומטי בשילוב עם מישור הבקרה המנוהל, על ידי הפעלה מחדש של עומסי העבודה כדי להזריק מחדש גרסאות חדשות של ה-proxy. התהליך הזה מתחיל אחרי שדרוג מישור הבקרה, ובדרך כלל מסתיים תוך שבועיים מתחילתו.

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

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

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

כשפורסים גרסאות חדשות של מישור הנתונים של Cloud Service Mesh

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

‫1 עדכונים פעילים של Cloud Service Mesh מחליפים באופן אוטומטי את Pods בעומסי עבודה, למעט StatefulSets,‏ Jobs,‏ DaemonSets ו-Pods שהוחדרו באופן ידני. עדכונים פעילים של Cloud Service Mesh מכבדים תקציבי שיבוש של Pod.

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

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

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

ההתראות לגבי פעולות תחזוקה לא נשלחות כברירת מחדל. מידע נוסף מופיע בקטע הפעלת התראות על תחזוקה במישור הנתונים המנוהל במסמך הזה.

מגבלות

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

  • פודים שלא הוזרקו
  • הוספת pods באופן ידני
  • תעסוקה
  • StatefulSets
  • DaemonSets

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

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

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

יכולות לעבור עד עשר דקות עד שהשירות יהיה מוכן לנהל את שרתי ה-proxy באשכול. מריצים את הפקודה הבאה כדי לבדוק את הסטטוס:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

הפלט הצפוי

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

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

השבתה של מישור הנתונים המנוהל (אופציונלי)

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

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

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

    kubectl get controlplanerevisions -n istio-system

  2. כדי לשנות את ההערה:

    kubectl annotate --overwrite controlplanerevision CONTROL_PLANE_REVISION_NAME -n istio-system mesh.cloud.google.com/proxy='{"managed":"false"}'

    חוזרים על השלב הזה לכל עדכון של מישור הבקרה.

    מחליפים את CONTROL_PLANE_REVISION_NAME בפלט מהפקודה הקודמת.

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

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

כדי להשבית את מישור הנתונים המנוהל עבור פוד:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

הפעלת חלונות תחזוקה למישור הנתונים המנוהל

אם הגדרתם חלון זמן לתחזוקה ב-GKE, השדרוגים הפעילים יתחילו בתחילת חלון זמן לתחזוקה הבא שזמין וימשיכו ללא הפסקה עד שכל ה-Pods המנוהלים יעודכנו (בדרך כלל 12 שעות). חלון הזמן לתחזוקה לא חל על השקות שקשורות ל-CVE.

‫Cloud Service Mesh משתמש בחלון זמן לתחזוקה של GKE כדי להתאים את עצמו ל-GKE.

הפעלת התראות על תחזוקה במישור הנתונים המנוהל

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

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

  1. עוברים לדף תקשורת.

    כניסה לדף Communication

  2. בשורה Cloud Service Mesh Upgrade, בעמודה Email, לוחצים על לחצן הבחירה כדי להפעיל את ההתראות על תחזוקה (ON).

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

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

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

Subject Line: Upcoming upgrade for your Cloud Service Mesh cluster "<location/cluster-name>"

שלום, משתמש Cloud Service Mesh,

רכיבי Cloud Service Mesh באשכול ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) מתוזמנים לשדרוג בתאריך ${scheduled_date_human_readable} בשעה ${scheduled_time_human_readable}.

בהערות המוצר (https://cloud.google.com/service-mesh/docs/release-notes) מוסבר על העדכון החדש.

אם עבודות התחזוקה יבוטלו, נעדכן אותך באימייל נוסף.

בברכה,

צוות Cloud Service Mesh

‫(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 שלחנו אליך את ההודעה הזו כדי למסור לך עדכון חשוב בקשר לשינויים ב-Google Cloud Platform או בחשבון שלך. לא רוצה לקבל התראות בקשר לחלונות זמנים לתחזוקה? אפשר תמיד לשנות את ההעדפות שלך: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

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

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

לפני שממשיכים, מוודאים ש-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 ל-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

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

  • ב-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. כדי לבדוק את הגרסה של Control Plane ואת גרסת ה-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. כדי לבצע Rollback, מריצים מחדש את פקודת ההתקנה של Cloud Service Mesh, שתפרוס מחדש את השער ותחזיר אותו למישור הבקרה בתוך האשכול:

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

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

deployment.apps/istio-ingressgateway rolled back

הסרה

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

פתרון בעיות

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

מה השלב הבא?