ניהול אשכולות ממסוף Google Cloud

במאמר הזה מוסבר איך להפוך אשכולות שנוצרו באמצעות תוכנת Google Distributed Cloud ל-VMware לזמינים לניהול במסוף Google Cloud . המאמר כולל ניהול בסיסי, כמו אפשרות להתחבר לאשכולות ולראות את עומסי העבודה שלהם, וגם הסבר על הפעלת ניהול מחזור החיים של האשכולות כדי שתוכלו לשדרג, לעדכן ולמחוק אשכולות.

חברי Fleet והמסוף

כל האשכולות של Google Distributed Cloud צריכים להיות חלק מצי – דרך מאוחדת להצגה ולניהול של כמה אשכולות ועומסי העבודה שלהם. כל Fleet של אשכולות משויך לפרויקט מארח של Fleet.

ב-Google Distributed Cloud, אשכול אדמין נרשם ל-Fleet בזמן היצירה על ידי ציון פרויקט המארח של ה-Fleet בקטע gkeConnect של קובץ ההגדרות של האשכול. ‫Google Distributed Cloud משתמש במידע הזה כדי לרשום את האשכול לפרויקט הצי שצוין. אם ההרשמה נכשלה, אפשר לנסות להירשם שוב על ידי הפעלת הפקודה gkectl update credentials register.

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

ב-Google Distributed Cloud, אשכול משתמשים נרשם לצי בשלב היצירה:

  • כשיוצרים אשכול משתמשים באמצעות gkectl, מציינים את פרויקט המארח של ה-Fleet בקטע gkeConnect של קובץ הגדרת האשכול. ‫Google Distributed Cloud משתמש במידע הזה כדי לרשום את האשכול לפרויקט הצי שצוין.

  • כשיוצרים אשכול משתמשים באמצעות כלי רגיל (המסוף, Google Cloud CLI או Terraform), האשכול הופך אוטומטית לחבר בצי בפרויקט שמציינים.

חברי ה-Fleet מחוץ ל- Google Cloud כמו Google Distributed Cloud מוצגים במסוף בפרויקט המארח של ה-Fleet, יחד עם אשכולות אחרים של ה-Fleet כמו GKE ב- Google Cloud. היקף האפשרויות לניהול Google Distributed Cloud מהמסוף תלוי בגורמים הבאים:

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

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

הצגת אשכולות רשומים

כל האשכולות בצי מוצגים בדף Google Kubernetes Engine clusters overview במסוף. כך תוכלו לקבל סקירה כללית של כל צי המכונות שלכם, וב-Google Distributed Cloud תוכלו לראות אילו אשכולות מנוהלים על ידי GKE On-Prem API.

כדי לראות את אשכולות ה-Fleet:

  1. במסוף, נכנסים לדף Google Kubernetes Engine clusters overview.

    מעבר לאשכולות GKE

  2. בוחרים את הפרויקט Google Cloud .

    • אם vm Google Distributed Cloud מוצג בעמודה Type, המשמעות היא שהאשכול מנוהל על ידי GKE On-Prem API.

    • אם הערך External מוצג בעמודה Type, המשמעות היא שהאשכול לא מנוהל על ידי GKE On-Prem API.

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

מגדירים אימות

כמו שמתואר למעלה, כל האשכולות של Fleet מופיעים ברשימות של אשכולות GKE במסוף. עם זאת, כדי לראות פרטים נוספים כמו צמתים ועומסי עבודה (ולבצע משימות של ניהול מחזור החיים של האשכול אם התכונה מופעלת), המשתמשים צריכים להתחבר לאשכול ולבצע אימות. כדי לעשות זאת, צריך להגדיר את האשכולות הרשומים באמצעות אחת משיטות האימות הבאות:

  • זהות Google: האפשרות הזו מאפשרת למשתמשים להתחבר באמצעותGoogle Cloud הזהות שלהם, שהיא כתובת האימייל שמשויכת לחשבוןGoogle Cloud . משתמשים באפשרות הזו אם למשתמשים כבר יש גישה ל-Google Cloud עם הזהות שלהם ב-Google. אם יצרתם את האשכול במסוף, אתם יכולים להתחבר לאשכול באמצעות הזהות שלכם ב-Google, אבל תצטרכו להגדיר אימות למשתמשים אחרים.

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

  • ‫OpenID Connect (OIDC): האפשרות הזו מאפשרת למשתמשים להתחבר לאשכולות מהמסוף באמצעות הזהות שלהם מספק זהויות OIDC של צד שלישי, כמו Okta או Microsoft AD FS. כדאי להשתמש באפשרות הזו אם למשתמשים שלכם יש שמות משתמש, סיסמאות וחברות בקבוצות אבטחה קיימים מהספק שלכם. במדריכים הבאים מוסבר איך להגדיר אימות OIDC של צד שלישי עבור האשכולות:

  • אסימון Bearer: אם הפתרונות הקודמים שסופקו על ידי Google לא מתאימים לארגון שלכם, אתם יכולים להגדיר אימות באמצעות חשבון שירות של Kubernetes ולהשתמש באסימון ה-Bearer שלו כדי להיכנס. פרטים נוספים זמינים במאמר בנושא הגדרה באמצעות אסימון bearer.

מתן התפקידים הנדרשים

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

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

    • ‫roles/container.viewer. התפקיד הזה מאפשר למשתמשים לראות את הדף GKE Clusters ואת משאבי הקונטיינר האחרים במסוף. לפרטים על ההרשאות שכלולות בתפקיד הזה, או כדי להעניק תפקיד עם הרשאות קריאה/כתיבה, אפשר לעיין במאמר תפקידים ב-Kubernetes Engine במסמכי ה-IAM.

    • roles/gkehub.viewer. התפקיד הזה מאפשר למשתמשים להציג אשכולות מחוץ ל-Google Cloud במסוף. פרטים על ההרשאות שכלולות בתפקיד הזה, או על הענקת תפקיד עם הרשאות קריאה/כתיבה, זמינים במאמר תפקידים ב-GKE Hub במאמרי העזרה בנושא IAM.

  • כדי לאפשר למשתמשים לנהל את מחזור החיים של האשכול במסוף, צריך להעניק את תפקיד ה-IAM‏ roles/gkeonprem.admin. התפקיד roles/gkeonprem.admin מעניק למשתמשים גישת אדמין ל-GKE On-Prem API, שמשמש את המסוף לניהול מחזור החיים של האשכול. במאמר תפקידים ב-GKE On-Prem שבמסמכי IAM מפורטות ההרשאות שכלולות בתפקיד הזה.

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

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

where:

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

  • ‫MEMBER היא כתובת האימייל של המשתמש בפורמט user:emailID, לדוגמה: user:alice@example.com

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

אשכולות משתמשים שנוצרו באמצעות כלים סטנדרטיים (המסוף, ה-CLI של gcloud או Terraform) נרשמים אוטומטית ל-GKE On-Prem API, ומאפשרים לכם לבצע במסוף משימות של ניהול מחזור החיים של האשכול. אם רוצים להפעיל את התכונה הזו באשכולות משתמשים שנוצרו באמצעות gkectl, צריך לפעול לפי השלבים במאמר הגדרת אשכול משתמשים לניהול באמצעות GKE On-Prem API. כשניהול מחזור החיים של האשכול מופעל, אפשר לבצע את המשימות הבאות במסוף:

הגדרת אימות זהות באמצעות Google

כדי לאפשר למשתמשים להתחבר לאשכול באמצעות הזהות שלהם ב-Google, צריך להגדיר את הדברים הבאים:

הגדרת הרשאות RBAC

שרת ה-API של Kubernetes בכל אשכול צריך להיות מסוגל לאשר בקשות שמגיעות מהמסוף. כדי להגדיר הרשאה, צריך להגדיר מדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes בכל אשכול.

אם השתמשתם בכלי רגיל כדי ליצור את אשכול המשתמשים, יכול להיות שכבר קיבלתם את כללי המדיניות המתאימים של RBAC שמעניקים לכם גישת ניהול מלאה לאשכול. ‫GKE On-Prem API מוסיף את חשבון Google שלכם באופן אוטומטי כמנהל במקרים הבאים:

  • יצרתם את אשכול המשתמשים במסוף.

  • יצרתם את אשכול המשתמשים באמצעות ה-CLI של gcloud, וחשבון Google שלכם צוין בדגל --admin-users בפקודה ליצירת האשכול.

  • יצרתם את אשכול המשתמשים באמצעות Terraform וחשבון Google שלכם צוין בשדה authorization.admin_users.username.

באשכולות משתמשים שנוצרו באמצעות gkectl לא מוענקות לכם הרשאות RBAC לניהול האשכול באמצעות המסוף. צריך להוסיף את עצמכם אחרי שיוצרים את האשכול. לא משנה באיזה כלי השתמשתם כדי ליצור את האשכול, אתם יכולים להוסיף עוד מנהלי מערכת אחרי שהאשכול נוצר.

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

  • צריך להריץ את הפקודה gcloud ... generate-gateway-rbac בתחנת העבודה של האדמין, כי הפקודה דורשת גישה ל-kubeconfig ולהקשר של האשכול (שבדרך כלל נמצאים רק בתחנת העבודה של האדמין). הפקודה generate-gateway-rbac מאפשרת להתאים אישית את מדיניות RBAC, אבל כתובות האימייל של המשתמשים לא יוצגו כאדמינים בקטע פרטי אשכול במסוף.

  • אפשר להריץ את הפקודה gcloud ... update בתחנת העבודה של האדמין או בכל מחשב שיש לו גישה ל-GKE On-Prem API.

generate-gateway-rbac

  1. מתחברים לתחנת העבודה של האדמין.

  2. מריצים את הפקודה הבאה כדי לעדכן את הרכיבים:

    gcloud components update

  3. יוצרים את מדיניות ה-RBAC ומחילים אותה על האשכול עבור משתמשים וחשבונות שירות:

    gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

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

    • ‫MEMBERSHIP_NAME: השם שמשמש לייצוג ייחודי של האשכול ב-Fleet. ב-Google Distributed Cloud, שם החברות ושם האשכול זהים.
    • ‫ROLE: תפקיד Kubernetes שרוצים להעניק למשתמשים באשכול. כדי להעניק למשתמשים גישה מלאה לכל משאב באשכול בכל מרחבי השמות, מציינים clusterrole/cluster-admin. כדי לספק גישת קריאה בלבד, מציינים clusterrole/view. אפשר גם ליצור תפקיד בהתאמה אישית, למשל: role/mynamespace/namespace-reader. התפקיד המותאם אישית צריך כבר להתקיים לפני שמריצים את הפקודה.
    • ‫USERS: כתובות האימייל של המשתמשים (חשבונות משתמשים או חשבונות שירות) שרוצים להעניק להם את ההרשאות, כרשימה מופרדת בפסיקים. לדוגמה: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
    • ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫KUBECONFIG_PATH: הנתיב המקומי שבו מאוחסן קובץ ה-kubeconfig שמכיל רשומה של האשכול.

    • ‫KUBECONFIG_CONTEXT: ההקשר של האשכול כפי שהוא מופיע בקובץ kubeconfig. כדי לקבל את ההקשר הנוכחי משורת הפקודה, מריצים את הפקודה kubectl config current-context. בין אם משתמשים בהקשר הנוכחי ובין אם לא, חשוב לוודא שהגישה לאשכול פועלת על ידי הפעלת פקודה פשוטה כמו:

      kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

    אחרי שמריצים את gcloud container fleet memberships generate-gateway-rbac, בסוף הפלט מופיע משהו כזה (הפלט קוצר כדי שיהיה קל לקרוא אותו):

    Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.

    זהו ההקשר לגישה לאשכול דרך שער החיבור.

    למידע נוסף על הפקודה generate-gateway-rbac, אפשר לעיין במדריך העזר ל-CLI של gcloud.

update

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

    gcloud components update

  2. לכל משתמש שרוצים להעניק לו את התפקיד clusterrole/cluster-admin, כוללים את הדגל --admin-users ומריצים את הפקודה הבאה. אי אפשר לציין כמה משתמשים בדגל אחד. חשוב לכלול את חשבון Google בפקודה, כי הפקודה מחליפה את רשימת ההרשאות במשתמשים שצוינו בפקודה.

    gcloud container vmware clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \

בנוסף להענקת התפקיד clusterrole/cluster-admin ב-Kubernetes, הפקודה מעניקה למשתמשים את הרשאות הגישה שנדרשות להם לאשכול דרך שער הגישה Connect.

המסוף

כדי להחיל את מדיניות RBAC על משתמשים, מבצעים את השלבים הבאים במסוף:

  1. במסוף, נכנסים לדף Google Kubernetes Engine clusters overview.

    מעבר לאשכולות GKE

  2. בוחרים את הפרויקט Google Cloud שבו נמצא אשכול המשתמשים.

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

  4. בקטע הרשאה, לוחצים על לחצן העריכה משתמשי אדמין.

  5. מזינים את כתובת האימייל של המשתמש שרוצים להוסיף כמנהל אשכול בלוח עריכת הרשאות. כדי להוסיף משתמשים נוספים עם הרשאות אדמין, לוחצים על הוספת משתמש עם הרשאות אדמין.

  6. כשמסיימים להוסיף משתמשים, לוחצים על שמירת השינויים.

מידע נוסף