יצירת אשכול משתמשים באמצעות לקוחות GKE On-Prem API

בדף הזה מוסבר איך ליצור אשכול משתמש באמצעות מסוף Google Cloud , ה-CLI של gcloud (gcloud CLI) או Terraform.

מה זה GKE On-Prem API?

‫GKE On-Prem API הוא API שמתארח ב- Google Cloudומאפשר לנהל את מחזור החיים של האשכולות המקומיים באמצעות Terraform ואפליקציותGoogle Cloud רגילות. ‫GKE On-Prem API פועל בתשתית של Google Cloud. ‫Terraform, המסוף וה-CLI של gcloud הם לקוחות של ה-API, והם משתמשים ב-API כדי ליצור אשכולות במרכז הנתונים שלכם.

כדי לנהל את מחזור החיים של האשכולות, ה-API של GKE On-Prem צריך לאחסן מטא-נתונים על מצב האשכול ב- Google Cloud, באמצעות האזור ב-Google Cloud שציינתם כשנוצר האשכול. המטא-נתונים האלה מאפשרים ל-API לנהל את מחזור החיים של האשכול, והם לא כוללים נתונים ספציפיים לעומס העבודה.

כשיוצרים אשכול באמצעות לקוח GKE On-Prem API, מציינים פרויקט ב-Google Cloud . אחרי שיוצרים את האשכול, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שצוין. הפרויקט הזה נקרא פרויקט המארח של ה-Fleet. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.

אם אתם מעדיפים, אתם יכולים ליצור אשכול משתמשים על ידי יצירת קובץ תצורה של אשכול משתמשים ושימוש ב-bmctl, כפי שמתואר במאמר יצירת אשכול משתמשים.

אם אתם רוצים להשתמש ב-Terraform, במסוף או ב-CLI של gcloud כדי לנהל את מחזור החיים של אשכולות שנוצרו באמצעות bmctl, קראו את המאמר הגדרת אשכול משתמש לניהול באמצעות GKE On-Prem API.

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

בקטע הזה מוסבר איך יוצרים אשכול משתמש באמצעות לקוחות API של GKE On-Prem.

מתן הרשאות IAM

אם אתם לא הבעלים של הפרויקט, צריך להקצות לכם את התפקיד roles/gkeonprem.admin.

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

• roles/container.viewer.
• roles/gkehub.viewer

אחרי שיוצרים את האשכול, אם אתם לא Project Owner ואתם רוצים להשתמש בשער הקישור כדי להתחבר לאשכול המשתמש באמצעות שורת הפקודה, אתם צריכים את התפקידים הבאים:

• ‫roles/gkehub.gatewayAdmin: התפקיד הזה מאפשר גישה ל-Connect Gateway API. אם אתם צריכים רק גישת קריאה לאשכול, מספיק להשתמש ב-roles/gkehub.gatewayReader.

• ‫roles/gkehub.viewer: התפקיד הזה מאפשר לאחזר את פרטי הכניסה לאשכול.

איך נותנים גישה לפרויקטים, לתיקיות ולארגונים

ממשקי ה-API הנדרשים של Google

מוודאים שכל ממשקי ה-API הנדרשים של Google מופעלים בפרויקט המארח של הצי.

אם אתם משתמשים ב-CLI של gcloud כדי ליצור את האשכול, אתם צריכים להפעיל את GKE On-Prem API. אם אתם משתמשים במסוף כדי ליצור את האשכול, הוא מפעיל את GKE On-Prem API באופן אוטומטי.

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

דרישות מוקדמות לאשכול אדמין

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

• גישה לשרת ה-API של Kubernetes באשכול המשתמש אחרי שהוא נוצר.

• חיבור לרשת לכל הצמתים באשכול המשתמש אחרי שהוא נוצר.

• חייב להיות רשום בצי. מזהה הפרויקט שמוגדר בשדה gkeConnect.projectID של אשכול האדמין, שנקרא הפרויקט המארח של ה-fleet, חייב להיות אותו פרויקט שבו תיצרו את אשכול המשתמשים.

דרישות מוקדמות למכונות של צומתי אשכולות

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

גישה לשורת פקודה

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

הערה: אם אתם משתמשים ב-Cloud Shell כסביבת המעטפת לאינטראקציה עם Google Cloud, הכלים האלה כבר מותקנים.

• הגרסה העדכנית של ה-CLI של gcloud.
• ‫kubectl להרצת פקודות באשכולות של Kubernetes. אם אתם צריכים להתקין את kubectl, תוכלו להיעזר בהוראות האלה.

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

אתם יכולים להשתמש ב-Terraform, במסוף Google Cloud או ב-CLI של gcloud כדי ליצור אשכול שמנוהל על ידי GKE On-Prem API. אם זו הפעם הראשונה שאתם מתקינים את Google Distributed Cloud, יכול להיות שהמסוף יהיה הכלי שהכי קל להשתמש בו.

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

באמצעות ה-CLI של gcloud, אתם יכולים לשמור את הפקודה עם הארגומנטים שלה בקובץ טקסט ולבצע שינויים לפי הצורך כדי ליצור אשכולות נוספים. אם אתם משתמשים בכלי CI/CD, כמו Cloud Build, אתם יכולים להשתמש בפקודות gcloud כדי ליצור אשכול ומאגר צמתים, ולציין את הדגל --impersonate-service-account כדי להפוך את היצירה לאוטומטית.

המסוף

רוב ההגדרות במסוף תואמות לשדות בקובץ התצורה של האשכול.

1. נכנסים לדף Create a bare metal cluster במסוף.

   מעבר לדף Create a bare metal cluster

2. בוחרים את הפרויקט ב- Google Cloud שבו רוצים ליצור את האשכול. הפרויקט שנבחר משמש גם כפרויקט המארח של ה-fleet. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר.

3. לוחצים על Next כדי להתחיל להגדיר את האשכול.

בקטעים הבאים מוסבר איך להגדיר את אשכול המשתמשים.

מידע בסיסי על אשכולות

מזינים מידע בסיסי על האשכול.

1. מזינים שם לאשכול המשתמשים.

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

3. בשדה Google Cloud API Location, בוחרים את האזור של Google Cloudמהרשימה. ההגדרה הזו קובעת את האזור שבו פועלים ממשקי ה-API והשירותים הבאים:

   • ‫GKE On-Prem API‏ (gkeonprem.googleapis.com)
   • שירות Fleet‏ (gkehub.googleapis.com)
   • קישור השירות (gkeconnect.googleapis.com)

   ההגדרה הזו קובעת גם את האזור שבו יאוחסנו:

   • המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
   • נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
   • יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud

   שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

4. בוחרים את הגרסה של אשכול המשתמשים. אשכולות המשתמשים חייבים להיות באותה גרסה משנית כמו אשכול האדמין, או בגרסה משנית אחת נמוכה יותר מאשכול האדמין.

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

   כשיוצרים את האשכול, GKE On-Prem API מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin של Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

6. בקטע Node configuration, מציינים את הפרטים הבאים:

   • Maximum Pods per node: מזינים את המספר המקסימלי של Pods שאפשר להריץ בצומת אחד. הערכים המותרים הם בין 32 ל-250, כולל. ‫Kubernetes מקצה בלוק Classless Inter-Domain Routing‏ (CIDR) לכל צומת, כדי שלכל pod תהיה כתובת IP ייחודית. הגודל של בלוק ה-CIDR תואם למספר המקסימלי של Pods לכל צומת. למידע נוסף על הגדרת המספר המקסימלי של Pods לכל צומת, קראו את המאמר רשתות של Pods ושירותים.

   • סביבת זמן ריצה של קונטיינר: containerd היא סביבת זמן הריצה היחידה של קונטיינר שזמינה לאשכול.

7. לוחצים על Next כדי לעבור לקטע Networking.

Networking

בקטע הזה מציינים את כתובות ה-IP של הצמתים, ה-Pods והשירותים של האשכול. אם אתם משתמשים באיזון עומסים בחבילה עם MetalLB, אתם צריכים להגדיר גם אותו.

1. בקטע Control plane, מזינים את כתובת ה-IPv4 של כל צומת במישור הבקרה. צמתים של מישור הבקרה מריצים את עומס העבודה של המערכת. בדרך כלל מדובר במכונה אחת אם משתמשים בפריסה מינימלית, או בשלוש מכונות אם משתמשים בפריסה עם זמינות גבוהה (HA). כדי שיהיה קוורום של רוב לזמינות גבוהה, צריך לציין מספר אי-זוגי של צמתים. אפשר לשנות את השדה הזה בכל פעם שמעדכנים או משדרגים אשכול.

   לוחצים על + הוספת כתובת IP לפי הצורך כדי להזין עוד כתובות IP.

2. בקטע Load balancer, בוחרים את מאזן העומסים מהרשימה Mode כדי להגדיר את האשכול. מידע נוסף זמין במאמר סקירה כללית של מאזני עומסים.

   כלול ב-MetalLB

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

   1. בקטע מאגרי צמתים של מאזן עומסים, בוחרים אחת מהאפשרויות הבאות:

      • Use control plane nodes: בוחרים באפשרות הזו כדי להריץ את מאזני העומסים באותם צמתים של מישור הבקרה.

      • Create load balancer node pool: בוחרים באפשרות המתקדמת הזו אם צריך להריץ את מאזני העומסים במאגר ייעודי של צמתים עובדים. כל הצמתים במאגר הצמתים של מאזן העומסים חייבים להיות באותה רשת משנה של שכבה 2 כמו כתובות ה-IP הווירטואליות (VIP) של מאזן העומסים, שאותן מגדירים בקטע Load balancer address pools.

        1. בשדה Load balancer node pool IP 1, מזינים כתובת IPv4 של צומת במאגר הצמתים של מאזן העומסים.

        2. לוחצים על ‎+ Add IP address כדי להוסיף עוד כתובות IP.

   2. בקטע Load balancer address pools, מוסיפים מאגר כתובות אחד או יותר לבקר MetalLB כדי לבחור מתוכו ולהקצות לשירותים מסוג LoadBalancer. כתובת ה-VIP של תעבורת הנתונים הנכנסת, שמציינים בקטע Virtual IPs, חייבת להיות באחד מהמאגרים האלה.

      1. מזינים שם למאגר הכתובות.

      2. מזינים טווח של כתובות IP בסימון CIDR (לדוגמה: 192.0.2.0/26) או בסימון טווח (לדוגמה: 192.0.2.64-192.0.2.72). כדי לציין כתובת IP אחת במאגר, משתמשים ב-‎/32 בסימון CIDR (לדוגמה: ‎192.0.2.1/32).

      3. אם כתובת ה-VIP של ה-Ingress לא נמצאת בטווח הכתובות, לוחצים על ‎+ Add IP Address Range ומזינים טווח כתובות אחר שכולל את כתובת ה-VIP של ה-Ingress.

         כתובות ה-IP בכל מאגר לא יכולות לחפוף, והן חייבות להיות באותה רשת משנה כמו הצמתים באשכול.

      4. בקטע הקצאת כתובות IP, בוחרים אחת מהאפשרויות הבאות:

         • אוטומטי: בוחרים באפשרות הזו אם רוצים שהבקר של MetalLB יקצה באופן אוטומטי כתובות IP ממאגר הכתובות לשירותים מסוג LoadBalancer.
         • ידני: בוחרים באפשרות הזו אם רוצים להשתמש בכתובות מהמאגר כדי לציין ידנית כתובות לשירותים מסוג LoadBalancer.

      5. לוחצים על Avoid buggy IP addresses אם רוצים שבבקר MetalLB לא ייעשה שימוש בכתובות IP מהמאגר שמסתיימות ב-‎ .0 או ב-‎ .255. כך אפשר להימנע מהבעיה שבה מכשירים של צרכנים עם באגים משמיטים בטעות תעבורת נתונים שנשלחת לכתובות ה-IP המיוחדות האלה.

      6. כשמסיימים, לוחצים על סיום.

      7. אם צריך, לוחצים על Add Address Pool.

   מאזן עומסים ידני

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

3. בקטע Virtual IPs, מזינים את הפרטים הבאים:

   • כתובת ה-VIP של מישור הבקרה: כתובת ה-IP של היעד שאליה תישלח תעבורת הנתונים לשרת ה-API של Kubernetes באשכול המשתמש. כתובת ה-VIP של מישור הבקרה צריכה להיות באותה רשת משנה כמו הצמתים של מאזן העומסים, ולא יכולה להיות באף אחד מטווחי הכתובות שמשמשים למאגרי הכתובות של מאזן העומסים.

   • ‫Port: יציאת היעד שמשמשת לתעבורת הנתונים שנשלחת לשרת ה-API של Kubernetes. ברירת המחדל היא 443.

   • Ingress VIP: כתובת ה-IP שצריך להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress. מזינים כתובת מאחד ממאגרי הכתובות של מאזן העומסים.

4. בקטע Service and Pod CIDRs, מציינים את טווחי כתובות ה-IP של שירות Kubernetes ו-Pod בסימון CIDR. הם לא יכולים לחפוף אחד לשני, או לכל כתובת מחוץ לאשכול שרוצים להגיע אליה מתוך האשכול. מומלץ להשתמש בטווחי כתובות ה-IP הפרטיות שמוגדרים ב-RFC 1918. במסוף מוצגים טווחי הכתובות הבאים כברירת מחדל, אבל אפשר לשנות אותם:

   • ‫Service CIDR: 10.96.0.0/20 אם אתם לא מקבלים את ברירת המחדל, הזינו טווח CIDR בין ‎/24 ל-‎/12, כאשר ‎/12 מספק את המספר הגדול ביותר של כתובות IP.

   • ‫Pod CIDR: 192.168.0.0/16 אם אתם לא מקבלים את ברירת המחדל, הזינו טווח CIDR בין ‎/18 ל-‎/8, כאשר ‎/8 מספק את המספר הגדול ביותר של כתובות IP.

5. בקטע Advanced attributes, אפשר לציין את הפרטים הבאים:

   • כתובת ה-URL של שרת ה-Proxy: כתובת ה-HTTP של שרת ה-Proxy. צריך לכלול את מספר היציאה גם אם הוא זהה ליציאת ברירת המחדל של הסכימה, לדוגמה: http://my-proxy.example.local:80

   • כתובות URL: רשימה מופרדת בפסיקים של כתובות IP, טווחי כתובות IP, שמות מארחים ושמות דומיינים שלא צריכים לעבור דרך שרת ה-Proxy. כש-Google Distributed Cloud שולח בקשה לאחת מהכתובות, המארחים או הדומיינים האלה, הבקשה נשלחת ישירות.

6. לוחצים על הבא.

אחסון

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

1. אפשר גם להגדיר את האפשרויות הבאות:

   • Local volume provisioner node mounts: הגדרת PersistentVolumes (PVs) מקומיים שמגובים בדיסקים שנטענו. צריך לפרמט ולטעון את הדיסקים האלה, ואפשר לעשות את זה לפני או אחרי שיוצרים את האשכול.

   • ‫Local volume provisioner share: מציין את ההגדרה של PersistentVolumes מקומי שמגובה על ידי ספריות משנה במערכת קבצים משותפת. ספריות המשנה האלה נוצרות באופן אוטומטי במהלך יצירת האשכול.

2. לוחצים על הבא.

תכונות

כדי לעזור לכם לעקוב אחרי האשכול, לפתור בו בעיות ולהפעיל אותו, האפשרויות הבאות מופעלות באופן אוטומטי ואי אפשר להשבית אותן:

• ‫Cloud Logging של שירותי המערכת
• מעקב בענן אחרי שירותי המערכת
• יומן הביקורת Admin Activity

יצירת מאגר צמתים במסוף

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

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

1. בסרגל הניווט הימני, לוחצים על default pool.

2. בקטע Node pool defaults, מזינים את השם של מאגר הצמתים בשדה Node pool name או משאירים את השם default-pool.

3. בקטע צומתי עובד, מזינים את כתובות ה-IP של המכונות שהאשכול יפעל בהן.

4. בקטע מטא-נתונים של מאגר צמתים (אופציונלי), אם רוצים להוסיף תוויות ודחיות (taints) של Kubernetes:

   1. לוחצים על ‎+ Add Kubernetes Labels. מזינים את Key ו-Value של התווית. חוזרים לפי הצורך.
   2. לוחצים על ‎+ Add Taint. מזינים את הערכים של Key,‏ Value ו-Effect של הטולרנטיות. חוזרים לפי הצורך.

5. לוחצים על Verify and Complete כדי ליצור את אשכול המשתמשים. יצירת אשכול המשתמשים נמשכת 15 דקות או יותר. במסוף מוצגות הודעות סטטוס בזמן אימות ההגדרות ויצירת האשכול במרכז הנתונים.

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

‫CLI של gcloud

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

gcloud container bare-metal clusters create

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

gcloud container bare-metal node-pools create

רוב הדגלים ליצירת האשכול ומאגר הצמתים תואמים לשדות בקובץ התצורה של אשכול המשתמש. כדי להתחיל, אתם יכולים לבדוק את הפקודה המלאה בקטע דוגמאות. מידע על הדגלים מופיע בקטעים שאחרי הדוגמאות, או במדריך העזר ל-CLI של gcloud.

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

הגרסה שבוחרים כשיוצרים אשכול משתמשים חייבת להיות גרסה שנתמכת באשכול האדמין. בנוסף, גרסאות התיקון או הגרסאות המשניות האחרונות לא זמינות ב-GKE On-Prem API עד 7 עד 14 ימים אחרי ההשקה. אתם יכולים להריץ פקודת gcloud כדי לקבל רשימה של גרסאות אשכולות נתמכות שאפשר להתקין.

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

   gcloud components update
   

2. מאתרים את השם ואת מיקום החברות ב-Fleet של אשכול האדמין:

   gcloud container fleet memberships list \
     --project=FLEET_HOST_PROJECT_ID
   

   מחליפים את FLEET_HOST_PROJECT_ID במזהה הפרויקט שאליו רשום אשכול האדמין.

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

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   המיקום מציין איפה פועלים שירותי Fleet ו-Connect. אשכולות אדמין שנוצרו לפני גרסה 1.28 מנוהלים על ידי שירותי Fleet ו-Connect הגלובליים. בגרסה 1.28 ואילך, אפשר לציין global או אזור ב- Google Cloud כשיוצרים את אשכול האדמין. בדוגמאות לפקודות שבהמשך, מציינים את האזור בדגל --admin-cluster-membership-location.

3. מציגים רשימה של הגרסאות שאפשר להתקין באשכול המשתמש:

   gcloud container bare-metal clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
     --location=REGION
   

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

   • ‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין.

   • ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שאליו רשום אשכול האדמין.

   • ‫ADMIN_CLUSTER_REGION: האזור של אשכול הניהול ב-Fleet. הערך יכול להיות גלובלי או אזור ב- Google Cloud. משתמשים במיקום של אשכול האדמין מהפלט של gcloud container fleet memberships list.

   • ‫REGION: האזור ( Google Cloud ) שבו תשתמשו כשתצרו את האשכול. זה האזור שבו פועלים GKE On-Prem API והשירותים Fleet ו-Connect. מציינים את us-west1 או אזור נתמך אחר.

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

   versions:
   - version: 1.16.2
   - version: 1.16.1
   - version: 1.16.0
   - version: 1.15.7
   - version: 1.15.6
   - version: 1.15.5
   

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

דוגמאות

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

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

MetalLB

בדוגמה הזו מוסבר איך ליצור אשכול משתמש עם מאזן העומסים המצורף MetalLB.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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

• ‫USER_CLUSTER_NAME: השם שבחרתם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
  • לכלול עד 40 תווים
  • להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
  • להתחיל באות
  • להסתיים בתו אלפאנומרי
• ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של ה-fleet. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
• ‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדגל --admin-cluster-membership, אפשר להשתמש בשם המלא של האשכול, בפורמט הבא:

      projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

  לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, הריצו את הפקודה gcloud container fleet memberships list.

• ‫REGION: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). צריך לציין את us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הפריטים הבאים:
  • המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
  • נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
  • יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud

  שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

  חשוב אם אתם מתכננים להתקין את Cloud Service Mesh, אתם צריכים להתקין את גרסה 1.19.3 ואילך. הפעולה הזו נדרשת כי שירותי Fleet ו-Connect פועלים באזור.
• ‫VERSION: הגרסה של Google Distributed Cloud באשכול המשתמשים.
• ‫YOUR_EMAIL_ADDRESS ו-ANOTHER_EMAIL_ADDRESS: אם לא תכללו את הדגל --admin-users, כיוצרי האשכול תקבלו כברירת מחדל הרשאות אדמין באשכול. אבל אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. לדוגמה, כדי להוסיף שני אדמינים:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  אחרי שהאשכול נוצר, GKE On-Prem API מחיל את מדיניות בקרת הגישה מבוססת-התפקידים (RBAC) של Kubernetes על האשכול, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin של Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

מאגרי כתובות של MetalLB

• ‫--metal-lb-address-pools: מציינים את ההגדרות של מאגרי הכתובות שבהם ישתמש מאזן העומסים MetalLB. הערך של הדגל הוא בפורמט הבא:

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

הערך מכיל פלחים שמתחילים במילות המפתח pool,‏ avoid-buggy-ip,‏ manual-assign ו-addresses. מפרידים בין הפלחים באמצעות פסיקים.

• ‫pool: שם המאגר שבחרתם.

• ‫avoid-buggy-ips: אם מגדירים את הערך True, בקר MetalLB לא מקצה לשירותים כתובות IP שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירים צרכניים עם באגים, שעלולים להפיל בטעות תנועה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False.

• ‫manual-assign: אם אתם לא רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, הגדירו את הערך True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני את אחת מהכתובות במאגר. אם לא מציינים ערך, manual-assign מוגדר כ-False.

• ברשימה של addresses: כל כתובת צריכה להיות טווח בפורמט CIDR או בפורמט של טווח עם מקפים. כדי לציין כתובת IP אחת במאגר (למשל, ל-VIP של הכניסה), משתמשים ב-‎/32 בסימון CIDR (למשל, ‫192.0.2.1/32).

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

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

אפשר לציין יותר ממופע אחד של הדגל, כמו בדוגמה הבאה:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

צומתי MetalLB

• אופציונלי: --metal-lb-load-balancer-node-configs: כברירת מחדל, מאזן העומסים פועל באותם צמתים כמו מישור הבקרה. אם אתם צריכים להריץ את מאזן העומסים במאגר ייעודי של צומתי עובדים, ציינו את הדגל הזה לכל צומת. כל הצמתים במאגר הצמתים של מאזן העומסים צריכים להיות באותה רשת משנה של שכבה 2 כמו כתובות ה-IP הווירטואליות (VIP) של מאזן העומסים.

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

  הערך של הדגל הוא בפורמט הבא:

  'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \
  

  הערך מכיל פלחים שמתחילים במילות המפתח node-ip ו-labels. מפרידים בין הפלחים באמצעות פסיקים.

  • ‫node-ip: כתובת ה-IP של צומת במאגר הצמתים של מאזן העומסים. אפשר לציין רק node-ip אחד לכל דגל. אם צריך לציין יותר מצומת אחד, מוסיפים את הדגל שוב לכל צומת.

  • ‫labels: צמד אחד או יותר של מפתח=ערך שמצורפים לצומת.

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

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

  אם מציינים את --metal-lb-load-balancer-node-configs, אפשר לכלול את הדגלים הבאים:

  • ‫--metal-lb-load-balancer-node-labels: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים במאגר הצמתים של מאזן העומסים. מפרידים בין צמדי המפתח=ערך באמצעות פסיק.

    --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
    

  • ‫--metal-lb-load-balancer-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במאגר הצמתים של מאזן העומסים. כל taint הוא צמד של key=value שמשויך להשפעה, שיכולה להיות אחת מהאפשרויות הבאות: PreferNoSchedule,‏ NoSchedule או NoExecute.

    --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2
    

  בדוגמה הבאה מוסיפים שלושה צמתים למאגר הצמתים של מאזן העומסים. כל הצמתים מסומנים בתווית lb-pool-key=lb-pool-value ויש להם את ה-taint dedicated=experimental:PreferNoSchedule,

  --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
  --metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
  --metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \
  

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

• ‫--control-plane-node-configs: כתובת ה-IPv4 של צומת במישור הבקרה. צמתים של מישור הבקרה מריצים את עומס העבודה של המערכת. צריך לציין את הדגל הזה לכל צומת במישור הבקרה. בדרך כלל יש מכונה אחת אם משתמשים בפריסה מינימלית, או שלוש מכונות אם משתמשים בפריסה עם זמינות גבוהה (HA). כדי שיהיה קוורום של רוב לזמינות גבוהה, צריך לציין מספר אי-זוגי של צמתים. אפשר לשנות את הכתובות האלה בכל פעם שמעדכנים או משדרגים אשכול.

  הערך של הדגל הוא בפורמט הבא:

    'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

  הערך מכיל פלחים שמתחילים במילות המפתח node-ip ו-labels. מפרידים בין הפלחים באמצעות פסיקים.

• ‫node-ip: כתובת ה-IP של צומת במישור הבקרה. אפשר לציין רק node-ip אחד לכל דגל. אם צריך לציין יותר מצומת אחד, צריך לכלול את הדגל שוב לכל צומת.
• ‫labels: צמד אחד או יותר של מפתח=ערך שמצורפים לצומת.

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

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

  אפשר גם לכלול את הדגלים הבאים:

• ‫--control-plane-node-labels: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים של מישור הבקרה. צריך להפריד בין צמדי מפתח=ערך באמצעות פסיק.
    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במישור הבקרה. כל taint הוא צמד של key=value שמשויך להשפעה, שיכולה להיות אחת מהאפשרויות הבאות: PreferNoSchedule,‏ NoSchedule או NoExecute.

  בדוגמה הבאה מוסיפים שלושה צמתים לצומתי מישור הבקרה. כל הצמתים מסומנים בתווית cp-node-pool-key=cp-node-pool-value ויש להם את הטיינט dedicated=experimental:PreferNoSchedule.

    --control-plane-node-configs='node-ip=192.0.2.1' \
    --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
    --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
    --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
    --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

כתובות IP וירטואליות

• ‫CONTROL_PLANE_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.

  לדוגמה: --control-plane-vip=203.0.113.3

• ‫CONTROL_PLANE_LB_PORT: היציאה שבה מאזן העומסים משרת את שרת ה-API של Kubernetes.

  לדוגמה: -control-plane-load-balancer-port=443

• ‫INGRESS_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של תעבורת הנתונים הנכנסת.

  לדוגמה: --ingress-vip=10.251.134.80

  כתובת ה-IP של ה-VIP של הכניסה חייבת להיות באחד ממאגרי הכתובות של MetalLB.

CIDR של שירות ו-Pod

• ‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. טווח ה-CIDR חייב להיות בין ‎/24 ל-‎/12, כאשר ‎/12 מספק את מספר כתובות ה-IP הגדול ביותר.

  לדוגמה: --island-mode-service-address-cidr-blocks=10.96.0.0/20

• ‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. טווח ה-CIDR חייב להיות בין ‎/18 ל-‎/8, כאשר ‎/8 מספק את המספר הגדול ביותר של כתובות IP.

  לדוגמה: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

אחסון

1. ‫--lvp-share-path: הנתיב של המכונה המארחת שבו אפשר ליצור ספריות משנה. נוצר PersistentVolume‏ (PV) מקומי לכל ספריית משנה.
2. ‫--lvp-share-storage-class: זהו ה-StorageClass שמשמש ליצירת אמצעי אחסון מתמידים. ה-StorageClass נוצר במהלך יצירת האשכול.
3. ‫--lvp-node-mounts-config-path: הנתיב של המכונה המארחת שבו אפשר למצוא דיסקים שנטענו. לכל נקודת טעינה נוצר PersistentVolume‏ (PV) מקומי.
4. ‫--lvp-node-mounts-config-storage: סוג האחסון שבו נוצרים אמצעי האחסון הקבועים במהלך יצירת האשכול.

מידע נוסף על אחסון זמין במאמר הגדרת אחסון מקומי.

גלילה ידנית

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

חשוב לגלול אם צריך כדי למלא את הפלייסהולדר ADMIN_CLUSTER_NAME של הדגל --admin-cluster-membership.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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

• ‫USER_CLUSTER_NAME: השם שבחרתם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
  • לכלול עד 40 תווים
  • להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
  • להתחיל באות
  • להסתיים בתו אלפאנומרי
• ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של ה-fleet. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
• ‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדגל --admin-cluster-membership, אפשר להשתמש בשם המלא של האשכול, בפורמט הבא:

      projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

  לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, הריצו את הפקודה gcloud container fleet memberships list.

• ‫REGION: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). צריך לציין את us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הפריטים הבאים:
  • המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
  • נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
  • יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud

  שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

  חשוב אם אתם מתכננים להתקין את Cloud Service Mesh, אתם צריכים להתקין את גרסה 1.19.3 ואילך. הפעולה הזו נדרשת כי שירותי Fleet ו-Connect פועלים באזור.
• ‫VERSION: הגרסה של Google Distributed Cloud באשכול המשתמשים.
• ‫YOUR_EMAIL_ADDRESS ו-ANOTHER_EMAIL_ADDRESS: אם לא תכללו את הדגל --admin-users, כיוצרי האשכול תקבלו כברירת מחדל הרשאות אדמין באשכול. אבל אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. לדוגמה, כדי להוסיף שני אדמינים:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  אחרי שהאשכול נוצר, GKE On-Prem API מחיל את מדיניות בקרת הגישה מבוססת-התפקידים (RBAC) של Kubernetes על האשכול, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin של Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

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

• ‫--control-plane-node-configs: כתובת ה-IPv4 של צומת במישור הבקרה. צמתים של מישור הבקרה מריצים את עומס העבודה של המערכת. צריך לציין את הדגל הזה לכל צומת במישור הבקרה. בדרך כלל יש מכונה אחת אם משתמשים בפריסה מינימלית, או שלוש מכונות אם משתמשים בפריסה עם זמינות גבוהה (HA). כדי שיהיה קוורום של רוב לזמינות גבוהה, צריך לציין מספר אי-זוגי של צמתים. אפשר לשנות את הכתובות האלה בכל פעם שמעדכנים או משדרגים אשכול.

  הערך של הדגל הוא בפורמט הבא:

    'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

  הערך מכיל פלחים שמתחילים במילות המפתח node-ip ו-labels. מפרידים בין הפלחים באמצעות פסיקים.

• ‫node-ip: כתובת ה-IP של צומת במישור הבקרה. אפשר לציין רק node-ip אחד לכל דגל. אם צריך לציין יותר מצומת אחד, צריך לכלול את הדגל שוב לכל צומת.
• ‫labels: צמד אחד או יותר של מפתח=ערך שמצורפים לצומת.

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

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

  אפשר גם לכלול את הדגלים הבאים:

• ‫--control-plane-node-labels: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים של מישור הבקרה. צריך להפריד בין צמדי מפתח=ערך באמצעות פסיק.
    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במישור הבקרה. כל taint הוא צמד של key=value שמשויך להשפעה, שיכולה להיות אחת מהאפשרויות הבאות: PreferNoSchedule,‏ NoSchedule או NoExecute.

  בדוגמה הבאה מוסיפים שלושה צמתים לצומתי מישור הבקרה. כל הצמתים מסומנים בתווית cp-node-pool-key=cp-node-pool-value ויש להם את הטיינט dedicated=experimental:PreferNoSchedule.

    --control-plane-node-configs='node-ip=192.0.2.1' \
    --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
    --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
    --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
    --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

כתובות IP וירטואליות

• ‫CONTROL_PLANE_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.

  לדוגמה: --control-plane-vip=203.0.113.3

• ‫CONTROL_PLANE_LB_PORT: היציאה שבה מאזן העומסים משרת את שרת ה-API של Kubernetes.

  לדוגמה: -control-plane-load-balancer-port=443

• ‫INGRESS_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של תעבורת הנתונים הנכנסת.

  לדוגמה: --ingress-vip=10.251.134.80

  כתובת ה-IP של ה-VIP של הכניסה חייבת להיות באחד ממאגרי הכתובות של MetalLB.

CIDR של שירות ו-Pod

• ‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. טווח ה-CIDR חייב להיות בין ‎/24 ל-‎/12, כאשר ‎/12 מספק את מספר כתובות ה-IP הגדול ביותר.

  לדוגמה: --island-mode-service-address-cidr-blocks=10.96.0.0/20

• ‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. טווח ה-CIDR חייב להיות בין ‎/18 ל-‎/8, כאשר ‎/8 מספק את המספר הגדול ביותר של כתובות IP.

  לדוגמה: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

אחסון

1. ‫--lvp-share-path: הנתיב של המכונה המארחת שבו אפשר ליצור ספריות משנה. נוצר PersistentVolume‏ (PV) מקומי לכל ספריית משנה.
2. ‫--lvp-share-storage-class: זהו ה-StorageClass שמשמש ליצירת אמצעי אחסון מתמידים. ה-StorageClass נוצר במהלך יצירת האשכול.
3. ‫--lvp-node-mounts-config-path: הנתיב של המכונה המארחת שבו אפשר למצוא דיסקים שנטענו. לכל נקודת טעינה נוצר PersistentVolume‏ (PV) מקומי.
4. ‫--lvp-node-mounts-config-storage: סוג האחסון שבו נוצרים אמצעי האחסון הקבועים במהלך יצירת האשכול.

מידע נוסף על אחסון זמין במאמר הגדרת אחסון מקומי.

לפני שמריצים את הפקודה gcloud כדי ליצור את האשכול, כדאי לכלול את --validate-only כדי לאמת את ההגדרות שציינתם בדגלים של הפקודה gcloud. כשהכול מוכן ליצירת האשכול, מסירים את הדגל הזה ומריצים את הפקודה.

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

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

בפלט לדוגמה, המחרוזת operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 היא ה-OPERATION_ID של הפעולה שרצה לאורך זמן. כדי לבדוק את סטטוס הפעולה, מריצים את הפקודה הבאה:

gcloud container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

יצירת אשכול המשתמשים נמשכת 15 דקות או יותר. אפשר לראות את אשכול ה-GKE בדף GKE clusters במסוף Google Cloud .

רשימה מלאה של הדגלים והתיאורים שלהם מופיעה בחומר העזר של ה-CLI של gcloud.

יצירת מאגר צמתים

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

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

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

• ‫NODE_POOL_NAME: שם לבחירתכם למאגר הצמתים. השם צריך:

  • לכלול עד 40 תווים
  • להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
  • להתחיל באות
  • להסתיים בתו אלפאנומרי

• ‫USER_CLUSTER_NAME: השם של אשכול המשתמש החדש שנוצר.

• ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שהאשכול רשום בו.

• ‫REGION: האזור של Google Cloud שציינתם כשיצרתם את האשכול.

• ‫--node-configs: כתובת ה-IPv4 של מכונת צומת עובד. צריך לציין את הדגל הזה לכל צומת. הערך של הדגל הוא בפורמט הבא:

  'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \
  

  הערך מכיל פלחים שמתחילים במילות המפתח node-ip ו-labels. מפרידים בין הפלחים באמצעות פסיקים.

  • ‫node-ip: כתובת ה-IP של צומת עובד. אפשר לציין רק node-ip אחד לכל דגל. מוסיפים את הדגל הזה שוב לכל צומת במאגר הצמתים.

  • ‫labels: צמד אחד או יותר של מפתח=ערך שמצורפים לצומת.

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

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

  אפשר גם לציין את הפרטים הבאים:

  • ‫--node-labels=KEY=VALUE,...: רשימה מופרדת בפסיקים של תוויות Kubernetes (צמדי מפתח/ערך) שחלות על כל צומת במאגר.

  • --node-taints=KEY=VALUE:EFFECT,... רשימה מופרדת בפסיקים של Kubernetes taints שחלים על כל צומת במאגר. Taints הם צמדי מפתח=ערך שמשויכים לאפקט. הכתמות משמשות עם סבילות לתזמון Pod. צריך לציין אחד מהערכים הבאים בשביל EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

בדוגמה הבאה נוצר מאגר צמתים בשם default-pool ב-user-cluster-, ונוספים שני צמתים למאגר הצמתים. כל הצמתים מסומנים בתווית node-pool-key=node-pool-value וכוללים את הכתם dedicated=experimental:PreferNoSchedule,

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

למידע נוסף, קראו את מדריך העזר ל-CLI של gcloud.

Terraform

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

גרסת התוכנה של Distributed Cloud ל-bare metal בלבד שאתם בוחרים כשאתם יוצרים אשכול משתמשים, צריכה להיות גרסה שנתמכת באשכול האדמין. בנוסף, הגרסאות המשניות או גרסאות התיקון האחרונות לא זמינות ב-GKE On-Prem API עד 7 עד 14 ימים אחרי ההשקה. אפשר להריץ פקודת gcloud כדי לקבל רשימה של גרסאות נתמכות שבהן אפשר להשתמש כדי להתקין את אשכול המשתמשים.

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

   gcloud components update
   

2. מאתרים את השם ואת מיקום החברות ב-Fleet של אשכול האדמין:

   gcloud container fleet memberships list \
     --project=FLEET_HOST_PROJECT_ID
   

   מחליפים את FLEET_HOST_PROJECT_ID במזהה הפרויקט שאליו רשום אשכול האדמין.

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

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   המיקום מציין איפה פועלים שירותי Fleet ו-Connect. אשכולות אדמין שנוצרו לפני גרסה 1.28 מנוהלים על ידי שירותי Fleet ו-Connect הגלובליים. בגרסה 1.28 ואילך, אפשר לציין global או אזור ב- Google Cloud כשיוצרים את אשכול האדמין. בדוגמאות לפקודות שבהמשך, מציינים את האזור בדגל --admin-cluster-membership-location.

3. מציגים רשימה של הגרסאות שאפשר להתקין באשכול המשתמש:

   gcloud container bare-metal clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
     --location=REGION
   

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

   • ‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין.

   • ‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שאליו רשום אשכול האדמין.

   • ‫ADMIN_CLUSTER_REGION: האזור של אשכול הניהול ב-Fleet. הערך יכול להיות גלובלי או אזור ב- Google Cloud. משתמשים במיקום של אשכול האדמין מהפלט של gcloud container fleet memberships list.

   • ‫REGION: האזור ( Google Cloud ) שבו תשתמשו כשתצרו את האשכול. זה האזור שבו פועלים GKE On-Prem API והשירותים Fleet ו-Connect. מציינים את us-west1 או אזור נתמך אחר.

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

   versions:
   - version: 1.16.2
   - version: 1.16.1
   - version: 1.16.0
   - version: 1.15.7
   - version: 1.15.6
   - version: 1.15.5
   

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

דוגמה

אתם יכולים להשתמש בדוגמה הבאה להגדרה בסיסית כדי ליצור אשכול משתמשים עם מאזן עומסים של MetalLB. למידע נוסף, ראו את מאמרי העזרה של google_gkeonprem_bare_metal_cluster.

הגדרת משתנים ב-terraform.tfvars

הדוגמה כוללת קובץ משתנים לדוגמה שאפשר להעביר ל-main.tf, שמראה איך להגדיר את מאזן העומסים MetalLB שמצורף לחבילה.

1. משכפלים את המאגר anthos-samples ועוברים לספרייה שבה נמצאת הדוגמה של Terraform:

   git clone https://github.com/GoogleCloudPlatform/anthos-samples
   cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb
   

   הדוגמה כוללת קובץ משתנים לדוגמה שאפשר להעביר אל main.tf.

2. יוצרים עותק של הקובץ terraform.tfvars.sample:

   cp terraform.tfvars.sample terraform.tfvars
   

3. משנים את ערכי הפרמטרים בקובץ terraform.tfvars ושומרים את הקובץ.

   
   project_id          = "PROJECT_ID"
   region              = "ON_PREM_API_REGION"
   admin_cluster_name  = "ADMIN_CLUSTER_NAME"
   bare_metal_version  = "VERSION"
   admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name        = "abm-user-cluster-metallb"
   control_plane_ips   = ["10.200.0.4"]
   worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
   control_plane_vip   = "10.200.0.50"
   ingress_vip         = "10.200.0.51"
   lb_address_pools    = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

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

   • ‫project_id: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של הצי. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.

   • ‫region: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). מציינים את us-west1 או אזור נתמך אחר.

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

   • ‫admin_cluster_name: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדוגמה הזו, האזור של אשכול האדמין הוא global. אם יש לכם אשכול אדמין אזורי:

     1. פותחים את main.tf בכלי לעריכת טקסט.

     2. מחפשים את admin_cluster_membership, שנראה כך:

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     3. משנים את global לאזור שבו משתמש אשכול האדמין ושומרים את הקובץ.

   • ‫bare_metal_version: הגרסה של Google Distributed Cloud לאשכול המשתמשים. ציינו גרסה זהה לזו של אשכול האדמין, או גרסה נמוכה יותר בלא יותר מגרסה משנית אחת מזו של אשכול האדמין.

   • ‫admin_user_emails: רשימה של כתובות האימייל של המשתמשים שרוצים לתת להם הרשאות אדמין באשכול. אם אתם מתכוונים לנהל את האשכול, הקפידו להוסיף את כתובת האימייל שלכם.

     כשיוצרים את האשכול, ה-API של GKE On-Prem מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, כדי להקצות למשתמשים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin ב-Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות. כך המשתמשים יכולים גם להתחבר למסוף באמצעות Google Identity.

   • ‫cluster_name: שם לבחירתכם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:

     • לכלול עד 40 תווים
     • להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
     • להתחיל באות
     • להסתיים בתו אלפאנומרי

   • ‫control_plane_ips: רשימה של כתובת IPv4 אחת או יותר לצומתי מישור הבקרה. צמתים של מישור הבקרה מריצים את עומס העבודה של המערכת. בדרך כלל, אם משתמשים בפריסה מינימלית יש מכונה אחת, ואם משתמשים בפריסה של זמינות גבוהה (HA) יש שלוש מכונות. כדי שיהיה קוורום של רוב לזמינות גבוהה, צריך לציין מספר אי-זוגי של צמתים. אפשר לשנות את הכתובות האלה בכל פעם שמעדכנים או משדרגים אשכול.

   • ‫worker_node_ips: רשימה של כתובת IPv4 אחת או יותר למכונות של צומתי העובדים.

   • ‫control_plane_vip: כתובת ה-IP הווירטואלית (VIP) שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.

   • ‫ingress_vip: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress.

   • ‫lb_address_pools: רשימה של מפות שמגדירות את מאגרי הכתובות שבהם מאזן העומסים MetalLB ישתמש. כתובת ה-VIP של הכניסה חייבת להיות באחד מהמאגרים האלה.

4. שומרים את השינויים ב-terraform.tfvars.

5. מאתחלים ויוצרים את התוכנית ב-Terraform:

   terraform init
   

   ‫Terraform מתקין את כל הספריות הנדרשות, כמו הספק Google Cloud .

6. בודקים את ההגדרות ומשנים אותן לפי הצורך:

   terraform plan
   

7. מפעילים את התוכנית של Terraform כדי ליצור את אשכול המשתמש:

   terraform apply
   

   יצירת אשכול המשתמשים נמשכת 15 דקות או יותר. אפשר לראות את אשכול ה-GKE בדף GKE clusters במסוף Google Cloud .

התחברות לאשכול המשתמשים

כשיוצרים אשכול משתמשים במסוף, האשכול מוגדר עם כללי מדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, כדי שתוכלו להתחבר לאשכול באמצעות הזהות שלכם ב- Google Cloud . כשיוצרים אשכול משתמש באמצעות ה-CLI של gcloud, מקבלים את כללי המדיניות האלה של RBAC כברירת מחדל אם לא כוללים את הדגל --admin-users. אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. למידע נוסף על כללי המדיניות הנדרשים של IAM ו-RBAC, קראו את המאמר הגדרת אימות Google Identity.

לכל האשכולות יש נקודת קצה קנונית. נקודת הקצה חושפת את שרת ה-API של Kubernetes, שמשמש את kubectl ושירותים אחרים כדי לתקשר עם מישור הבקרה של האשכול דרך יציאת TCP‏ 443. אי אפשר לגשת לנקודת הקצה הזו דרך האינטרנט הציבורי. אם יש לכם גישה לנקודת הקצה הפרטית של האשכול דרך ה-VPC, אתם יכולים להתחבר ישירות לנקודת הקצה הפרטית וליצור קובץ kubeconfig ישירות. אחרת, אתם יכולים להשתמש ב-Connect Gateway.

כדי לגשת לאשכול המשתמש משורת הפקודה, צריך קובץ kubeconfig. יש שתי דרכים לקבל קובץ kubeconfig:

• משתמשים בשער הקישוריות כדי לגשת לאשכול ממחשב שמותקן בו Google Cloud CLI. במקרה כזה, kubectl משתמש ב-kubeconfig של שער Connect, שמעביר באופן מאובטח את התנועה לנקודת הקצה הפרטית בשמכם.

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

חשוב להמתין עד שבמסוף Google Cloud יצוין שהסטטוס של אשכול המשתמשים תקין.

חיבור השער

1. מאתחלים את ה-CLI של gcloud לשימוש עם הפרויקט המארח של ה-fleet, או מריצים את הפקודות הבאות כדי להתחבר באמצעות חשבון Google, להגדיר את הפרויקט המארח של ה-fleet כברירת המחדל ולעדכן רכיבים:

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud components update
   

2. אחזור פרטי הכניסה של האשכול שמשמשים לאינטראקציה עם Connect gateway. בפקודה הבאה, מחליפים את MEMBERSHIP_NAME בשם האשכול. ב-Distributed Cloud לתוכנת Bare Metal בלבד, שם המינוי זהה לשם האשכול.

   gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
   

   הפקודה הזו מחזירה שער ספציפי לחיבורkubeconfig שמאפשר להתחבר לאשכול דרך השער.

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

kubectl get namespaces

תחנת עבודה של אדמין

משתמשים בפקודה bmctl get credentials כדי לאחזר קובץ kubeconfig לאשכול המשתמשים החדש שנוצר.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

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

• ‫CLUSTER_NAME: השם של אשכול המשתמשים המטורגט.

• ‫ADMIN_KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של אשכול האדמין.

kubeconfig עם פרטי הכניסה של אשכול המשתמשים נכתב בקובץ bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. הערך TIMESTAMP בשם הקובץ מציין את התאריך והשעה שבהם הקובץ נוצר.

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

המאמרים הבאים

• אבטחת קונטיינרים באמצעות SELinux
• ניהול אשכולות דרך מסוף Google Cloud