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

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

מה זה GKE On-Prem API?

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

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

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

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

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

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

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

מתן הרשאות IAM

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

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

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

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

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

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

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

ממשקי Google APIs נדרשים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אחרי שתכירו טוב יותר את המידע שצריך לספק כדי ליצור אשכולות, יכול להיות שתגלו שנוח יותר להשתמש ב-Terraform או ב-CLI של gcloud, במיוחד אם אתם מתכננים ליצור יותר מאשכול אחד. ‫Terraform הוא כלי לתשתית כקוד (IaC) שהוא תקן בתעשייה. אם הארגון שלכם כבר משתמש ב-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 הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שנבחר משמש גם כפרויקט המארח של צי המכונות. הפרויקט הזה צריך להיות זהה לפרויקט שבו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמשים, הוא נרשם אוטומטית לצי הפרויקט שנבחר.

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

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

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

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

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

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

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

   • ‫GKE On-Prem API ‏ (gkeonprem.googleapis.com)
   • שירות לצי רכב (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, שמאפשר גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

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

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

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

7. לוחצים על הבא כדי לעבור לקטע Networking (רשת).

Networking

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

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

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

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

   כלול בחבילה עם MetalLB

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

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

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

      • יצירת מאגר צמתים של מאזן עומסים: בוחרים באפשרות המתקדמת הזו אם צריך להפעיל את מאזני העומסים במאגר ייעודי של צמתי עובדים. כל הצמתים במאגר הצמתים של מאזן העומסים צריכים להיות באותה רשת משנה (subnet) בשכבה 2 כמו כתובות ה-IP הווירטואליות (VIP) של מאזן העומסים שאתם מגדירים בקטע מאגרי כתובות של מאזן העומסים.

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

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

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

      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 של התנועה הנכנסת לא נמצאת בטווח הכתובות, בוחרים באפשרות + הוספת טווח כתובות IP ומזינים טווח כתובות אחר שכולל את כתובת ה-VIP של התנועה הנכנסת.

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

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

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

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

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

      7. במקרה הצורך, לוחצים על הוספת מאגר כתובות.

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

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

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

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

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

   • כתובת IP וירטואלית של Ingress: כתובת ה-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. לוחצים על הבא.

אחסון

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

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

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

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

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

תכונות

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

• Cloud Logging של שירותי מערכת
• Cloud Monitoring של שירותי מערכת
• יומן הביקורת Admin Activity

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

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

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

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

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

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

4. בקטע Node pool metadata (optional) (מטא-נתונים של מאגר צמתים (אופציונלי)), אם רוצים להוסיף labels (תוויות) ו-taints (הכתמות) של Kubernetes, מבצעים את הפעולות הבאות:

   1. לוחצים על + הוספת תוויות Kubernetes. מזינים את המפתח ואת הערך של התווית. חוזרים לפי הצורך.
   2. לוחצים על + הוספת כתם. מזינים את המפתח, הערך וההשפעה של הכתם. חוזרים לפי הצורך.

5. לוחצים על אימות והשלמה כדי ליצור את אשכול המשתמשים. יצירת אשכול המשתמשים נמשכת 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של צי כלי הרכב אחרי שיוצרים את האשכול.
• ‫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: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים 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, שמעניק גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

  הערה: בנוסף למדיניות RBAC של Kubernetes, צריך להקצות תפקידים מסוימים של ניהול זהויות והרשאות גישה (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 יחידה במאגר (למשל עבור כתובת ה-IP הווירטואלית של הכניסה), משתמשים ב-‎ /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: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים במאגר הצמתים של מאזן העומסים. מפרידים בין רשימת הצמדים key=value באמצעות פסיק.

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

  • ‫--metal-lb-load-balancer-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במאגר הצמתים של מאזן העומסים. כל taint הוא זוג של מפתח=ערך שמשויך לאפקט, שחייב להיות אחד מהערכים הבאים: 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 ויש להם את ההכתמה 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: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים של מישור הבקרה. מפרידים בין רשימת הצמדים key=value באמצעות פסיק.
    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במישור הבקרה. כל טיינט הוא צמד של מפתח=ערך שמשויך לאפקט, שיכול להיות אחד מהערכים הבאים: 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 של שירותים ו-Pods

• ‫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, לשימוש ב-Pods באשכול. טווח ה-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: סוג האחסון שבו נוצרים כרכי PV במהלך יצירת האשכול.

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

גלילה ידנית

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

אם צריך, גוללים כדי למלא את ה-placeholder‏ 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של צי כלי הרכב אחרי שיוצרים את האשכול.
• ‫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: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים 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, שמעניק גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

  הערה: בנוסף למדיניות RBAC של Kubernetes, צריך להקצות תפקידים מסוימים של ניהול זהויות והרשאות גישה (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: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים של מישור הבקרה. מפרידים בין רשימת הצמדים key=value באמצעות פסיק.
    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים במישור הבקרה. כל טיינט הוא צמד של מפתח=ערך שמשויך לאפקט, שיכול להיות אחד מהערכים הבאים: 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 של שירותים ו-Pods

• ‫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, לשימוש ב-Pods באשכול. טווח ה-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: סוג האחסון שבו נוצרים כרכי PV במהלך יצירת האשכול.

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

לפני שמריצים את הפקודה 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 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 עם tolerations לתזמון של 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

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

הגרסה של Google 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 אחרי שיוצרים את האשכול.

   • ‫region: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים 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: רשימה של כתובות אימייל של המשתמשים שרוצים להעניק להם הרשאות אדמין באשכול. אם אתם מתכוונים לנהל את האשכול, הקפידו להוסיף את כתובת האימייל שלכם.

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

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

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

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

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

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

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

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

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

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

   terraform init
   

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

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

   terraform plan
   

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

   terraform apply
   

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

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

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

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

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

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

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

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

חיבור שער

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

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud components update
   

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

   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