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

סקירה כללית

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

מידע על התכונות הנתמכות והמגבלות של Cloud Service Mesh מנוהל זמין במאמר תכונות נתמכות של 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 בסביבה של פרויקט יחיד ורשת יחידה, או בסביבה של כמה פרויקטים ורשת יחידה.

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

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

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

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

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

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

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

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

אם המדיניות מושבתת, ניהול ה-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}

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

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

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

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

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

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

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

deployment.apps/istio-ingressgateway rolled back

הסרה

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

פתרון בעיות

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

מה השלב הבא?