‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

חברי Fleet והמסוף

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

כל האשכולות נרשמים ל-Fleet בזמן היצירה:

כשיוצרים אשכול באמצעות bmctl, מציינים את פרויקט המארח של ה-Fleet בקטע gkeConnect של קובץ ההגדרות של האשכול. האשכול הופך לחבר ב-Fleet של הפרויקט שצוין.
כשיוצרים אשכול אדמין או אשכול משתמשים באמצעות לקוח API רגיל של GKE On-Prem (המסוף, Google Cloud CLI או Terraform), האשכול הופך לחבר בצי בפרויקט שצוין.

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

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

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

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

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

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

מעבר לאשכולות GKE
בוחרים את הפרויקט Google Cloud .
- אם Bare metal מוצג בעמודה Type, המשמעות היא שהאשכול מנוהל על ידי GKE On-Prem API. הערה: רק אשכולות אדמין ואשכולות משתמשים יכולים להיות מנוהלים על ידי GKE On-Prem API.
- אם הערך External מוצג בעמודה Type, המשמעות היא שהאשכול לא מנוהל על ידי GKE On-Prem API.

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

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

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

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

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

הכניסה באמצעות חשבון Google היא הדרך הכי פשוטה לאימות במסוף, ולכן אנחנו מסבירים בפירוט איך להגדיר אותה במאמר הגדרת אימות באמצעות חשבון Google.
‫OpenID Connect (OIDC): האפשרות הזו מאפשרת לכם להתחבר לאשכולות מהמסוף באמצעות הזהות שלהם מספק זהויות של צד שלישי מסוג OIDC, כמו Okta או Microsoft AD FS. כדאי להשתמש באפשרות הזו אם למשתמשים שלכם יש שמות משתמש, סיסמאות וחברות בקבוצות אבטחה קיימים מהספק שלכם. במדריכים הבאים מוסבר איך להגדיר אימות OIDC של צד שלישי עבור האשכולות:
- הגדרת אשכולות ל-GKE Identity Service באמצעות OIDC: במדריך הזה מוסבר איך להגדיר אימות OIDC באשכול על בסיס אשכול.
- הגדרה של GKE Identity Service לצי: האפשרות הזו מאפשרת להגדיר OIDC ברמת הצי.
אסימון Bearer: אם הפתרונות הקודמים שסופקו על ידי Google לא מתאימים לארגון שלכם, אתם יכולים להגדיר אימות באמצעות חשבון שירות של Kubernetes ולהשתמש באסימון ה-Bearer שלו כדי להיכנס. פרטים נוספים זמינים במאמר בנושא הגדרה באמצעות אסימון bearer.

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

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

כדי לאפשר למשתמשים לגשת למסוף, צריך להקצות לפחות את התפקידים הבאים:
- ‫roles/container.viewer: התפקיד הזה מאפשר למשתמשים לצפות בדף GKE Clusters (אשכולות GKE) ובמשאבי קונטיינרים אחרים במסוף. לפרטים על ההרשאות שכלולות בתפקיד הזה, או כדי להעניק תפקיד עם הרשאות קריאה וכתיבה, אפשר לעיין במאמר תפקידים ב-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 PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

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

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

where:

‫PROJECT_ID הוא פרויקט המארח של ה-Fleet. במקרה של אשכולות שנוצרו באמצעות bmctl, זהו הפרויקט שהגדרתם בקטע gkeConnect של קובץ ההגדרות של אשכול המשתמשים. עבור אשכולות שנוצרו במסוף, זהו הפרויקט שבחרתם כשנוצר האשכול.
‫MEMBER היא כתובת האימייל של המשתמש בפורמט user:emailID, לדוגמה: user:alice@example.com

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

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

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

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

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

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

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

יצרתם את אשכול המשתמשים במסוף.
יצרתם את אשכול המשתמשים באמצעות ה-CLI של gcloud, וחשבון Google שלכם צוין בדגל --admin-users בפקודה ליצירת האשכול.
יצרתם את אשכול המשתמשים באמצעות Terraform וחשבון Google שלכם צוין בשדה authorization.admin_users.username.
יצרתם את אשכול המשתמשים באמצעות bmctl והגדרתם את חשבון Google ב-clusterSecurity.authorization.clusterAdmin.gcpAccounts.

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

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

שימו לב: אם יצרתם אשכול אדמין במסוף Google Cloud , תקבלו גישת קריאה בלבד לאשכול. כדי לקבל את התפקיד clusterrole/cluster-admin, מישהו עם התפקיד הזה יצטרך להוסיף אתכם באמצעות הפקודה gcloud ... generate-gateway-rbac.

`generate-gateway-rbac`

כדי להחיל את מדיניות RBAC על משתמשים, פועלים לפי השלבים הבאים בתחנת העבודה של האדמין:

מריצים את הפקודה הבאה כדי לעדכן רכיבים (אם צריך):
```
gcloud components update
```
יוצרים את מדיניות ה-RBAC ומחילים אותה על האשכול עבור משתמשים וחשבונות שירות:
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MEMBERSHIP_NAME: השם שמשמש לייצוג ייחודי של האשכול בצי. ב-Google Distributed Cloud, שם החברות ושם האשכול זהים.
- ‫ROLE: תפקיד Kubernetes שרוצים להקצות למשתמשים באשכול. כדי להעניק למשתמשים גישה מלאה לכל משאב באשכול בכל מרחבי השמות, מציינים clusterrole/cluster-admin. כדי לספק גישת קריאה בלבד, מציינים clusterrole/view. כדי להגביל את הגישה, יוצרים תפקיד בהתאמה אישית, לדוגמה: role/mynamespace/namespace-reader. התפקיד המותאם אישית צריך כבר להתקיים לפני שמריצים את הפקודה.
- ‫USERS: כתובות האימייל של המשתמשים (חשבונות משתמשים או חשבונות שירות) שרוצים להעניק להם את ההרשאות, כרשימה מופרדת בפסיקים. לדוגמה: --users=222larabrown@gmail.com,test-acct@test-project.iam.gserviceaccount.com.
- ‫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`

מריצים את הפקודה הבאה כדי לעדכן את הרכיבים:
```
gcloud components update
```
לכל משתמש שרוצים להעניק לו את התפקיד clusterrole/cluster-admin, כוללים את הדגל --admin-users ומריצים את הפקודה הבאה. אי אפשר לציין כמה משתמשים בדגל אחד. חשוב לכלול את חשבון Google בפקודה, כי הפקודה מחליפה את רשימת ההרשאות במשתמשים שצוינו בפקודה.
```
gcloud container bare-metal clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

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

bmctl

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

מוסיפים את הקטע clusterSecurity.authorization לקובץ התצורה של האשכול. מציינים את כתובת האימייל שלכם ושל משתמשים אחרים שצריכים לנהל את האשכול. לדוגמה:
```
...
clusterSecurity:
  authorization:
    clusterAdmin:
      gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com]
...
```
הערה: השדה הזה רלוונטי רק לאשכולות שיכולים להריץ עומסי עבודה. אי אפשר לציין gcpAccounts עבור אשכולות אדמין.
מעדכנים את האשכול:
```
bmctl update cluster \
    -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG
```
צריך לבצע את השינויים הבאים:
- מחליפים את CLUSTER_NAME בשם של האשכול שרוצים לעדכן.
- אם האשכול הוא אשכול בניהול עצמי (כמו אשכול אדמין או אשכול עצמאי), מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של האשכול. אם האשכול הוא אשכול משתמשים, מחליפים את KUBECONFIG בנתיב לקובץ ה-kubeconfig של אשכול האדמין.

המסוף

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

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

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