יצירת אשכול משתמשים באמצעות לקוחות 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 כדי ליצור אשכולות במרכז הנתונים שלכם.

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

כשיוצרים אשכול באמצעות לקוח GKE On-Prem API, מצייניםGoogle Cloud פרויקט. אחרי שיוצרים את האשכול, הוא נרשם אוטומטית ל-Fleet של הפרויקט שצוין. הפרויקט הזה נקרא פרויקט המארח של ה-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. אם משתמשים במסוף כדי ליצור את האשכול, GKE On-Prem API מופעל באופן אוטומטי.

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

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

כדי ליצור אשכול משתמשים, צריך קודם ליצור אשכול אדמינים תקין. אשכול האדמין צריך:

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

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

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

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

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

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

אחרי שיוצרים את האשכול, אם רוצים להשתמש בשער החיבור כדי להריץ את 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 הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שנבחר משמש גם כפרויקט המארח של Fleet. הפרויקט הזה צריך להיות זהה לפרויקט שבו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמשים, הוא נרשם אוטומטית ל-Fleet של הפרויקטים שנבחר.

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

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

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

מזינים פרטים בסיסיים על האשכול.

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

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

3. בשדה Google Cloud API Location (מיקום Google Cloud API), בוחרים את האזור 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, שמאפשר גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

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

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

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

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

Networking

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: האזור שבו נמצאת קבוצת השרתים של האדמין. האזור יכול להיות גלובלי או 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: האזור שבו פועלים 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 לא מקצה ל-Services כתובות 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: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים במאגר הצמתים של מאזן העומסים. מפרידים בין רשימת הצמדים key=value באמצעות פסיק.

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

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

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים של מישור הבקרה. כל taint הוא צמד של מפתח=ערך שמשויך לאפקט, שיכול להיות אחד מהערכים הבאים: 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: זהו הנתיב במכונת המארח שבו אפשר לגלות דיסקים שמוצמדים. לכל נקודת הרכבה נוצר נפח אחסון קבוע (PV) מקומי.
4. ‫--lvp-node-mounts-config-storage: סוג האחסון (storage class) שבו נוצרים כרכי 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. זה צריך להיות אותו פרויקט שבו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמשים, הוא נרשם אוטומטית ל-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: האזור שבו פועלים 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: משתמשים בדגל הזה כדי להוסיף תוויות לכל הצמתים של מישור הבקרה. מפרידים בין צמדי המפתח=ערך באמצעות פסיק.
    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• ‫--control-plane-node-taints: משתמשים בדגל הזה כדי להוסיף taints לכל הצמתים של מישור הבקרה. כל taint הוא צמד של מפתח=ערך שמשויך לאפקט, שיכול להיות אחד מהערכים הבאים: 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: זהו הנתיב במכונת המארח שבו אפשר לגלות דיסקים שמוצמדים. לכל נקודת הרכבה נוצר נפח אחסון קבוע (PV) מקומי.
4. ‫--lvp-node-mounts-config-storage: סוג האחסון (storage class) שבו נוצרים כרכי 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 דקות או יותר. אפשר לראות את האשכול במסוף Google Cloud בדף GKE clusters.

רשימה מלאה של הדגלים והתיאורים שלהם זמינה במאמרי העזרה של ה-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 הם זוגות של מפתח=ערך שמשויכים לאפקט. משתמשים ב-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: האזור שבו נמצאת קבוצת השרתים של האדמין. האזור יכול להיות גלובלי או 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של ה-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:

   terraform init
   

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

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

   terraform plan
   

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

   terraform apply
   

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

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

כשיוצרים אשכול משתמשים במסוף, האשכול מוגדר עם כללי מדיניות של בקרת גישה מבוססת-תפקידים (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. מאinitialized את ה-CLI של gcloud לשימוש בפרויקט המארח של הצי, או מריצים את הפקודות הבאות כדי להתחבר באמצעות חשבון Google, להגדיר את פרויקט המארח של הצי כברירת מחדל ולעדכן רכיבים:

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud components update
   

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

   gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
   

   הפקודה הזו מחזירה connect gateway-specific 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