הגדרת תשתית מינימלית

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

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

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

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

• מומלץ לקרוא את הסקירה הכללית על Google Distributed Cloud (תוכנה בלבד) ל-VMware, שכוללת סקירה כללית של כל רכיב שתתקינו בהגדרה הזו.

• גרסאות נתמכות של vSphere

• דרישות הרישיון של vSphere לצורך ההתקנה המינימלית הזו, מספיק רישיון vSphere Standard.

• צריך מופע פעיל של vCenter Server.

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

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

  • יצירה וניהול של פרויקטים
  • סקירה כללית על IAM
  • חשבונות שירות

סקירה כללית של התהליך

אלה השלבים העיקריים שנדרשים להגדרה הזו:

1. הגדרת הסביבה מוודאים שאתם עומדים בדרישות לגבי משאבים. אנחנו מספקים דוגמה להגדרה של מארח ESXi ומאגר נתונים של vSphere שעומדים בדרישות של ההתקנה הזו.
2. הגדרת אובייקטים של vSphere רכיבי Google Distributed Cloud פועלים בהיררכיית אובייקטים של vSphere.
3. תכנון כתובות ה-IP. ב-Google Distributed Cloud, צריך לספק כתובות IP לכל הצמתים, בנוסף לכתובות IP וירטואליות (VIP) לגישת אדמין ומשתמש לפריסה. בהגדרה הזו תשתמשו בכתובות IP סטטיות לצמתי האשכול. אנחנו מספקים דוגמאות, אבל מומלץ להתייעץ עם מנהל הרשת כדי לבחור כתובות מתאימות לרשת שלכם.
4. הגדרת כללים לחומת האש ולשרת ה-proxy
5. הגדרת Google Cloud משאבים, כולל Google Cloud פרויקט שבו תשתמשו להגדרה ולניהול של Google Distributed Cloud, וחשבון שירות עם ההרשאות הנדרשות לגישה ולהורדה של תוכנת רכיבים של Google Distributed Cloud.

1. מגדירים את הסביבה

להתקנה המינימלית הזו, אפשר להשתמש במארח פיזי יחיד שבו פועל ESXi.

1. מוודאים שלמארח יש את הקיבולת המינימלית הבאה של יחידת העיבוד המרכזית (CPU), זיכרון ה-RAM ונפח האחסון:

   • מעבד עם 8 ליבות פיזיות במהירות 2.7GHz עם הפעלת ריבוי הליכי משנה
   • ‫RAM בנפח 80 גיביבייט (GiB)
   • אחסון בנפח ‎470 GiB

2. מוודאים שמותקנת גרסה ESXi 7.0u2 ואילך.

3. מוודאים שאתם משתמשים ב-vCenter Server בגרסה 7.0u2 ואילך.

דוגמה למארח ולמאגר נתונים

דוגמה למארח ESXi ולמאגר נתונים של vSphere שעומדים בדרישות:

• הגדרות של מארח ESXi:

  • יצרן: Dell Inc.
  • מעבדים פיזיים: 8 מעבדים במהירות 2.7‎ GHz
  • סוג המעבד: Intel(R) Xeon(R) Platinum 8168 CPU @ 2.70 GHz
  • שקעי מעבד: 2
  • גרסת ESXi: ‏ 7.0u2 ואילך
  • גרסת vCenter Server: ‏ 7.0u2 ואילך
  • Hyperthreading: enabled

• הגדרת מאגר הנתונים:

  • סוג: VMFS 6.82
  • סוג הכונן: SSD
  • ספק: DELL
  • סוג הכונן: לוגי
  • רמת RAID: ‏ RAID1

2. הגדרת אובייקטים ב-vSphere

מגדירים את האובייקטים הבאים בסביבת vSphere:

• מרכז נתונים של vSphere

• אשכול vSphere

• vSphere datastore

• רשת vSphere

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

אם הגדרתם מאגר נתונים של vSAN, אתם יכולים להשתמש ב-govc כדי ליצור תיקייה בספרייה datastore לשימוש בדיסק של מכונה וירטואלית (VMDK) ב-Google Distributed Cloud:

govc datastore.mkdir -namespace=true data-disks

3. תכנון כתובות ה-IP

כפי שראיתם בסקירה הכללית של Google Distributed Cloud, התקנה של Google Distributed Cloud דורשת מספר כתובות IP, כולל:

• כתובות IP של כל הצמתים
• כתובות IP וירטואליות (VIP) לגישה לרכיבי מישור הבקרה, כמו שרתי Kubernetes API ולאפליקציות שפועלות באשכולות המשתמשים
• טווחים של CIDR לתקשורת בין קבוצות Pod ושירותים

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

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

• ב-Google Distributed Cloud אפשר לבחור בין הקצאת כתובות IP סטטיות לצומתי האשכול או שימוש בשרת DHCP. בהתקנה הפשוטה הזו, תשתמשו בכתובות IP סטטיות.

דוגמה ל-VLAN

במקרה של התקנה קטנה, מומלץ למקם את תחנת העבודה של האדמין, את הצמתים של אשכול האדמין ואת הצמתים של אשכול המשתמשים באותו VLAN ברשת vSphere. לדוגמה, נניח שכל כתובות ה-IP בטווח 172.16.20.0/24 מנותבות ל-VLAN מסוים. נניח גם שמנהל הרשת אומר שאפשר להשתמש בכתובות 172.16.20.49 עד 172.16.20.69 למכונות וירטואליות ולכתובות IP וירטואליות (VIP).

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

כתובות IP של אשכול אדמין ואשכול משתמשים (לחיצה להגדלה)

כתובת IP לדוגמה: תחנת עבודה של אדמין

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

דוגמאות לכתובות IP: צמתי אשכול

בטבלה הבאה מופיעה דוגמה לאופן שבו אפשר להשתמש בכתובות IP לצמתים של אשכול. שימו לב שהטבלה מציגה כתובות של שני צמתים נוספים: admin-vm-6 ו-user-vm-5. הצמתים הנוספים נדרשים במהלך שדרוגים, עדכונים ותיקונים אוטומטיים של האשכול. מידע נוסף זמין במאמר בנושא ניהול כתובות IP של צמתים.

שם המארח של ה-VM	תיאור	כתובת IP
admin-vm-1	צומת של מישור הבקרה עבור אשכול האדמין.	172.16.20.50
admin-vm-2	צומת של מישור הבקרה עבור אשכול האדמין.	172.16.20.51
admin-vm-3	צומת של מישור הבקרה עבור אשכול האדמין.	172.16.20.52
user-vm-1	צומת מישור הבקרה של אשכול המשתמשים.	172.16.20.53
user-vm-2	צומת עובד באשכול משתמשים	172.16.20.54
user-vm-3	צומת עובד באשכול משתמשים	172.16.20.55
user-vm-4	צומת עובד באשכול משתמשים	172.16.20.56
user-vm-5		172.16.20.57

כתובות IP לדוגמה: VIP לאשכול הניהול

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

VIP	תיאור	כתובת IP
כתובת VIP לשרת Kubernetes API של אשכול האדמין	מוגדר במאזן העומסים של אשכול האדמין.	172.16.20.58

דוגמאות לכתובות IP: כתובות IP וירטואליות לאשכול המשתמשים

בטבלה הבאה מוצגת דוגמה לאופן שבו אפשר לציין כתובות VIP עבור אשכול המשתמשים.

שימו לב שכתובת ה-IP הווירטואלית של שרת ה-API של Kubernetes של אשכול המשתמשים וכתובת ה-IP הווירטואלית של ה-Ingress נמצאות באותו VLAN כמו צמתי העובדים וצמתי מישור הבקרה.

VIP	תיאור	כתובת IP
כתובת IP וירטואלית (VIP) לשרת Kubernetes API של אשכול המשתמשים	מוגדר במאזן העומסים של אשכול האדמין.	172.16.20.59
כתובת VIP של תעבורת נתונים נכנסת (Ingress)	מוגדר במאזן העומסים של אשכול המשתמשים.	172.16.20.60
כתובות VIP של שירותים	‫10 כתובות לשירותים מהסוג LoadBalancer. מוגדר לפי הצורך במאזן העומסים של אשכול המשתמשים. שימו לב שהטווח הזה כולל את כתובת ה-VIP של ה-Ingress. זו דרישה למאזן העומסים של MetalLB.	‫172.16.20.60 - 172.16.20.69

כתובות IP של Pods ושירותים

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

כדי לעשות את זה, מציינים טווח CIDR לשימוש בכתובות IP של Pod וטווח CIDR אחר לשימוש בכתובות ClusterIP של שירותי Kubernetes. ההגדרות האלה מצוינות כחלק מהגדרת האשכול, כמו שמוסבר בחלק הבא של המדריך הזה.

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

מטרה	טווח CIDR שמוגדר כברירת מחדל
‫Pods באשכול אדמין	192.168.0.0/16
‫Pods באשכול משתמש	192.168.0.0/16
שירותים של אשכול אדמין	10.96.232.0/24
שירותים באשכול משתמש	10.96.0.0/20

הערכים שמוגדרים כברירת מחדל ממחישים את הנקודות האלה:

• טווח ה-CIDR של ה-Pod יכול להיות זהה בכמה אשכולות.

• טווח ה-CIDR של השירות של אשכול לא יכול לחפוף לטווח ה-CIDR של השירות של אשכול אחר.

• בדרך כלל צריך יותר פודים משירותים, ולכן עבור אשכול נתון, כדאי להשתמש בטווח CIDR של פודים שגדול יותר מטווח ה-CIDR של השירות. לדוגמה, טווח ה-Pod שמוגדר כברירת מחדל עבור אשכול משתמשים כולל 2^(32-16) = 2^16 כתובות, אבל טווח השירות שמוגדר כברירת מחדל עבור אשכול משתמשים כולל רק 2^(32-20) = 2^12 כתובות.

הימנעות מחפיפה

במקרים מסוימים, יכול להיות שתצטרכו להשתמש בטווחים של CIDR שאינם ברירת מחדל כדי למנוע חפיפה עם כתובות IP שאפשר להגיע אליהן ברשת שלכם. הטווחים של השירותים וה-Pods לא יכולים לחפוף לכתובות מחוץ לאשכול שרוצים להגיע אליהן מתוך האשכול.

לדוגמה, נניח שטווח השירות הוא 10.96.232.0/24, וטווח הפוד הוא 192.168.0.0/16. כל תעבורה שנשלחת מ-Pod לכתובת באחד מהטווחים האלה תטופל כתעבורה בתוך האשכול ולא תגיע ליעד מחוץ לאשכול.

בפרט, טווחי ה-Service וה-Pod לא יכולים לחפוף ל:

• כתובות ה-IP של הצמתים בכל אשכול

• כתובות IP שמשמשות מכונות של מאזן עומסים

• כתובות VIP שמשמשות צמתים של רמת הבקרה ומאזני עומסים

• כתובת ה-IP של שרתי vCenter, שרתי DNS ושרתי NTP

מומלץ להשתמש בטווחים של כתובות IP פנימיות שמוגדרים על ידי RFC 1918 עבור טווחי ה-Pod והשירות.

זו אחת הסיבות להמלצה להשתמש בכתובות RFC 1918. נניח שטווח ה-Pod או השירות שלכם מכיל כתובות IP חיצוניות. כל תנועה שנשלחת מ-Pod לאחת מהכתובות החיצוניות האלה תטופל כתנועה בתוך האשכול ולא תגיע ליעד החיצוני.

שרת DNS ושער ברירת מחדל

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

• שרת DNS שאפשר להשתמש בו בתחנת העבודה של האדמין ובצמתי האשכול

• שרת NTP שאפשר להשתמש בו בצמתי האשכול

• כתובת ה-IP של שער ברירת המחדל לרשת המשנה שכוללת את תחנת העבודה של האדמין ואת צמתי האשכול. לדוגמה, נניח שתחנת העבודה של האדמין, הצמתים של אשכול האדמין והצמתים של אשכול המשתמש נמצאים כולם ברשת המשנה 172.16.20.0/24. הכתובת של שער ברירת המחדל של רשת המשנה יכולה להיות 172.16.20.1.

4. הגדרה של חומת האש ושרת ה-proxy

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

5. הגדרת משאבים ב- Google Cloud

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

1. בוחרים Google Cloud פרויקט קיים או יוצרים פרויקט חדש.

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

הגדרת Google Cloud CLI

‫Google Cloud CLI הוא כלי של שורת הפקודה שבעזרתו אפשר לעבוד עם הפרויקט. כדי לוודא שיש לכם את הגרסה העדכנית ביותר, פועלים לפי ההוראות שבמאמר התקנת Google Cloud SDK.

ההרשאות הנדרשות

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

תפקידי ה-IAM הבאים מאפשרים ליצור חשבון שירות, להקצות לו תפקידי IAM, להפעיל ממשקי API ולוודא שהכלי gkeadm יכול ליצור ולנהל חשבונות שירות בשבילכם בחלק השני של ההגדרה הזו:

• resourcemanager.projectIamAdmin
• serviceusage.serviceUsageAdmin
• iam.serviceAccountCreator
• iam.serviceAccountKeyAdmin

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

כדי להעניק את התפקידים:

‫Linux ו-macOS

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountKeyAdmin"

Windows

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountKeyAdmin"

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
• ‫ACCOUNT: כתובת האימייל המזהה של חשבון Google שלכם

הגדרה של חשבונות שירות

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

• חשבון שירות לחיבור ולרישום (נוצר אוטומטית)
• חשבון שירות לרישום ביומן ולמעקב (נוצר אוטומטית)
• חשבון שירות לרישום ביומן ביקורת (יצירה ידנית)
• חשבון שירות לגישה לרכיבים (יצירה ידנית)

חשבון השירות של יומן הביקורת

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

   gcloud iam service-accounts create audit-logging-sa \
       --display-name "Audit Logging Service Account" \
       --project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה שלGoogle Cloud הפרויקט.

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

   gcloud iam service-accounts list \
       --project PROJECT_ID
   

3. יוצרים מפתח JSON לחשבון השירות של שירות יומני הביקורת:

   gcloud iam service-accounts keys create audit-logging-key.json \
       --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING
   

   מחליפים את SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING בכתובת האימייל של חשבון השירות של שירות יומני הביקורת.

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

חשבון שירות לגישה לרכיבים

1. בפרויקט Google Cloud , יוצרים חשבון שירות ש-Google Distributed Cloud יכול להשתמש בו כדי להוריד בשמכם קוד של רכיב אשכול מ-Artifact Registry. החשבון הזה נקרא חשבון שירות לגישה לרכיבים.

   gcloud iam service-accounts create component-access-sa \
       --display-name "Component Access Service Account" \
       --project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה שלGoogle Cloud הפרויקט.

2. מוצאים את כתובת האימייל של חשבון השירות החדש שנוצר לגישה לרכיבים:

   gcloud iam service-accounts list \
       --project PROJECT_ID
   

3. יוצרים מפתח JSON לחשבון השירות של רכיב הגישה:

   gcloud iam service-accounts keys create component-access-key.json \
      --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS
   

   מחליפים את SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS בכתובת האימייל של חשבון השירות של רכיב הגישה.

4. מוסיפים את תפקידי ה-IAM הבאים לחשבון השירות של רכיב הגישה:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
       --role "roles/serviceusage.serviceUsageViewer"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
       --role "roles/iam.roleViewer"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
       --role "roles/iam.serviceAccountViewer"
   

הפעלת ממשקי Google APIs

1. מפעילים את ממשקי ה-API הבאים של Google בפרויקט Google Cloud . כך תוכלו להשתמש בכל השירותים שנדרשים ל-Google Distributed Cloud בפרויקט שלכם. Google Cloud

   gcloud services enable --project PROJECT_ID \
       anthos.googleapis.com \
       anthosgke.googleapis.com \
       anthosaudit.googleapis.com \
       cloudresourcemanager.googleapis.com \
       connectgateway.googleapis.com \
       container.googleapis.com \
       gkeconnect.googleapis.com \
       gkehub.googleapis.com \
       gkeonprem.googleapis.com \
       kubernetesmetadata.googleapis.com \
       serviceusage.googleapis.com \
       stackdriver.googleapis.com \
       opsconfigmonitoring.googleapis.com \
       monitoring.googleapis.com \
       logging.googleapis.com \
       iam.googleapis.com \
       storage.googleapis.com

2. אם זו הפעם הראשונה שאתם מפעילים את GKE On-Prem API ‏(gkeonprem.googleapis.com) בפרויקט שלכם, אתם צריכים לאתחל את ה-API. כדי לעשות את זה, מריצים פקודה של ה-CLI של gcloud שמציגה את הגרסאות הזמינות שאפשר להשתמש בהן כדי ליצור אשכול משתמשים:

   gcloud container vmware clusters query-version-config \
       --project=PROJECT_ID \
       --location="us-central1"
   

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

יצירת אשכולות בסיסיים