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

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

בדף הזה מוסבר איך להשתמש ב-API של Fleet כדי להגדיר Cloud Service Mesh מנוהל באמצעות ממשקי Istio API.

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

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

דרישות

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

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

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

    • אם מצטרפים לאשכולות שלא נמצאים באותו פרויקט, הם צריכים להיות רשומים באותו פרויקט מארח של Fleet, והאשכולות צריכים להיות מוגדרים יחד בVPC משותף באותה רשת.
    • בסביבה מרובת אשכולות של פרויקט יחיד, פרויקט ה-Fleet יכול להיות זהה לפרויקט האשכול. מידע נוסף על צי רכבים זמין במאמר סקירה כללית על צי רכבים.
    • בסביבה מרובת פרויקטים, מומלץ לארח את ה-Fleet בפרויקט נפרד מפרויקטים של האשכול. אם מדיניות הארגון וההגדרה הקיימת מאפשרות זאת, מומלץ להשתמש בפרויקט ה-VPC המשותף כפרויקט המארח של Fleet. מידע נוסף זמין במאמר בנושא הגדרת אשכולות עם VPC משותף.

תפקידים שנדרשים להתקנת 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. חשוב לשים לב במיוחד לנקודות הבאות:

– כדי להשתמש ב-Certificate Authority Service (CA Service), צריך להגדיר את Cloud Service Mesh לכל אשכול. אי אפשר להשתמש ב-CA Service כשמשתמשים בהגדרת ברירת המחדל של Fleet ב-GKE Enterprise.

  • באשכולות 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.

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

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. מגדירים את gcloud (גם אם משתמשים ב-Cloud Shell).
    1. מאמתים באמצעות Google Cloud CLI, כאשר FLEET_PROJECT_ID הוא מזהה הפרויקט המארח של Fleet. בדרך כלל, התיקייה FLEET_PROJECT_ID נוצרת כברירת מחדל ויש לה את אותו שם כמו לפרויקט.

             gcloud auth login --project FLEET_PROJECT_ID

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

             gcloud components update

  7. מפעילים את ממשקי ה-API הנדרשים בפרויקט המארח של Fleet.

      gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID

הפעלת mesh.googleapis.com מפעילה את ממשקי ה-API הבאים:

API מטרה ניתן להשבית
meshconfig.googleapis.com ‫Cloud Service Mesh משתמש ב-Mesh Configuration API כדי להעביר נתוני הגדרה מהרשת שלכם אל Google Cloud. בנוסף, הפעלת Mesh Configuration API מאפשרת לכם לגשת לדפים של Cloud Service Mesh במסוף Google Cloud ולהשתמש ברשות האישורים של Cloud Service Mesh. לא
meshca.googleapis.com קשור לרשות האישורים של Cloud Service Mesh שמשמשת את Cloud Service Mesh מנוהל. לא
container.googleapis.com נדרש כדי ליצור אשכולות Google Kubernetes Engine‏ (GKE). לא
gkehub.googleapis.com נדרש כדי לנהל את רשת ה-Mesh כFleet. לא
monitoring.googleapis.com נדרש כדי ללכוד טלמטריה עבור עומסי עבודה של רשתות Mesh. לא
stackdriver.googleapis.com נדרש כדי להשתמש בממשק המשתמש של השירותים. לא
opsconfigmonitoring.googleapis.com נדרש כדי להשתמש בממשק המשתמש של Services עבור אשכולות לא מקומיים שלGoogle Cloud. לא
connectgateway.googleapis.com נדרשת כדי שמטוס הבקרה המנוהל של Cloud Service Mesh יוכל לגשת לעומסי עבודה של רשתות. כן*
trafficdirector.googleapis.com הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס. כן*
networkservices.googleapis.com הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס. כן*
networksecurity.googleapis.com הפעלת מישור בקרה מנוהל עם זמינות גבוהה וניתן להתאמה לעומס. כן*

הגדרת Cloud Service Mesh מנוהל

השלבים הנדרשים להקצאת Cloud Service Mesh מנוהל באמצעות Fleet API תלויים בהעדפה שלכם: הפעלה לכל אשכול או הפעלה כברירת מחדל לאשכולות חדשים של Fleet.

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

כדי להגדיר את Cloud Service Mesh מנוהל לכל אשכול ברשת בנפרד:

הפעלת התכונה Cloud Service Mesh fleet

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

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

רישום אשכולות ב-Fleet

  1. רישום של אשכול GKE באמצעות Fleet Workload Identity. הדגל --location הוא אזור או אזור גיאוגרפי של מחשוב (למשל us-central1-a או us-central1) עבור האשכול.

    gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID

  2. מוודאים שהאשכול רשום:

    gcloud container fleet memberships list --project FLEET_PROJECT_ID

    פלט לדוגמה:

    NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

    חשוב לשים לב לMEMBERSHIP_NAME, כי תצטרכו אותו כשתפעילו ניהול אוטומטי.

  3. אם הפרויקט של הרשת של האשכול שונה מהפרויקט המארח של צי, (לדוגמה, אם אתם משתמשים בVPC משותף), אתם צריכים לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט הצי לגשת לפרויקט הרשת. צריך לעשות את זה רק פעם אחת לפרויקט הרשת.

    נותנים לחשבונות שירות בפרויקט הצי גישה לפרויקט הרשת:

     gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent

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

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

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

     gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent

    מפעילים את Mesh API בפרויקט של האשכול:

     gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID

הגדרת Certificate Authority Service (אופציונלי)

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

הפעלת ניהול אוטומטי

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

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

where:

  • ‫MEMBERSHIP_NAME הוא שם החברות שמופיע כשאימתתם שהאשכול רשום ב-Fleet.

  • ‫MEMBERSHIP_LOCATION הוא המיקום שבו נרשמתם למינוי (אזור או global).

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

    הערך הזה יכול להיות global אם נרשמתם לפני מאי 2023, או אם ציינתם את המיקום global כשנרשמתם למועדון. אתם יכולים לבדוק את המיקום של המינוי שלכם באמצעות gcloud container fleet memberships list --project FLEET_PROJECT_ID.

ממשיכים אל אימות הקצאת מישור הבקרה.

הגדרה לכלל המכשירים בארגון

כדי להפעיל את Cloud Service Mesh מנוהל כהגדרת ברירת מחדל לצי, צריך להפעיל את מהדורת Enterprise של Google Kubernetes Engine‏ (GKE). כלומר, בכל אשכול חדש של GKE ב-Google Cloud שנרשם במהלך יצירת האשכול, יופעל Cloud Service Mesh מנוהל באשכול. מידע נוסף על הגדרות ברירת המחדל של צי הרכבים זמין במאמר ניהול תכונות ברמת צי הרכבים.

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

הפעלת Cloud Service Mesh מנוהל כהגדרת ברירת מחדל לצי ורישום אשכולות לצי במהלך יצירת האשכול תומכת רק ב-Mesh CA. אם אתם רוצים להשתמש ב-Certificate Authority Service, מומלץ להפעיל אותו לכל אשכול.

כדי להפעיל ברירות מחדל ברמת הצי ל-Cloud Service Mesh מנוהל:

המסוף

  1. נכנסים לדף Feature Manager במסוף Google Cloud .

    כניסה אל Feature Manager

  2. בחלונית Service Mesh, לוחצים על Configure (הגדרה).

  3. בודקים את ההגדרות שמועברות בירושה לכל האשכולות החדשים שיוצרים במסוף Google Cloud ונרשמים ל-Fleet.

  4. כדי להחיל את ההגדרות האלה, לוחצים על הגדרה.

  5. בתיבת הדו-שיח לאישור, לוחצים על אישור.

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

    1. ברשימה Clusters in the fleet, בוחרים את האשכולות שרוצים לסנכרן.
    2. לוחצים על סנכרון להגדרות של כל המכשירים ואז על אישור בתיבת הדו-שיח שמופיעה. הפעולה הזו יכולה להימשך כמה דקות.

gcloud

כדי להגדיר ברירות מחדל ברמת הצי באמצעות Google Cloud CLI, צריך להגדיר את ההגדרות הבאות:

  • הגדרות ברמת כלל המכשירים בארגון

    • יוצרים קובץ mesh.yaml שמכיל רק את השורה management: automatic:

      echo "management: automatic" > mesh.yaml

    • מפעילים את Cloud Service Mesh בצי:

      gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

      אם מופיעה השגיאה הבאה, צריך להפעיל את GKE Enterprise.

      ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

  • הגדרות ברמת הרשת

    • אם הפרויקט של הרשת שונה מהפרויקט המארח של צי הרכבים (לדוגמה, אם אתם משתמשים בVPC משותף), אתם צריכים לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט צי הרכבים לגשת לפרויקט הרשת. צריך לעשות את זה רק פעם אחת לפרויקט הרשת.

      נותנים לחשבונות שירות בפרויקט הצי גישה לפרויקט הרשת:

      gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

  • הגדרות ברמת האשכול

    • כשמוכנים ליצור אשכולות לשימוש עם Cloud Service Mesh, יוצרים אותם ורושמים אותם בשלב אחד באמצעות Google Cloud CLI כדי להשתמש בהגדרת ברירת המחדל. לדוגמה:

      gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION

      כדי לקבל את מספר הפרויקט של פרויקט Fleet, מריצים את הפקודה הבאה:

      gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"

      הדגל --location הוא אזור או אזור מחשוב (למשל us-central1-a או us-central1) של האשכול.

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

      מעניקים לחשבונות שירות בפרויקט Fleet הרשאה לגשת לפרויקט האשכול:

      gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

      מפעילים את Mesh API בפרויקט של האשכול:

      gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID

      מחליפים את CLUSTER_PROJECT_ID במזהה הייחודי של פרויקט האשכול. אם יצרתם את האשכול באותו פרויקט שבו יצרתם את ה-Fleet, אז CLUSTER_PROJECT_ID זהה ל-FLEET_PROJECT_ID.

ממשיכים אל אימות הקצאת מישור הבקרה.

תמיכה ב-Terraform

‫Cloud Service Mesh תומך בהקצאת משאבים באמצעות Terraform דרך מודול החברות בתכונה GKEHub.

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

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

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

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

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

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

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

הערה: שער כניסה לא נפרס אוטומטית עם מישור הבקרה. הפרדה בין פריסת שער הכניסה לבין מישור הבקרה מאפשרת לכם לנהל את השערים בסביבת ייצור. אם רוצים להשתמש בשער כניסה או בשער יציאה של Istio, אפשר לעיין במאמר בנושא פריסת שערים. אם רוצים להשתמש ב-Kubernetes Gateway API, אפשר לעיין במאמר הכנת Gateway ל-Mesh. במאמר הפעלת תכונות אופציונליות ב-Cloud Service Mesh מוסבר איך להפעיל תכונות אופציונליות אחרות.

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

אם אתם משתמשים ב-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, צריך להשבית את מישור הנתונים המנוהל.

מגבלות

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

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

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

אם אתם מקצים משאבים ל-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".

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

שורת הנושא: שדרוג קרוב של אשכול Cloud Service Mesh ‏ "<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/v1.28/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 מוגדר בכל אשכול.

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

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

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

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

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

מנוהל (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"

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

כדי להעביר אפליקציות מ-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

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