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

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

חברי הצי והמסוף

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

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

  • כשיוצרים אשכול באמצעות bmctl, מציינים את פרויקט המארח של ה-Fleet בקטע gkeConnect של קובץ התצורה של האשכול. האשכול הופך לחבר ב-Fleet של הפרויקט שצוין.

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

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

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

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

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

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

כדי לראות את אשכולות הצי:

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

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

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

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

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

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

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

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

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

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

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

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

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

הגישה למסוף נשלטת על ידי ניהול זהויות והרשאות גישה (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 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 על משתמשים, מבצעים את השלבים הבאים בתחנת העבודה של האדמין:

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

    gcloud components update

  2. יוצרים ומחילים את מדיניות ה-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

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

    gcloud components update

  2. לכל משתמש שצריך להעניק לו את התפקיד 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 \

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

bmctl

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

  1. מוסיפים את הקטע clusterSecurity.authorization לקובץ התצורה של האשכול. מציינים את כתובת האימייל שלכם ושל משתמשים אחרים שצריכים לנהל את האשכול. לדוגמה:

    ...
clusterSecurity:
  authorization:
    clusterAdmin:
      gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com]
...

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

    bmctl update cluster \
    -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG

    צריך לבצע את השינויים הבאים:

    • מחליפים את CLUSTER_NAME בשם של האשכול שרוצים לעדכן.
    • אם האשכול הוא אשכול בניהול עצמי (כמו אשכול אדמין או אשכול עצמאי), מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של האשכול. אם האשכול הוא אשכול משתמשים, מחליפים את KUBECONFIG בנתיב לקובץ ה-kubeconfig של אשכול האדמין.

המסוף

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

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

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

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

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

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

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

מידע נוסף