‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

gkectl
מסוףGoogle Cloud
Google Cloud CLI
Terraform

שלושה מהכלים האלה (המסוף, ה-CLI של gcloud ו-Terraform) הם לקוחות של GKE On-Prem API.

במאמר בחירת כלי לניהול מחזור החיים של אשכולות מוסבר איך לבחור את הכלי המתאים.

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

אם אתם מתכננים להשתמש ב-gkectl כדי ליצור את אשכול המשתמשים, ודאו שהגדרתם את תחנת העבודה של האדמין ואתם יכולים להיכנס אליה, כפי שמתואר במאמר יצירת תחנת עבודה של אדמין.
מוודאים שבתחנת העבודה של האדמין מותקנת הגרסה הנדרשת של gkectl. בדרך כלל משתמשים באותה גרסה של gkectl כמו הגרסה שבה משתמשים כשיוצרים את האשכול. מציינים את גרסת האשכול בשדה gkeOnPremVersion בקובץ התצורה של האשכול. במהלך יצירת האשכול, המערכת אוכפת את כללי הגרסאות הבאים:
- הגרסה המשנית של gkectl לא יכולה להיות נמוכה מהגרסה המשנית של האשכול. לדוגמה, אי אפשר ליצור אשכול בגרסה 1.30 באמצעות gkectl בגרסה 1.29. גרסאות התיקון לא משנות. לדוגמה, אתם יכולים להשתמש בגרסה 1.29.0-gke.1456 של gkectl כדי ליצור אשכול עם גרסת תיקון גבוהה יותר, כמו 1.29.1000-gke.94.
- הגרסה המשנית של gkectl לא יכולה להיות גבוהה ביותר משתי גרסאות משניות מגרסת האשכול. לדוגמה, אם יוצרים אשכול בגרסה 1.28, הגרסה של gkectl יכולה להיות 1.29 או 1.30. אבל אי אפשר להשתמש בגרסה 1.31 של gkectl, כי היא גבוהה בשלוש גרסאות משניות מגרסת האשכול.
אם צריך, אפשר לעיין במאמר הורדת gkectl כדי לקבל גרסה נתמכת של gkectl.
אם עדיין לא עשיתם זאת, הגדירו את המשאבים של Google Cloud כפי שמתואר במסמכים הבאים:
כשמגדירים את הפרויקט המארח של Fleet, חשוב לזכור את הכלי שבחרתם, כי אם בחרתם באחד מלקוחות ה-API של GKE On-Prem, יש ממשקי API נוספים שצריך להפעיל. רשימת ממשקי ה-API שצריך להפעיל בפרויקט המארח של ה-Fleet
כדי ליצור אשכול משתמשים, צריך שיהיה אשכול אדמין שינהל אותו. אם עדיין לא עשיתם זאת, צרו תחנת עבודה אדמין ואשכול אדמין.
מחליטים איזו גרסה של אשכול המשתמשים רוצים להתקין. כשיוצרים אשכול משתמשים, בדרך כלל מתקינים את הגרסה שתואמת לגרסה של אשכול האדמין. אם רוצים להתקין גרסה אחרת באשכול משתמש, אפשר לקרוא את המאמר כללים לשדרוג גרסאות.
אם אתם מתכננים להתקין את גרסה 1.30 או גרסה חדשה יותר, אתם צריכים את Controlplane V2. גם אם אתם מתקינים את גרסה 1.29 או גרסה קודמת, מומלץ להפעיל את Controlplane V2. כשהתכונה Controlplane V2 מופעלת, מישור הבקרה של אשכול המשתמש פועל בצומת אחד או יותר באשכול המשתמש עצמו. האפשרות השנייה היא ליצור אשכול משתמש שמשתמש ב-kubeception. במקרה של kubeception, מישור הבקרה של אשכול המשתמש פועל בצומת אחד או יותר באשכול האדמין.
קוראים את מסמך התכנון של כתובות ה-IP ומוודאים שיש מספיק כתובות IP זמינות.
קוראים את הסקירה הכללית על איזון עומסים ובוחנים מחדש את ההחלטה לגבי סוג מאזן העומסים שבו רוצים להשתמש. אתם יכולים להשתמש במאזן העומסים המצורף MetalLB, או להגדיר ידנית מאזן עומסים לבחירתכם. באיזון עומסים ידני, צריך להגדיר את מאזן העומסים לפני שיוצרים את אשכול המשתמשים.
חשבו כמה מאגרי צמתים אתם צריכים ובאיזו מערכת הפעלה אתם רוצים להריץ כל אחד מהמאגרים.
חשבו אם אתם רוצים להשתמש באשכולות vSphere נפרדים לאשכול האדמין ולאשכולות המשתמשים, ואם אתם רוצים להשתמש במרכזי נתונים נפרדים. כדאי גם לחשוב אם אתם רוצים להשתמש במכונות נפרדות של vCenter Server.
בגרסה 1.29 ואילך, בדיקות מקדימות בצד השרת מופעלות כברירת מחדל. בדיקות מקדימות בצד השרת דורשות כללים נוספים של חומת האש. במאמר כללי חומת אש לאשכולות אדמין, חפשו את "בדיקות מקדימות" וודאו שכל כללי חומת האש הנדרשים מוגדרים.

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

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

בקטע הזה מוסבר איך יוצרים אשכול משתמש באמצעות gkectl, המסוף, ה-CLI של gcloud ו-Terraform.

gkectl

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

אלה השלבים העיקריים ליצירת אשכול משתמשים באמצעות gkectl:

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

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

מריצים את gkectl prepare.
יצירת אשכול משתמשים

מריצים את הפקודה gkectl create cluster כדי ליצור אשכול כמו שצוין בקובץ התצורה.
איך מוודאים שאשכול המשתמש פועל

משתמשים ב-kubectl כדי להציג את הצמתים באשכול.

בסיום התהליך, יהיה לכם אשכול משתמשים פעיל שבו תוכלו לפרוס את עומסי העבודה.

אם אתם משתמשים ב-VPC Service Controls, יכול להיות שתראו שגיאות כשתריצו פקודות מסוימות של gkectl, כמו "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". כדי להימנע מהשגיאות האלה, הוסיפו את הפרמטר --skip-validation-gcp לפקודות שלכם.

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

אם השתמשתם ב-gkeadm כדי ליצור את תחנת העבודה של הניהול, gkeadm יצרה תבנית לקובץ התצורה של אשכול המשתמשים בשם user-cluster.yaml. בנוסף, gkeadm מילא בשבילכם חלק מהשדות.

אם לא השתמשתם ב-gkeadm כדי ליצור את תחנת העבודה של האדמין, אתם יכולים להשתמש ב-gkectl כדי ליצור תבנית לקובץ התצורה של אשכול המשתמשים.

כדי ליצור תבנית לקובץ התצורה של אשכול המשתמש:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

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

‫OUTPUT_FILENAME: נתיב לבחירתכם לתבנית שנוצרה. אם לא משתמשים בדגל הזה, gkectl נותן לקובץ את השם user-cluster.yaml וממקם אותו בספרייה הנוכחית.

‫VERSION: מספר הגרסה הרצויה. לדוגמה: gkectl create-config cluster --gke-on-prem-version=1.36.100-gke.144.

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

`name`

בשדה name נותנים שם לאשכול המשתמש.

`gkeOnPremVersion`

השדה הזה כבר מלא. הוא מציין את הגרסה של Google Distributed Cloud. לדוגמה, 1.36.100-gke.144.

`enableAdvancedCluster`

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

שימו לב להבדלים הבאים בין הגרסאות:

בגרסה 1.31, התכונה של אשכול מתקדם נמצאת בגרסת טרום-השקה (Preview):
- אפשר להפעיל את התכונה "אשכול מתקדם" בזמן יצירת האשכול רק לאשכולות חדשים בגרסה 1.31.
- אחרי שמפעילים את האשכול המתקדם, אי אפשר לשדרג את האשכול לגרסה 1.32. צריך להפעיל את האשכול המתקדם רק בסביבת בדיקה.
בגרסה 1.32, התכונה המתקדמת של אשכולות זמינה לכולם.
- כברירת מחדל, אשכולות של משתמשים נוצרים כאשכולות מתקדמים. כדי ליצור אשכול לא מתקדם, צריך להגדיר במפורש את enableAdvancedCluster ל-false.
- באשכולות שבהם מופעלת התכונה "אשכולות מתקדמים", אפשר לשדרג את האשכולות.
בגרסה 1.33 ואילך, כל האשכולות נוצרים כאשכולות מתקדמים. אם מגדירים את enableAdvancedCluster לערך false, יצירת האשכול נכשלת.

`enableControlplaneV2`

כדי ליצור אשכול משתמש עם Controlplane V2, מגדירים את enableControlplaneV2 ל-true.

אם מפעילים את האשכול המתקדם, צריך להגדיר את enableControlplaneV2 לערך true.

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

kubeception

אם מגדירים את השדה הזה ל-false, האשכול ישתמש ב-kubeception. ב-kubeception, מישור הבקרה של אשכול המשתמש פועל בצמתים באשכול האדמין.

באשכול kubeception:

מגדירים את enableControlplaneV2 להיות false.
אל תמלאו את הקטע controlPlaneIPBlock.
מציינים את כתובות ה-IP של צומתי מישור הבקרה של אשכול המשתמש בקובץ בלוק ה-IP של אשכול האדמין.

`enableDataplaneV2`

מגדירים את enableDataplaneV2 לערך true.

`vCenter`

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

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

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

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

שימוש במרכז נתונים אחד ובאשכול vSphere אחד

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

שימוש באשכולות vSphere נפרדים

אם רוצים ליצור אשכול משתמשים שנמצא באשכול vSphere משלו, צריך לציין ערך ל-vCenter.cluster בקובץ התצורה של אשכול המשתמשים.

אם אשכול האדמין ואשכול המשתמש נמצאים באשכולות vSphere נפרדים, הם יכולים להיות באותו מרכז נתונים או במרכזי נתונים שונים.

שימוש במרכזי נתונים נפרדים של vSphere

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

אם מציינים את vCenter.datacenter בקובץ התצורה של אשכול המשתמש, צריך לציין גם את:

vCenter.networkName
‫vCenter.datastore או vCenter.storagePolicyName
‫vCenter.cluster או vCenter.resourcePool

שימוש בחשבונות vCenter נפרדים

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

שימוש במכונות נפרדות של שרת vCenter

במצבים מסוימים, כדאי ליצור אשכול משתמש שמשתמש במכונה משלו של vCenter Server. כלומר, אשכול האדמין ואשכול המשתמשים שמשויך אליו משתמשים במכונות שונות של vCenter Server.

לדוגמה, במיקום קצה, יכול להיות שתרצו להפעיל את vCenter Server במכונה פיזית אחת, ואת ESXi במכונה פיזית אחת או יותר. לאחר מכן תוכלו להשתמש במכונה המקומית של vCenter Server כדי ליצור היררכיית אובייקטים של vSphere, כולל מרכזי נתונים, אשכולות, מאגרי משאבים, מאגרי נתונים ותיקיות.

ממלאים את כל הקטע vCenter בקובץ התצורה של אשכול המשתמש. חשוב במיוחד לציין ערך ל-vCenter.address ששונה מהכתובת של שרת ה-vCenter שציינתם בקובץ התצורה של אשכול האדמין. לדוגמה:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

ממלאים גם את השדה network.vCenter.networkName.

`network`

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

משרת DHCP שהגדרתם מראש. מגדירים את network.ipMode.type לערך "dhcp".
מרשימה של כתובות IP סטטיות שאתם מספקים. מגדירים את network.ipMode.type לערך "static" ויוצרים קובץ בלוק IP שמספק את כתובות ה-IP הסטטיות. במאמר דוגמה לקובצי תצורה מלאים מופיעה דוגמה לקובץ של בלוק IP.

אם החלטתם להשתמש בכתובות IP סטטיות לצומתי העובדים, מלאו את השדה network.ipMode.ipBlockFilePath.

צומתי מישור הבקרה של אשכול המשתמשים צריכים לקבל את כתובות ה-IP שלהם מרשימה של כתובות סטטיות שאתם מספקים. זה נכון גם אם צומתי העובדים מקבלים את הכתובות שלהם משרת DHCP. כדי לציין כתובות IP סטטיות לצומתי מישור הבקרה, ממלאים את הקטע network.controlPlaneIPBlock. אם אתם רוצים אשכול משתמשים בזמינות גבוהה (HA), ציינו שלוש כתובות IP. אחרת, צריך לציין כתובת IP אחת.

מציינים שרתי DNS ו-NTP על ידי מילוי הקטע hostConfig. שרתי ה-DNS ושרתי ה-NTP האלה מיועדים לצומתי מישור הבקרה. אם אתם משתמשים בכתובות IP סטטיות לצומתי העובדים, שרתי ה-DNS ושרתי ה-NTP האלה מיועדים גם לצומתי העובדים.

הערכים של network.podCIDR ו-network.serviceCIDR מאוכלסים מראש, ואפשר להשאיר אותם ללא שינוי, אלא אם הם מתנגשים עם כתובות שכבר נמצאות בשימוש ברשת. ‫Kubernetes משתמש בטווחים האלה כדי להקצות כתובות IP ל-Pods ולשירותים באשכול.

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

`loadBalancer`

הקצאת VIP לשרת ה-API של Kubernetes באשכול המשתמש. הקצו כתובת VIP נוספת לשירות ה-ingress של אשכול המשתמשים. מזינים את כתובות ה-VIP כערכים של loadBalancer.vips.controlPlaneVIP ו-loadBalancer.vips.ingressVIP.

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

איזון עומסים בחבילה של MetalLB. מגדירים את loadBalancer.kind לערך "MetalLB". מלאו גם את הקטע loadBalancer.metalLB.addressPools והגדירו את enableLoadBalancer לערך true לפחות באחד ממאגרי הצמתים. מידע נוסף זמין במאמר איזון עומסים בחבילה עם MetalLB.
איזון עומסים ידני. מגדירים את loadBalancer.kind ל-"ManualLB" וממלאים את הקטע manualLB. מידע נוסף על איזון עומסים ידני

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

`advancedNetworking`

אם אתם מתכננים ליצור שער NAT לתעבורת נתונים יוצאת, הגדירו את advancedNetworking לערך true.

`multipleNetworkInterfaces`

מחליטים אם רוצים להגדיר כמה ממשקי רשת ל-Pods, ומגדירים את multipleNetworkInterfaces בהתאם.

`storage`

אם רוצים להשבית את הפריסה של רכיבי vSphere CSI, מגדירים את storage.vSphereCSIDisabled לערך true.

`masterNode`

בקטע masterNode, אתם יכולים לציין כמה צומתי מישור בקרה אתם רוצים לאשכול המשתמש: ציינו 3 לאשכול בזמינות גבוהה (HA) או 1 לאשכול שלא בזמינות גבוהה. אתם יכולים גם לציין מאגר נתונים לצומתי מישור הבקרה, ולהחליט אם להפעיל שינוי גודל אוטומטי לצומתי מישור הבקרה.

אם השדה enableAdvancedCluster הוא true, צריך להגדיר את השדה replicas לערך 3. באשכולות מתקדמים יש תמיכה רק באשכולות משתמשים עם זמינות גבוהה.

זכרו שציינתם כתובות IP לצומתי מישור הבקרה בקטע network.controlPlaneIPBlock.

`nodePools`

מאגר צמתים הוא קבוצה של צמתים באשכול, שלכולם יש את אותה הגדרה. לדוגמה, הצמתים במאגר אחד יכולים להריץ את Windows והצמתים במאגר אחר יכולים להריץ את Linux.

צריך לציין לפחות מאגר צמתים אחד על ידי מילוי הקטע nodePools.

אם מפעילים את האשכול המתקדם, צריך להגדיר את nodePools[i].osImageType לערך ubuntu_cgv2.

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

`antiAffinityGroups`

מגדירים את antiAffinityGroups.enabled לערך true או false.

השדה הזה מציין אם Google Distributed Cloud יוצר כללי אי-קרבה של Distributed Resource Scheduler ‏(DRS) לצומתי העובדים, כך שהם יתפרסו על פני לפחות שלושה מארחים פיזיים במרכז הנתונים.

`stackdriver`

אם רוצים להפעיל את Cloud Logging ו-Cloud Monitoring באשכול, ממלאים את הקטע stackdriver.

כברירת מחדל, חובה למלא את הקטע הזה. כלומר, אם לא תמלאו את הקטע הזה, תצטרכו לכלול את הדגל --skip-validation-stackdriver כשאתם מריצים את gkectl create cluster.

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

המזהה בשדה stackdriver.projectID צריך להיות זהה למזהה בשדות gkeConnect.projectID ו-cloudAuditLogging.projectID.
האזור של Google Cloud שמוגדר ב-stackdriver.clusterLocation צריך להיות זהה לאזור שמוגדר ב-cloudAuditLogging.clusterLocation וב-gkeConnect.location. בנוסף, אם הערך של gkeOnPremAPI.enabled הוא true, צריך להגדיר את אותו אזור ב-gkeOnPremAPI.location.

אם מזהי הפרויקטים והאזורים לא זהים, יצירת האשכול תיכשל.

`gkeConnect`

אשכול המשתמשים צריך להיות רשום ב- Google Cloud fleet.

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

בגרסה 1.28 ואילך, אפשר לציין אזור שבו שירותי Fleet ו-Connect פועלים ב-gkeConnect.location. אם לא כוללים את השדה הזה, האשכול משתמש במכונות הגלובליות של השירותים האלה.

אם אתם כוללים את gkeConnect.location בקובץ התצורה, האזור שאתם מציינים חייב להיות זהה לאזור שהוגדר ב-cloudAuditLogging.clusterLocation, ב-stackdriver.clusterLocation וב-gkeOnPremAPI.location. אם האזורים לא זהים, יצירת האשכול תיכשל.

`gkeOnPremAPI`

בגרסה 1.16 ואילך, אם GKE On-Prem API מופעל בפרויקט ב-Google Cloud , כל האשכולות בפרויקט רשומים ל-GKE On-Prem API באופן אוטומטי באזור שהוגדר ב-stackdriver.clusterLocation. האזור של gkeOnPremAPI.location צריך להיות זהה לאזור שצוין ב-cloudAuditLogging.clusterLocation, ב-gkeConnect.location (אם השדה נכלל בקובץ התצורה) וב-stackdriver.clusterLocation.

אם אתם רוצים לרשום את כל האשכולות בפרויקט ל-GKE On-Prem API, הקפידו לבצע את השלבים שמפורטים בקטע לפני שמתחילים כדי להפעיל את GKE On-Prem API בפרויקט ולהשתמש בו.
אם אתם לא רוצים לרשום את האשכול ב-GKE On-Prem API, צריך לכלול את הקטע הזה ולהגדיר את gkeOnPremAPI.enabled כ-false. אם אתם לא רוצים לרשום אשכולות בפרויקט, השביתו את gkeonprem.googleapis.com (שם השירות של GKE On-Prem API) בפרויקט. הוראות מפורטות זמינות במאמר השבתת שירותים.

`cloudAuditLogging`

אם רוצים לשלב את יומני הביקורת משרת ה-API של Kubernetes באשכול עם יומני הביקורת של Cloud, ממלאים את הקטע cloudAuditLogging.

שימו לב לדרישות הבאות:

אם מפעילים את האשכול המתקדם, צריך להגדיר את cloudAuditLogging.serviceAccountKeyPath לאותו נתיב כמו stackdriver.serviceAccountKeyPath.
המזהה בשדה cloudAuditLogging.projectID צריך להיות זהה למזהה בשדות gkeConnect.projectID ו-stackdriver.projectID.
האזור ב-cloudAuditLogging.clusterLocation צריך להיות זהה לאזור שמוגדר ב-gkeConnect.location וב-stackdriver.clusterLocation. בנוסף, אם הערך של gkeOnPremAPI.enabled הוא true, צריך להגדיר את אותו אזור במדיניות gkeOnPremAPI.location.

אם מזהי הפרויקטים והאזורים לא זהים, יצירת האשכול תיכשל.

דוגמה לקובצי תצורה מלאים

דוגמה לקובץ בלוק IP ולקובץ תצורה של אשכול משתמש:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.36.100-gke.144
enableControlplaneV2: true
enableAdvancedCluster: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
enableDataplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: "ubuntu_cgv2"
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
  disableVsphereResourceMetrics: false
cloudAuditLogging:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

אלה הנקודות החשובות שצריך להבין בדוגמה שלמעלה:

השדה nodePools.replicas מוגדר ל-3, כלומר יש שלושה צומתי עובדים ב-"worker-node-pool". כל הצמתים העובדים משתמשים בכתובות IP סטטיות כי network.ipMode.type מוגדר ל-"static".
כתובות ה-IP הסטטיות של צומתי העובדים מצוינות בקובץ של בלוק IP. בקובץ של בלוק ה-IP יש ארבע כתובות, למרות שיש רק שלושה צומתי עובד. כתובת ה-IP הנוספת נדרשת במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול.
שרתי DNS ו-NTP מצוינים בקטע hostConfig. בדוגמה הזו, שרתי ה-DNS ושרתי ה-NTP האלה מיועדים לצומתי מישור הבקרה ולצומתי העובדים. הסיבה לכך היא שלצומתי העובדים יש כתובות IP סטטיות. אם צומתי העובדים היו מקבלים את כתובות ה-IP שלהם משרת DHCP, שרתי ה-DNS וה-NTP האלה היו מיועדים רק לצומתי מישור הבקרה.
כתובות ה-IP הסטטיות של שלושת הצמתים של מישור הבקרה מצוינות בקטע network.controlPlaneIPBlock של קובץ התצורה של אשכול המשתמש. אין צורך בכתובת IP נוספת בבלוק הזה.
‫Controlplane V2 מופעל.
השדה masterNode.replicas מוגדר ל-3, כך שלמישור הבקרה של האשכול תהיה זמינות גבוהה.
כתובת ה-VIP של מישור הבקרה וכתובת ה-VIP של תעבורת הנתונים הנכנסת נמצאות באותו VLAN כמו צומתי העובדים וצומתי מישור הבקרה.
כתובות ה-VIP שמוקצות לשירותים מסוג LoadBalancer מצוינות בקטע loadBalancer.metalLB.addressPools בקובץ התצורה של אשכול המשתמש. כתובות ה-VIP האלה נמצאות באותה רשת VLAN כמו צומתי העובדים וצומתי מישור הבקרה. קבוצת כתובות ה-VIP שמצוינות בקטע הזה חייבת לכלול את כתובת ה-VIP של הכניסה, ואסור שהיא תכלול את כתובת ה-VIP של מישור הבקרה.
קובץ התצורה של אשכול המשתמשים לא כולל קטע vCenter. לכן, אשכול המשתמש משתמש באותם משאבי vSphere כמו אשכול האדמין.

אימות קובץ התצורה

אחרי שממלאים את קובץ התצורה של אשכול המשתמש, מריצים את הפקודה gkectl check-config כדי לוודא שהקובץ תקין. התמיכה בפקודה gkectl check-config באשכולות של משתמשים מתקדמים נוספה בגרסאות הבאות: ‎1.32.700+‎,‏ ‎1.33.300+‎ ו-‎1.34.0‎ ואילך. אם תתקינו גרסה ישנה יותר באשכול מתקדם, הפקודה תיכשל.

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

‫ADMIN_CLUSTER_KUBECONFIG: הנתיב של קובץ kubeconfig של אשכול האדמין
‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמש

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

אם אתם רוצים לדלג על האימותים שאורכים יותר זמן, העבירו את הדגל --fast. כדי לדלג על אימותים ספציפיים, משתמשים בדגלים --skip-validation-xxx. למידע נוסף על הפקודה check-config, קראו את המאמר הרצת בדיקות טרום-טיסה.

(אופציונלי) ייבוא קובצי אימג' של מערכת ההפעלה ל-vSphere, והעברת קובצי אימג' של קונטיינרים ל-registry פרטי

מריצים את gkectl prepare אם מתקיים אחד מהתנאים הבאים:

אשכול המשתמשים נמצא במרכז נתונים של vSphere ששונה מאשכול האדמין.
לאשכול המשתמשים יש שרת vCenter שונה מאשכול האדמין.
לאשכול המשתמשים יש תיקיית vCenter שונה מזו של אשכול האדמין.
אשכול המשתמשים משתמש ב-Container Registry פרטי ששונה מהמאגר הפרטי שבו משתמש אשכול האדמין.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

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

‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין
‫BUNDLE: הנתיב של קובץ החבילה. הקובץ הזה נמצא בתחנת העבודה של האדמין ב-/var/lib/gke/bundles/. לדוגמה:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.36.100-gke.144-full.tgz
```
‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמש

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

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

איתור קובץ kubeconfig של אשכול המשתמשים

הפקודה gkectl create cluster יוצרת קובץ kubeconfig בשם USER_CLUSTER_NAME-kubeconfig בספרייה הנוכחית. תצטרכו את קובץ ה-kubeconfig הזה בהמשך כדי ליצור אינטראקציה עם אשכול המשתמשים.

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

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

בפלט מוצג שם האשכול. לדוגמה:

NAME
my-user-cluster

אם רוצים, אפשר לשנות את השם והמיקום של קובץ ה-kubeconfig.

איך מוודאים שאשכול המשתמש פועל

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

מחליפים את USER_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמש.

בפלט מוצגים הצמתים של אשכול המשתמשים. לדוגמה:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

המסוף

קדימה, מתחילים

נכנסים לדף Create VM cluster במסוף Google Cloud .

כניסה לדף Create VM cluster
בוחרים את הפרויקט ב- Google Cloud שבו רוצים ליצור את האשכול. הפרויקט שנבחר משמש כפרויקט המארח של ה-fleet. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר.
בקטע Choose your cluster type, בוחרים באפשרות Create a user cluster for an existing admin cluster.

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

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

מזינים שם לאשכול המשתמשים.
בקטע Admin cluster, בוחרים את אשכול האדמין מהרשימה. אם לא ציינתם שם לאשכול האדמין כשיצרתם אותו, השם נוצר בפורמט gke-admin-[HASH]. אם אתם לא מזהים את שם אשכול האדמין, הריצו את הפקודה הבאה בתחנת העבודה של האדמין:
```
KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
```
אם אשכול האדמין שבו אתם רוצים להשתמש לא מוצג, עיינו בקטע פתרון הבעיות אשכול האדמין לא מוצג ברשימה הנפתחת Cluster basics.
בשדה GCP API Location, בוחרים את האזור 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.
בוחרים את הגרסה של Google Distributed Cloud לאשכול המשתמשים.
כיוצרי האשכול, אתם מקבלים הרשאות אדמין באשכול. אם רוצים, אפשר להזין את כתובת האימייל של משתמש אחר שינהל את האשכול בשדה Cluster admin user בקטע Authorization.

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

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

מישור הבקרה

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

בשדה Control-plane node vCPUs, מזינים את מספר המעבדים הווירטואליים (מינימום 4) לכל צומת במישור הבקרה של אשכול המשתמשים.
בשדה Control-plane node memory, מזינים את גודל הזיכרון ב-MiB (מינימום 8,192, וצריך להיות כפולה של 4) לכל מישור בקרה של אשכול המשתמשים.
בקטע Control-plane nodes, בוחרים את מספר הצמתים של מישור הבקרה באשכול המשתמש. לדוגמה, אתם יכולים לבחור צומת אחד של מישור הבקרה לסביבת פיתוח, ו-3 צמתים של מישור הבקרה לסביבות ייצור עם זמינות גבוהה (HA).
אם רוצים, בוחרים באפשרות Automatic node resizing. שינוי הגודל פירושו שמשאבי ה-vCPU והזיכרון שהוקצו לצומת מותאמים באופן אוטומטי. כשהתכונה מופעלת, הגודל של צומתי מישור הבקרה באשכול המשתמשים משתנה בהתאם למספר הצמתים העובדים באשכול המשתמשים. לכן, כשמוסיפים עוד צומתי עובדים לאשכול המשתמש, הגודל של צומתי מישור הבקרה גדל.
בקטע Control plane node IPs, מזינים את כתובות ה-IP של השער, המסכה של רשת המשנה והצמתים של מישור הבקרה.
לוחצים על Next כדי לעבור לקטע Networking.

Networking

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

בקטע Node IPs, בוחרים את IP mode לאשכול המשתמשים. צריך לבחור אחת מהאפשרויות האלה:
- ‫DHCP: בוחרים באפשרות DHCP אם רוצים שצומתי האשכול יקבלו את כתובת ה-IP שלהם משרת DHCP.
- סטטית: בוחרים באפשרות סטטית אם רוצים לספק כתובות IP סטטיות לצומתי האשכול, או אם רוצים להגדיר איזון עומסים ידני.
אם בחרתם באפשרות DHCP, דלגו לשלב הבא כדי לציין את Service and Pod CIDRs. ב-Static IP mode, מספקים את הפרטים הבאים:
1. מזינים את כתובת ה-IP של שער הכניסה של אשכול המשתמשים.
2. מזינים את מסכת רשת המשנה של הצמתים באשכול המשתמש.
3. בקטע IP Addresses, מזינים את כתובות ה-IP ואת שמות המארחים של הצמתים באשכול המשתמש (אופציונלי). אפשר להזין כתובת IPv4 בודדת (למשל 192.0.2.1) או בלוק CIDR של כתובות IPv4 (למשל 192.0.2.0/24).
  - אם מזינים בלוק CIDR, לא צריך להזין שם מארח.
  - אם מזינים כתובת IP ספציפית, אפשר להזין גם שם מארח. אם לא מזינים שם מארח, Google Distributed Cloud משתמש בשם של המכונה הווירטואלית מ-vSphere כשם המארח.
4. לוחצים על + הוספת כתובת IP לפי הצורך כדי להזין עוד כתובות IP.
בקטע Service and Pod CIDRs, המסוף מספק את טווחי הכתובות הבאים לשירותים ול-Pods של Kubernetes:
- Service CIDR: ‏ 10.96.0.0/20
- ‫Pod CIDR: ‏ 192.168.0.0/16
אם אתם מעדיפים להזין טווחי כתובות משלכם, כדאי לעיין בשיטות המומלצות לכתובות IP של Pods ו-Services.
אם בחרתם באפשרות Static IP mode או Enable מישור הבקרה v2, ציינו את הפרטים הבאים בקטע Host config:
1. מזינים את כתובות ה-IP של שרתי ה-DNS.
2. מזינים את כתובות ה-IP של שרתי ה-NTP.
3. אם רוצים, מזינים דומיינים לחיפוש DNS.
לוחצים על Next כדי לעבור לקטע מאזן עומסים (LB).

מאזן עומסים

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

בוחרים את Load balancer type (סוג מאזן העומסים) מהרשימה.

כלול ב-MetalLB

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

בקטע Address pools, מגדירים לפחות מאגר כתובות אחד, באופן הבא:
1. מזינים שם למאגר הכתובות.
2. מזינים טווח של כתובות IP שמכיל את כתובת ה-VIP של תעבורת הנתונים הנכנסת, בסימון CIDR (למשל, ‫192.0.2.0/26) או סימון טווח (למשל, ‫192.0.2.64-192.0.2.72). כדי לציין כתובת IP אחת במאגר, משתמשים ב-‎/32 בסימון ה-CIDR (למשל, ‫192.0.2.1/32).
3. אם כתובות ה-IP של השירותים מסוג LoadBalancer לא נמצאות באותו טווח כתובות IP כמו ה-VIP של תעבורת הנתונים הנכנסת, לוחצים על + Add IP Address Range ומזינים טווח כתובות אחר.
  
  כתובות ה-IP בכל מאגר לא יכולות לחפוף, והן חייבות להיות באותה רשת משנה כמו הצמתים באשכול.
4. בקטע הקצאה של כתובות IP, בוחרים אחת מהאפשרויות הבאות:
  - אוטומטי: בוחרים באפשרות הזו אם רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP ממאגר הכתובות לשירותים מסוג LoadBalancer
  - ידנית: בוחרים באפשרות הזו אם רוצים להשתמש בכתובות מהמאגר כדי לציין ידנית כתובות לשירותים מסוג LoadBalancer.
5. לוחצים על Avoid buggy IP addresses אם רוצים שבבקר MetalLB לא ייעשה שימוש בכתובות IP מהמאגר שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירים צרכניים עם באגים, שעלולים להפיל בטעות תעבורת נתונים שנשלחת לכתובות ה-IP המיוחדות האלה.
6. כשמסיימים, לוחצים על סיום.
אם צריך, לוחצים על Add Address Pool.
בקטע Virtual IPs, מזינים את הפרטים הבאים:
- כתובת ה-VIP של מישור הבקרה: כתובת ה-IP של היעד שאליה נשלחת תעבורת הנתונים לשרת ה-API של Kubernetes באשכול המשתמש. שרת ה-API של Kubernetes לאשכול המשתמש פועל בצומת באשכול האדמין. כתובת ה-IP הזו צריכה להיות באותו דומיין L2 כמו הצמתים של אשכול האדמין. אל תוסיפו את הכתובת הזו בקטע מאגרי כתובות.
- ‫Ingress VIP: כתובת ה-IP שצריך להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress. צריך להוסיף את הכתובת הזו למאגר כתובות בקטע מאגרי כתובות.
לוחצים על Continue.

F5 BIG-IP

אתם יכולים להשתמש ב-F5 BIG-IP לאשכול המשתמש רק אם אשכול האדמין משתמש ב-F5 BIG-IP. חשוב להתקין ולהגדיר את F5 BIG-IP ADC לפני שמשלבים אותו עם Google Distributed Cloud.

שם המשתמש והסיסמה של F5 עוברים בירושה מאשכול האדמין.

בקטע Virtual IPs, מזינים את הפרטים הבאים:
- כתובת ה-VIP של מישור הבקרה: כתובת ה-IP של היעד שאליה נשלחת תעבורת הנתונים לשרת ה-API של Kubernetes.
- ‫Ingress VIP: כתובת ה-IP שצריך להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress.
בשדה Address, מזינים את הכתובת של מאזן העומסים F5 BIG-IP.
בשדה Partition, מזינים את השם של מחיצת BIG-IP שיצרתם לאשכול המשתמש.
בשדה sNAT pool name, מזינים את השם של מאגר ה-SNAT, אם רלוונטי.
לוחצים על Continue.

גלילה ידנית

אתם יכולים להשתמש באיזון עומסים ידני באשכול המשתמש רק אם אתם משתמשים באיזון עומסים ידני באשכול האדמין. ב-Google Distributed Cloud, שרת ה-API של Kubernetes ושרת ה-Proxy של Ingress נחשפים על ידי שירות Kubernetes מסוג LoadBalancer. בוחרים ערכי nodePort משלכם בטווח 30000 - 32767 לשירותים האלה. לשרת ה-proxy של תעבורת הנתונים הנכנסת, בוחרים ערך של nodePort גם לתעבורת הנתונים של HTTP וגם לזו של HTTPS. מידע נוסף זמין במאמר הפעלת מצב איזון עומסים ידני.

בקטע Virtual IPs, מזינים את הפרטים הבאים:
- כתובת ה-VIP של מישור הבקרה: כתובת ה-IP של היעד שאליה נשלחת תעבורת הנתונים לשרת ה-API של Kubernetes.
- ‫Ingress VIP: כתובת ה-IP שצריך להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress.
בשדה Control-plan node port, מזינים ערך nodePort לשרת ה-API של Kubernetes.
בשדה Ingress HTTP node port, מזינים ערך של nodePort לתנועת HTTP לשרת ה-proxy של Ingress.
בשדה Ingress HTTPS node port, מזינים ערך של nodePort לתנועת HTTPS אל שרת ה-proxy של Ingress.
בשדה Konnectivity server node port, מזינים ערך nodePort לשרת Konnectivity.
לוחצים על Continue.

תכונות

בקטע הזה מוצגות התכונות והפעולות שמופעלות באשכול.

האפשרויות הבאות מופעלות באופן אוטומטי ואי אפשר להשבית אותן:
- רישום ב-Cloud Logging של שירותי המערכת
- מעקב בענן אחרי שירותי המערכת
- יומן הביקורת Admin Activity
האפשרויות הבאות מופעלות כברירת מחדל, אבל אתם יכולים להשבית אותן:
- הפעלת מנהל ההתקן של vSphere CSI: נקרא גם vSphere Container Storage Plug-in. מנהל ההתקן של Container Storage Interface (CSI) פועל באשכול Kubernetes שנפרס ב-vSphere כדי להקצות נפחי אחסון מתמידים באחסון של vSphere. מידע נוסף זמין במאמר שימוש במנהל ההתקן של ממשק האחסון של מאגר vSphere.
- הפעלת קבוצות של חוסר-קרבה: כללי חוסר-קרבה של VMware Distributed Resource Scheduler (DRS) נוצרים באופן אוטומטי לצמתים של אשכול המשתמשים, וגורמים להם להתפרס על פני לפחות 3 מארחים פיזיים במרכז הנתונים. מוודאים שסביבת vSphere עומדת בדרישות.
הערה: אם פעלתם לפי ההוראות במאמר הגדרת תשתית מינימלית, יש לכם רק מארח ESXi אחד, ולכן חשוב לוודא שהאפשרות Enable anti-affinity groups לא מסומנת.
לוחצים על Next כדי להגדיר מאגר צמתים.

מאגרי צמתים

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

בקטע ברירות מחדל של מאגר צמתים, מבצעים את הפעולות הבאות:
1. מזינים את שם מאגר הצמתים או מאשרים את השם default-pool.
2. מזינים את מספר vCPUs לכל צומת במאגר (מינימום 4 לכל worker באשכול המשתמשים).
3. מזינים את גודל הזיכרון במביבייט (MiB) לכל צומת במאגר (מינימום 8,192MiB לכל צומת עובד באשכול משתמשים, והערך חייב להיות כפולה של 4).
4. בשדה Nodes, מזינים את מספר הצמתים במאגר (לפחות 3). אם הזנתם כתובות IP סטטיות בשדה Node IPs בקטע Networking, ודאו שהזנתם מספיק כתובות IP כדי להכיל את הצמתים האלה באשכול המשתמשים.
5. בוחרים את סוג קובץ האימג' של מערכת ההפעלה: Ubuntu,‏ Ubuntu Containerd או COS.
6. מזינים את Boot disk size ב-GiB (מינימום 40GiB).
7. אם אתם משתמשים ב-MetalLB כמאזן העומסים, צריך להפעיל את MetalLB במאגר צמתים אחד לפחות. משאירים את האפשרות Use this node pool for MetalLB load balancing מסומנת, או מוסיפים מאגר צמתים אחר לשימוש ב-MetalLB.
בקטע Node pool metadata (optional), אם רוצים להוסיף תוויות וtaints של Kubernetes:
1. לוחצים על ‎+ Add Kubernetes Labels. מזינים את Key ו-Value של התווית. חוזרים לפי הצורך.
2. לוחצים על ‎+ Add Taint. מזינים את הערכים של Key,‏ Value ו-Effect של ה-taint. חוזרים לפי הצורך.
לוחצים על Verify and Complete כדי ליצור את אשכול המשתמשים. יצירת אשכול המשתמשים נמשכת 15 דקות או יותר. במסוף מוצגות הודעות סטטוס בזמן שההגדרות מאומתות והאשכול נוצר במרכז הנתונים.

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

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

‫CLI של gcloud

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

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

איסוף מידע

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

מאתרים את השם ואת מיקום החברות ב-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.
כדי לקבל רשימה של הגרסאות הזמינות:
```
gcloud container vmware 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 פועל ומאחסן את המטא-נתונים שלו.
  - אם אשכול האדמין רשום ב-GKE On-Prem API, צריך להשתמש באותו אזור של אשכול האדמין. כדי לברר מהו האזור של אשכול האדמין, מריצים את הפקודה הבאה:
```
gcloud container vmware admin-clusters list \
  --project=FLEET_HOST_PROJECT_ID \
  --location=-
```
  - אם אשכול האדמין לא רשום ב-GKE On-Prem API, צריך לציין את us-west1 או אזור נתמך אחר. אם בהמשך תרשמו את אשכול האדמין ב-GKE On-Prem API, תצטרכו להשתמש באותו אזור שבו נמצא אשכול המשתמש.
הפלט של הפקודה gcloud container vmware clusters query-version-config אמור להיראות כך:
```
versions:
- isInstalled: true
  version: 1.28.800-gke.109
- version: 1.29.0-gke.1456
- version: 1.29.100-gke.248
- version: 1.29.200-gke.245
- version: 1.29.300-gke.184
```
הפקודה גם מפיקה הסבר על הגרסאות שבהן אפשר להשתמש כדי ליצור או לשדרג אשכולות של משתמשים. הגרסאות המותרות מסומנות ב-isInstalled: true, כלומר לאשכול האדמין יש את הרכיבים הספציפיים לגרסה שהוא צריך כדי לנהל את אשכולות המשתמשים של אותה גרסה. אם אתם רוצים להשתמש בגרסה שמותקנת באשכול האדמין, דלגו לקטע דוגמאות כדי ליצור את אשכול המשתמש.

התקנת גרסה אחרת

אשכול אדמין יכול לנהל אשכולות משתמשים בגרסאות שונות. הפלט של הפקודה query-version-config מציג גרסאות אחרות שאפשר להשתמש בהן כשיוצרים את האשכול. אם רוצים ליצור אשכול משתמשים בגרסה שונה מאשכול הניהול, צריך להוריד ולפרוס את הרכיבים שאשכול הניהול צריך כדי לנהל אשכולות משתמשים בגרסה הזו, באופן הבא:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

מחליפים את VERSION באחת מהגרסאות שמופיעות בפלט של הפקודה query-version-config.

הפקודה מורידה את גרסת הרכיבים שציינתם ב---required-platform-version לאשכול האדמין, ואז פורסת את הרכיבים. עכשיו אפשר ליצור אשכול משתמשים עם הגרסה שצוינה.

אם מריצים מחדש את gcloud container vmware clusters query-version-config, הגרסה שציינתם מסומנת ב-isInstalled: true.

דוגמאות

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

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

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

אם מופיעה שגיאה אחרי שהפקודה gcloud container vmware clusters create פועלת במשך כדקה או יותר, בודקים אם האשכול נוצר באופן חלקי על ידי הפעלת הפקודה הבאה:

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

אם האשכול לא מופיע בפלט, מתקנים את השגיאה ומריצים מחדש את gcloud container vmware clusters create.

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

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

אחרי שמתקנים את השגיאה, מריצים מחדש את gcloud container vmware clusters create.

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

‫MetalLB ו-DHCP

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

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

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

דגל	תיאור
`--admin-users`	מעניקה לכם ולמשתמש אחר זכויות אדמין מלאות באשכול.
`--enable-control-plane-v2`	הפעלת Controlplane V2, שמומלץ ונדרש בגרסה 1.30 ואילך.
`--control-plane-ip-block`	כתובת IP אחת לצומת של מישור הבקרה. כדי ליצור אשכול משתמשים בזמינות גבוהה (HA), צריך לציין שלוש כתובות IP ולהוסיף את הדגל `--replicas=3`.
`--metal-lb-config-address-pools`	שני מאגרי כתובות למאזן העומסים של MetalLB. צריך לפחות מאגר כתובות אחד, ואפשר לציין יותר אם צריך. לנוחות, הדוגמה מכילה מאגר כתובות עם השם "ingress-vip-pool" כתזכורת לכך שכתובת ה-IP של ה-VIP של ה-ingress חייבת להיות באחד ממאגרי הכתובות. כדי לציין את ה-CIDR של כתובת IP אחת, מוסיפים `/32` לכתובת ה-IP.

gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

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

‫USER_CLUSTER_NAME: שם לבחירתכם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
- לכלול עד 40 תווים
- להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
- להתחיל באות
- להסתיים בתו אלפאנומרי
‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של הצי. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדגל --admin-cluster-membership, אפשר להשתמש בשם המלא של האשכול, בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, הריצו את הפקודה gcloud container fleet memberships list.
‫REGION: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). מציינים את us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הפריטים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
- נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

חשוב אם אתם מתכננים להתקין את Cloud Service Mesh, אתם צריכים להתקין את גרסה 1.19.3 ואילך. הפעולה הזו נדרשת כי שירותי Fleet ו-Connect פועלים באזור.
‫VERSION: הגרסה של Google Distributed Cloud באשכול המשתמש.
‫YOUR_EMAIL_ADDRESS ו-ANOTHER_EMAIL_ADDRESS: אם לא תכללו את הדגל --admin-users, כיוצרי האשכול תקבלו כברירת מחדל הרשאות אדמין באשכול. אבל אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. לדוגמה, כדי להוסיף שני אדמינים:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
אחרי שהאשכול נוצר, GKE On-Prem API מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin ב-Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. הטווח חייב להיות לפחות ‎/24.
לדוגמה: --service-address-cidr-blocks=10.96.0.0/20
‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. הטווח חייב להיות לפחות ‎/18.
לדוגמה: --pod-address-cidr-blocks=192.168.0.0/16

‫--metal-lb-config-address-pools: צריך לכלול את הדגל הזה כדי לציין את ההגדרות של מאגרי הכתובות שבהם ישתמש מאזן העומסים MetalLB. הערך של הדגל הוא בפורמט הבא:
```
--metal-lb-config-address-pool '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-ips1: אם מגדירים את הערך True, בקר MetalLB לא יקצה לשירותים כתובות IP שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירי צרכנים עם באגים, שעלולים להפיל בטעות תנועה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False.
- ‫manual-assign: אם לא רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, מגדירים את הערך ל-True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני את אחת מהכתובות במאגר. אם לא מציינים ערך, manual-assign מוגדר כ-False.
- ברשימה של addresses: כל כתובת צריכה להיות טווח בסימון CIDR או בפורמט של טווח עם מקפים. כדי לציין כתובת IP אחת במאגר (למשל, ל-VIP של תעבורת הנתונים הנכנסת), משתמשים ב-‎/32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
שימו לב לנקודות הבאות:
- תוחמים את הערך כולו במירכאות בודדות.
- אי אפשר להשתמש ברווחים.
- מפרידים בין טווחי כתובות ה-IP באמצעות נקודה ופסיק.
לדוגמה:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

‫CONTROL_PLANE_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.
לדוגמה: --control-plane-vip=203.0.113.3
‫INGRESS_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של תעבורת הנתונים הנכנסת.
לדוגמה: --ingress-vip=10.251.134.80

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

‫--enable-dhcp: צריך לכלול את --enable-dhcp אם רוצים שצומתי האשכול יקבלו את כתובת ה-IP שלהם משרת DHCP שאתם מספקים. אל תכללו את הדגל הזה אם אתם רוצים לספק כתובות IP סטטיות לצומתי האשכול, או אם אתם רוצים להגדיר איזון עומסים ידני.

‫MetalLB וכתובות IP סטטיות

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

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

דגל	תיאור
`--admin-users`	מעניקה לכם ולמשתמש אחר זכויות אדמין מלאות באשכול.
`--enable-control-plane-v2`	הפעלת Controlplane V2, שמומלץ ונדרש בגרסה 1.30 ואילך.
`--control-plane-ip-block`	כתובת IP אחת לצומת של מישור הבקרה. כדי ליצור אשכול משתמשים בזמינות גבוהה (HA), צריך לציין שלוש כתובות IP ולהוסיף את הדגל `--replicas=3`.
`--metal-lb-config-address-pools`	שני מאגרי כתובות למאזן העומסים של MetalLB. צריך לפחות מאגר כתובות אחד, ואפשר לציין יותר אם צריך. לנוחות, הדוגמה מכילה מאגר כתובות עם השם "ingress-vip-pool" כתזכורת לכך שכתובת ה-IP של ה-VIP של ה-ingress חייבת להיות באחד ממאגרי הכתובות. כדי לציין את ה-CIDR של כתובת IP אחת, מוסיפים `/32` לכתובת ה-IP.
`--static-ip-config-ip-blocks`	ארבע כתובות IP לצומתי העובדים באשכולות. הכתובות האלה כוללות כתובת לצומת נוסף שאפשר להשתמש בו במהלך השדרוג והעדכון. אפשר לציין עוד כתובות IP לפי הצורך. שם המארח הוא אופציונלי.

gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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

‫USER_CLUSTER_NAME: שם לבחירתכם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
- לכלול עד 40 תווים
- להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
- להתחיל באות
- להסתיים בתו אלפאנומרי
‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של הצי. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדגל --admin-cluster-membership, אפשר להשתמש בשם המלא של האשכול, בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, הריצו את הפקודה gcloud container fleet memberships list.
‫REGION: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). מציינים את us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הפריטים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
- נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

חשוב אם אתם מתכננים להתקין את Cloud Service Mesh, אתם צריכים להתקין את גרסה 1.19.3 ואילך. הפעולה הזו נדרשת כי שירותי Fleet ו-Connect פועלים באזור.
‫VERSION: הגרסה של Google Distributed Cloud באשכול המשתמש.
‫YOUR_EMAIL_ADDRESS ו-ANOTHER_EMAIL_ADDRESS: אם לא תכללו את הדגל --admin-users, כיוצרי האשכול תקבלו כברירת מחדל הרשאות אדמין באשכול. אבל אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. לדוגמה, כדי להוסיף שני אדמינים:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
אחרי שהאשכול נוצר, GKE On-Prem API מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin ב-Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. הטווח חייב להיות לפחות ‎/24.
לדוגמה: --service-address-cidr-blocks=10.96.0.0/20
‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. הטווח חייב להיות לפחות ‎/18.
לדוגמה: --pod-address-cidr-blocks=192.168.0.0/16

‫--metal-lb-config-address-pools: צריך לכלול את הדגל הזה כדי לציין את ההגדרות של מאגרי הכתובות שבהם ישתמש מאזן העומסים MetalLB. הערך של הדגל הוא בפורמט הבא:
```
--metal-lb-config-address-pool '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-ips1: אם מגדירים את הערך True, בקר MetalLB לא יקצה לשירותים כתובות IP שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירי צרכנים עם באגים, שעלולים להפיל בטעות תנועה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False.
- ‫manual-assign: אם לא רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, מגדירים את הערך ל-True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני את אחת מהכתובות במאגר. אם לא מציינים ערך, manual-assign מוגדר כ-False.
- ברשימה של addresses: כל כתובת צריכה להיות טווח בסימון CIDR או בפורמט של טווח עם מקפים. כדי לציין כתובת IP אחת במאגר (למשל, ל-VIP של תעבורת הנתונים הנכנסת), משתמשים ב-‎/32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
שימו לב לנקודות הבאות:
- תוחמים את הערך כולו במירכאות בודדות.
- אי אפשר להשתמש ברווחים.
- מפרידים בין טווחי כתובות ה-IP באמצעות נקודה ופסיק.
לדוגמה:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

‫CONTROL_PLANE_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.
לדוגמה: --control-plane-vip=203.0.113.3
‫INGRESS_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של תעבורת הנתונים הנכנסת.
לדוגמה: --ingress-vip=10.251.134.80

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

‫--static-ip-config-ip-blocks: מציינים את שער ברירת המחדל, את המסכה של רשת המשנה ואת רשימת כתובות ה-IP הסטטיות של צומתי העובדים באשכול המשתמש. הערך של הדגל הוא בפורמט הבא:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
הערך מכיל פלחים שמתחילים במילות המפתח gateway,‏ netmask ו-ips. מפרידים בין הפלחים באמצעות פסיק.

שימו לב לנקודות הבאות:
- תוחמים את הערך כולו במירכאות בודדות.
- אסור להשתמש ברווחים, חוץ מאשר בין כתובת IP לשם מארח.
ברשימה של כתובות ה-IP:
- אפשר לציין כתובת IP ספציפית או בלוק CIDR של כתובות IP.
- צריך להפריד בין כל כתובת IP או בלוק CIDR באמצעות נקודה-פסיק.
- לכתובת IP ספציפית, אפשר לציין שם מארח אחרי כתובת ה-IP. מפרידים בין כתובת ה-IP לשם המארח באמצעות רווח. אם לא מציינים שם מארח, Google Distributed Cloud משתמש בשם של המכונה הווירטואלית מ-vSphere כשם המארח.
- אם מציינים בלוק CIDR, לא מציינים ערך לשם המארח.
לדוגמה:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
‫DNS_SERVER: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי ה-DNS של המכונות הווירטואליות.
‫DNS_SEARCH_DOMAIN: רשימה מופרדת בפסיקים של דומיינים לחיפוש DNS שהמארחים יכולים להשתמש בהם. הדומיינים האלה משמשים כחלק מרשימת חיפוש של דומיינים.
לדוגמה:
```
--dns-search-domains example.com,examplepetstore.com
```
‫NTP_SERVER: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי הזמן שבהם המכונות הווירטואליות ישתמשו.

איזון עומסים ידני וכתובות IP סטטיות

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

אפשר להשתמש במאזן עומסים ידני לאשכול המשתמש רק אם אשכול האדמין משתמש במאזן עומסים ידני. ב-Google Distributed Cloud, שרת ה-API של Kubernetes, שרת ה-proxy של Ingress והשירות הנוסף לצבירת יומנים נחשפים על ידי שירות Kubernetes מסוג LoadBalancer. בוחרים ערכים משלכם ל-nodePort בטווח שבין 30000 ל-32767 בשביל השירותים האלה. לשרת ה-proxy של תעבורת הנתונים הנכנסת, בוחרים ערך של nodePort גם לתעבורת נתונים של HTTP וגם לתעבורת נתונים של HTTPS. מידע נוסף זמין במאמר הפעלת מצב איזון עומסים ידני.

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

דגל	תיאור
`--admin-users`	מעניקה לכם ולמשתמש אחר זכויות אדמין מלאות באשכול.
`--enable-control-plane-v2`	הפעלת Controlplane V2, שמומלץ ונדרש בגרסה 1.30 ואילך.
`--control-plane-ip-block`	כתובת IP אחת לצומת של מישור הבקרה. כדי ליצור אשכול משתמשים בזמינות גבוהה (HA), צריך לציין שלוש כתובות IP ולהוסיף את הדגל `--replicas=3`.
`--static-ip-config-ip-blocks`	ארבע כתובות IP לצומתי העובדים באשכולות. הכתובות האלה כוללות כתובת לצומת נוסף שאפשר להשתמש בו במהלך השדרוג והעדכון. אפשר לציין עוד כתובות IP לפי הצורך. שם המארח הוא אופציונלי.

gcloud container vmware 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 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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

‫USER_CLUSTER_NAME: שם לבחירתכם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
- לכלול עד 40 תווים
- להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
- להתחיל באות
- להסתיים בתו אלפאנומרי
‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של הצי. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמש. בדגל --admin-cluster-membership, אפשר להשתמש בשם המלא של האשכול, בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, הריצו את הפקודה gcloud container fleet memberships list.
‫REGION: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). מציינים את us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הפריטים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול.
- נתוני Cloud Logging ו-Cloud Monitoring של רכיבי המערכת
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
שם האשכול, הפרויקט והמיקום מזהים באופן ייחודי את האשכול ב- Google Cloud.

חשוב אם אתם מתכננים להתקין את Cloud Service Mesh, אתם צריכים להתקין את גרסה 1.19.3 ואילך. הפעולה הזו נדרשת כי שירותי Fleet ו-Connect פועלים באזור.
‫VERSION: הגרסה של Google Distributed Cloud באשכול המשתמש.
‫YOUR_EMAIL_ADDRESS ו-ANOTHER_EMAIL_ADDRESS: אם לא תכללו את הדגל --admin-users, כיוצרי האשכול תקבלו כברירת מחדל הרשאות אדמין באשכול. אבל אם אתם כוללים את --admin-users כדי להגדיר משתמש אחר כאדמין, אתם מבטלים את ברירת המחדל וצריכים לכלול גם את כתובת האימייל שלכם וגם את כתובת האימייל של האדמין האחר. לדוגמה, כדי להוסיף שני אדמינים:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
אחרי שהאשכול נוצר, GKE On-Prem API מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes, כדי להקצות לכם ולמשתמשים אחרים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin ב-Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות.

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

‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. הטווח חייב להיות לפחות ‎/24.
לדוגמה: --service-address-cidr-blocks=10.96.0.0/20
‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. הטווח חייב להיות לפחות ‎/18.
לדוגמה: --pod-address-cidr-blocks=192.168.0.0/16

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

לדוגמה: --control-plane-vip=203.0.113.3
‫INGRESS_VIP: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress.

לדוגמה: --ingress-vip=203.0.113.4
‫INGRESS_HTTP_NODE_PORT: ערך nodePort לתנועת HTTP לשרת ה-proxy של הכניסה (למשל 30243).
‫INGRESS_HTTPS_NODE_PORT: ערך nodePort לתנועת HTTPS לשרת ה-proxy של הכניסה (כמו 30879).

‫--static-ip-config-ip-blocks: מציינים את שער ברירת המחדל, את המסכה של רשת המשנה ואת רשימת כתובות ה-IP הסטטיות של צומתי העובדים באשכול המשתמש. הערך של הדגל הוא בפורמט הבא:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
הערך מכיל פלחים שמתחילים במילות המפתח gateway,‏ netmask ו-ips. מפרידים בין הפלחים באמצעות פסיק.

שימו לב לנקודות הבאות:
- תוחמים את הערך כולו במירכאות בודדות.
- אסור להשתמש ברווחים, חוץ מאשר בין כתובת IP לשם מארח.
ברשימה של כתובות ה-IP:
- אפשר לציין כתובת IP ספציפית או בלוק CIDR של כתובות IP.
- צריך להפריד בין כל כתובת IP או בלוק CIDR באמצעות נקודה-פסיק.
- לכתובת IP ספציפית, אפשר לציין שם מארח אחרי כתובת ה-IP. מפרידים בין כתובת ה-IP לשם המארח באמצעות רווח. אם לא מציינים שם מארח, Google Distributed Cloud משתמש בשם של המכונה הווירטואלית מ-vSphere כשם המארח.
- אם מציינים בלוק CIDR, לא מציינים ערך לשם המארח.
לדוגמה:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
‫DNS_SERVER: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי ה-DNS של המכונות הווירטואליות.
‫DNS_SEARCH_DOMAIN: רשימה מופרדת בפסיקים של דומיינים לחיפוש DNS שהמארחים יכולים להשתמש בהם. הדומיינים האלה משמשים כחלק מרשימת חיפוש של דומיינים.
לדוגמה:
```
--dns-search-domains example.com,examplepetstore.com
```
‫NTP_SERVER: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי הזמן שבהם המכונות הווירטואליות ישתמשו.

דגלים של מישור הבקרה

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

‫--cpus=vCPUS: מספר המעבדים הווירטואליים (מינימום 4) לכל צומת במישור הבקרה של אשכול המשתמשים. אם לא מציינים ערך, ברירת המחדל היא 4 מעבדי vCPU.
‫--memory=MEMORY: גודל הזיכרון במגה-בייטים (MiB) לכל צומת במישור הבקרה של אשכול המשתמשים. הערך המינימלי הוא 8,192 והוא חייב להיות כפולה של 4. אם לא מציינים ערך, ברירת המחדל היא 8192.
‫--replicas=NODES: מספר הצמתים של מישור הבקרה באשכול המשתמש. לדוגמה, אתם יכולים לבחור צומת אחד של מישור הבקרה לסביבת פיתוח, ו-3 צמתים של מישור הבקרה לסביבות ייצור עם זמינות גבוהה (HA).
‫--enable-auto-resize: אם רוצים להפעיל שינוי גודל אוטומטי של צומתי מישור הבקרה באשכול המשתמש, צריך לכלול את --enable-auto-resize. שינוי הגודל פירושו שמשאבי ה-vCPU והזיכרון שהוקצו לצומת מותאמים באופן אוטומטי. כשהיא מופעלת, הגודל של צומתי מישור הבקרה באשכול המשתמשים משתנה בהתאם למספר הצמתים העובדים באשכול המשתמשים. לכן, כשמוסיפים עוד צומתי עובד לאשכול המשתמש, הגודל של צומתי מישור הבקרה גדל.
‫--enable-control-plane-v2: כדי להפעיל את Controlplane V2, שמומלץ להשתמש בו, צריך לכלול את הדגל הזה. כשהתכונה Controlplane V2 מופעלת, מישור הבקרה של אשכול משתמש פועל בצומת אחד או יותר באשכול המשתמש עצמו. בגרסה 1.30 ואילך, נדרש Controlplane V2.

כשמפעילים את Controlplane V2, צריך לציין גם את הדגלים הבאים:
- ‫--dns-servers=DNS_SERVER_1,...: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי ה-DNS של המכונות הווירטואליות.
- ‫--ntp-servers=NTP_SERVER_1,...: רשימה מופרדת בפסיקים של כתובות ה-IP של שרתי הזמן שבהם המכונות הווירטואליות ישתמשו.
- --control-plane-ip-block, בפורמט הבא:
```
  --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'
```
  הערך מכיל פלחים שמתחילים במילות המפתח gateway, netmask ו-ips. מפרידים בין הפלחים באמצעות פסיק.
  
  שימו לב לנקודות הבאות:
  - תוחמים את הערך כולו במירכאות בודדות.
  - אסור להשתמש ברווחים, חוץ מאשר בין כתובת IP לשם מארח.
    
    ברשימה של כתובות ה-IP:
  - אפשר לציין כתובת IP ספציפית או בלוק של כתובות IP בפורמט CIDR.
  - צריך להפריד בין כל כתובת IP או בלוק CIDR באמצעות נקודה-פסיק.
  - לכתובת IP ספציפית, אפשר לציין שם מארח אחרי כתובת ה-IP. מפרידים בין כתובת ה-IP לשם המארח באמצעות רווח.
  - אם מציינים בלוק CIDR, לא מציינים ערך לשם המארח.
    
    לדוגמה:
    --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
- אופציונלי: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: רשימה מופרדת בפסיקים של דומיינים לחיפוש DNS שהמארחים יכולים להשתמש בהם. הדומיינים האלה משמשים כחלק מרשימת חיפוש של דומיינים.
  
  לדוגמה:
```
--dns-search-domains example.com,examplepetstore.com
```
רשימה מלאה של הדגלים והתיאורים שלהם מופיעה במדריך העזר ל-CLI של gcloud.

דגלי vSphere

אם צריך, מציינים את הדגלים האופציונליים הבאים:
‫--disable-aag-config: אם לא כוללים את הדגל הזה, כללי ה-anti-affinity של VMware Distributed Resource Scheduler (DRS) נוצרים באופן אוטומטי לצמתים של אשכול המשתמש, וכתוצאה מכך הם מתפרסים על פני לפחות 3 מארחים פיזיים במרכז הנתונים. חשוב לוודא שסביבת vSphere עומדת בדרישות. אם האשכול לא עומד בדרישות, צריך לכלול את הדגל הזה.

הערה: אם פעלתם לפי ההוראות במאמר הגדרת תשתית מינימלית, יש לכם רק מארח ESXi אחד, ולכן חשוב לכלול את הדגל הזה.
‫--disable-vsphere-csi: אם לא כוללים את הדגל הזה, הרכיבים של ממשק אחסון קונטיינרים (CSI) של vSphere נפרסים באשכול המשתמש. מנהל התקן ה-CSI פועל באשכול Kubernetes מקורי שנפרס ב-vSphere כדי להקצות נפחי אחסון מתמידים באחסון של vSphere. מידע נוסף זמין במאמר שימוש במנהל ההתקן של ממשק האחסון של מאגר vSphere. אם אתם לא רוצים לפרוס את רכיבי ה-CSI, הוסיפו את הדגל הזה.

רשימה מלאה של הדגלים והתיאורים שלהם מופיעה במאמרי העזרה של ה-CLI של 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 vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
למידע נוסף, ראו gcloud container vmware operations.

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

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

אחרי שיוצרים את האשכול, צריך ליצור לפחות מאגר צמתים אחד לפני פריסת עומסי העבודה.
```
gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer
```
מחליפים את מה שכתוב בשדות הבאים:
‫NODE_POOL_NAME: שם לבחירתכם למאגר הצמתים. השם צריך:
- לכלול עד 40 תווים
- להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
- להתחיל באות
- להסתיים בתו אלפאנומרי
‫USER_CLUSTER_NAME: השם של אשכול המשתמש החדש שנוצר.
‫FLEET_HOST_PROJECT_ID: מזהה הפרויקט שהאשכול רשום בו.
‫REGION: האזור ( Google Cloud ) שציינתם כשיצרתם את האשכול.
‫IMAGE_TYPE: סוג קובץ האימג' של מערכת ההפעלה שיופעל במכונות הווירטואליות במאגר הצמתים. צריך להגדיר אחת מהאפשרויות הבאות: ubuntu_cgv2 או cos_cgv2.
‫BOOT_DISK_SIZE: הגודל של דיסק האתחול בגיביבייט (GiB) לכל צומת במאגר. המינימום הוא 40GiB.
‫vCPUs: מספר ה-vCPU לכל צומת במאגר הצמתים. המספר המינימלי הוא 4.
‫MEMORY: גודל הזיכרון במגה-בייטים (MiB) לכל צומת במאגר. המינימום הוא 8,192MiB לכל צומת עובד באשכול המשתמש, והערך חייב להיות כפולה של 4.
‫NODES: מספר הצמתים במאגר הצמתים. המינימום הוא 3.
אם אתם משתמשים ב-MetalLB כמאזן העומסים, אתם יכולים לכלול את --enable-load-balancer כדי לאפשר ל-MetalLB speaker לפעול בצמתים במאגר. צריך להפעיל את MetalLB במאגר צמתים אחד לפחות. אם לא כוללים את הדגל הזה, צריך ליצור מאגר צמתים אחר לשימוש ב-MetalLB.

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

דוגמאות לפקודות gcloud

‫MetalLB ו-DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

‫MetalLB וכתובות IP סטטיות

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

איזון עומסים ידני וכתובות IP סטטיות

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

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

מאתרים את השם ואת מיקום החברות ב-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 כשיוצרים את האשכול.
כדי לקבל רשימה של הגרסאות הזמינות:
```
gcloud container vmware 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:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
הפקודה גם מציגה הסבר על הגרסאות שבהן אפשר להשתמש כדי ליצור או לשדרג אשכולות של משתמשים. הגרסאות המותרות מסומנות ב-isInstalled: true, כלומר לאשכול האדמין יש את הרכיבים הספציפיים לגרסה שהוא צריך כדי לנהל את אשכולות המשתמשים של אותה גרסה. אם אתם רוצים להשתמש בגרסה שמותקנת באשכול האדמין, דלגו לקטע דוגמה כדי ליצור את אשכול המשתמש.

התקנת גרסה אחרת

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

מחליפים את VERSION באחת מהגרסאות שמופיעות בפלט של הפקודה query-version-config.

אם מריצים מחדש את gcloud container vmware clusters query-version-config, הגרסה שציינתם מסומנת ב-isInstalled: true.

דוגמה

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

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

כדי לקבל מידע נוסף על הדוגמה, לוחצים על הקישור הבא:

‫`main.tf` ליצירת אשכול משתמשים

הדוגמה main.tf מכילה את המודולים והמשאבים הבאים:

‫enable_google_apis_primary: מפעיל את ממשקי ה-API הנדרשים של Google בפרויקט. צריך להפעיל את ממשקי ה-API בפרויקט רק פעם אחת. אם ממשקי ה-API כבר הופעלו בפרויקט, לא צריך לכלול את זה בקובץ התצורה של Terraform.
‫google_project_service: מפעיל את GKE On-Prem API בפרויקט. כמו בממשקי Google API האחרים שנדרשים, צריך להפעיל את GKE On-Prem API רק פעם אחת.
‫gcloud_update_admin_cluster_platform_controller: מעדכן את בקר הפלטפורמה באשכול האדמין. השלב הזה נדרש לשדרוג אשכולות של משתמשים. אם אשכול האדמין כבר בגרסה הנכונה, המודול הזה לא משנה שום דבר. המודול הזה אופציונלי, אבל אם יש חוסר התאמה בין הגרסה של בקר הפלטפורמה באשכול האדמין לבין הגרסה שציינתם לאשכול המשתמש, לא תוכלו ליצור את אשכול המשתמש.
‫google_gkeonprem_vmware_cluster: יוצר את אשכול המשתמש. חובה להשתמש במשאב הזה. אשכול המשתמשים רשום ב-GKE On-Prem API ובאותו צי כמו אשכול האדמין. בדוגמה הזו, האשכול נוצר באמצעות MetalLB המצורף. במאמרי העזרה של google_gkeonprem_vmware_cluster יש דוגמה להגדרה של מאזן עומסים ידני.
‫google_gkeonprem_vmware_node_pool: יוצר מאגר צמתים. המשאב הזה נדרש בקובץ התצורה של Terraform. באשכול משתמשים חדש שנוצר חייב להיות לפחות מאגר צמתים אחד כדי לעבור למצב תקין.

module "enable_google_apis_primary" {
  source     = "terraform-google-modules/project-factory/google//modules/project_services"
  version    = "~> 18.0"
  project_id = var.project_id
  activate_apis = [
    "cloudresourcemanager.googleapis.com",
    "anthos.googleapis.com",
    "anthosgke.googleapis.com",
    "container.googleapis.com",
    "gkeconnect.googleapis.com",
    "gkehub.googleapis.com",
    "serviceusage.googleapis.com",
    "stackdriver.googleapis.com",
    "monitoring.googleapis.com",
    "logging.googleapis.com",
    "iam.googleapis.com",
    "compute.googleapis.com",
    "anthosaudit.googleapis.com",
    "opsconfigmonitoring.googleapis.com",
    "file.googleapis.com",
    "connectgateway.googleapis.com"
  ]
  disable_services_on_destroy = false
}

# Enable GKE OnPrem API
resource "google_project_service" "default" {
  project            = var.project_id
  service            = "gkeonprem.googleapis.com"
  disable_on_destroy = false
}

# This module is used to update the platform controller on your admin cluster. This
# is a necessary step for the user cluster version update. If the admin cluster is
# already on the correct version, then this module does not change anything
module "gcloud_update_admin_cluster_platform_controller" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 3.0"
  platform              = "linux"
  create_cmd_entrypoint = "gcloud"
  create_cmd_body       = <<EOT
    beta container vmware admin-clusters               \
    update ${var.admin_cluster_name}                   \
    --required-platform-version=${var.on_prem_version} \
    --project ${var.project_id}                        \
    --location ${var.region}
  EOT
}

# Create an anthos vmware user cluster and enroll it with the gkeonprem API
resource "google_gkeonprem_vmware_cluster" "default" {
  name        = var.cluster_name
  description = "Anthos VMware user cluster with MetalLB"
  provider    = google-beta
  depends_on = [
    google_project_service.default,
    module.gcloud_update_admin_cluster_platform_controller
  ]
  location                 = var.region
  on_prem_version          = var.on_prem_version
  admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
  network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks     = ["192.168.0.0/16"]
    dhcp_ip_config {
      enabled = true
    }
  }
  control_plane_node {
    cpus     = var.control_plane_node_cpus
    memory   = var.control_plane_node_memory
    replicas = var.control_plane_node_replicas
  }
  load_balancer {
    vip_config {
      control_plane_vip = var.control_plane_vip
      ingress_vip       = var.ingress_vip
    }
    metal_lb_config {
      dynamic "address_pools" {
        for_each = var.lb_address_pools
        content {
          pool      = address_pools.value.name
          addresses = address_pools.value.addresses
        }
      }
    }
  }
  authorization {
    dynamic "admin_users" {
      for_each = var.admin_user_emails
      content {
        username = admin_users.value
      }
    }
  }
}

# Create a node pool for the anthos vmware user cluster
resource "google_gkeonprem_vmware_node_pool" "default" {
  name           = "${var.cluster_name}-nodepool"
  display_name   = "Nodepool for ${var.cluster_name}"
  provider       = google-beta
  vmware_cluster = google_gkeonprem_vmware_cluster.default.name
  location       = var.region
  config {
    replicas             = 3
    image_type           = "ubuntu_containerd"
    enable_load_balancer = true
  }
  depends_on = [
    google_gkeonprem_vmware_cluster.default
  ]
}

מידע נוסף ודוגמאות נוספות זמינים במאמרי העזרה של google_gkeonprem_vmware_cluster.

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

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

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

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

יוצרים עותק של הקובץ terraform.tfvars.sample:
```
cp terraform.tfvars.sample terraform.tfvars
```
משנים את ערכי הפרמטרים ב-terraform.tfvars.
```
project_id                  = "FLEET_HOST_PROJECT_ID"
region                      = "REGION"
admin_cluster_name          = "ADMIN_CLUSTER_NAME"
on_prem_version             = "VERSION"
admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name                = "avmw-user-cluster-metallb"
control_plane_node_cpus     = 4
control_plane_node_memory   = 8192
control_plane_node_replicas = 3
control_plane_vip           = "CONTROL_PLANE_VIP"
ingress_vip                 = "INGRESS_VIP"
lb_address_pools            = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]
```
ברשימה הבאה מתוארים המשתנים:
- ‫project_id: מזהה הפרויקט שבו רוצים ליצור את האשכול. הפרויקט שצוין משמש גם כפרויקט המארח של ה-fleet. זה צריך להיות אותו פרויקט שאליו רשום אשכול האדמין. אחרי שיוצרים את אשכול המשתמש, הוא נרשם באופן אוטומטי ל-fleet של הפרויקט שנבחר. אי אפשר לשנות את הפרויקט המארח של ה-fleet אחרי שיוצרים את האשכול.
- ‫region: האזור ב- Google Cloud שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). מציינים את us-west1 או אזור נתמך אחר.
- ‫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}"
```
  1. משנים את global לאזור שבו משתמש אשכול האדמין ושומרים את הקובץ.
- ‫on_prem_version: הגרסה של Google Distributed Cloud באשכול המשתמש.
- ‫admin_user_emails: רשימה של כתובות האימייל של המשתמשים שיקבלו הרשאות אדמין באשכול. אם אתם מתכוונים לנהל את האשכול, הקפידו להוסיף את כתובת האימייל שלכם.
  
  כשהאשכול נוצר, GKE On-Prem API מחיל על האשכול את כללי המדיניות של בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes, כדי להקצות למשתמשים עם הרשאת אדמין את התפקיד clusterrole/cluster-admin של Kubernetes, שנותן גישה מלאה לכל משאב באשכול בכל מרחבי השמות. כך המשתמשים יכולים גם להתחבר למסוף באמצעות Google Identity שלהם.
- ‫cluster_name: שם לבחירתכם לאשכול המשתמש. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
  - לכלול עד 40 תווים
  - להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
  - להתחיל באות
  - להסתיים בתו אלפאנומרי
- ‫control_plane_node_cpus: מספר ה-vCPUs לכל צומת במישור הבקרה באשכול המשתמש. המינימום הוא 4 מעבדי vCPU.
- ‫control_plane_node_memory: גודל הזיכרון במגה-בייטים (MiB) לכל מישור בקרה באשכול המשתמשים. הערך המינימלי הוא 8,192 והוא חייב להיות כפולה של 4.
- ‫control_plane_node_replicas: מספר הצמתים במישור הבקרה של אשכול המשתמש. לדוגמה, אתם יכולים להזין צומת אחד של מישור בקרה לסביבת פיתוח, ו-3 צמתים של מישור בקרה לסביבות ייצור עם זמינות גבוהה (HA).
- ‫control_plane_vip: כתובת ה-IP הווירטואלית (VIP) שבחרתם להגדיר במאזן העומסים לשרת ה-API של Kubernetes באשכול המשתמש.
- ‫ingress_vip: כתובת ה-IP שבחרתם להגדיר במאזן העומסים בשביל שרת ה-proxy של Ingress.
- ‫lb_address_pools: רשימה של מפות שמגדירות את מאגרי הכתובות שבהם ישתמש מאזן העומסים של MetalLB. כתובת ה-VIP של הכניסה חייבת להיות באחד מהמאגרים האלה. מציינים את הפרטים הבאים:
  - ‫name: שם למאגר.
  - ‫addresses: טווח כתובות בפורמט של CIDR או בפורמט של טווח עם מקפים. כדי לציין כתובת IP אחת במאגר (למשל, ל-VIP של תעבורת הנתונים הנכנסת), משתמשים ב-‎/32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
  מחליפים את כתובות ה-IP לדוגמה בערכים שלכם, ומוסיפים עוד מאגרי כתובות לפי הצורך.
שומרים את השינויים ב-terraform.tfvars. אם אתם לא רוצים לבצע שינויים אופציונליים ב-main.tf, דלגו לקטע הבא, יצירת האשכול ומאגר צמתים אחד.

הגדרת Controlplane V2

בגרסה 1.30 ואילך, צריך להפעיל את Controlplane V2. הקובץ main.tf בדוגמה לא מפעיל את Controlplane V2. כדי להפעיל את Controlplane V2, צריך לשנות את main.tf ולהוסיף את כתובות ה-IP של השער, מסכת הרשת והצמתים של מישור הבקרה. לפני שמבצעים שינויים, צריך ליצור גיבוי של main.tf:

  cp main.tf main.tf.bak

כדי להגדיר את Controlplane V2, מבצעים את השינויים הבאים ב-main.tf:

מוסיפים את השורה הבאה לבלוק resource:
```
  enable_control_plane_v2 = "true"
```

מוסיפים מפה של control_plane_v2_config לבלוק network_config, לדוגמה:

  control_plane_v2_config {
    control_plane_ip_block {
      netmask = "255.255.252.0"
      gateway = "10.250.71.254"
      ips {
        ip = "10.250.68.54"
        hostname = "cpv2-vm1"
      }
      ips {
        ip = "10.250.68.128"
        hostname = "cpv2-vm2"
      }
      ips {
        ip = "10.250.71.50"
        hostname = "cpv2-vm3"
      }
    }
  }

מחליפים את הערכים של netmask ו-gateway בכתובות IP מהרשת שלכם. מחליפים את ip ואת hostname בכתובות ה-IP של צומתי מישור הבקרה.

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

כברירת מחדל, בגרסה 1.32 ואילך, אשכולות משתמשים שנוצרו באמצעות Terraform לא כוללים אשכול מתקדם. כדי להפעיל אשכול מתקדם, מוסיפים את השדה הבא ברמה העליונה אל main.tf:

enable_advanced_cluster = true

אופציונלי: מצב כתובות ה-IP של צומת העובד

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

cp main.tf main.tf.bak

כברירת מחדל, main.tf מגדיר את האשכול כך שישתמש בשרת DHCP שאתם מספקים כדי להקצות כתובות IP לצומתי העובדים של האשכול. כדי להגדיר את DHCP, צריך לכלול את המפה dhcp_config בתוך הבלוק network_config. אם רוצים לספק כתובות IP סטטיות לצומתי העובדים, צריך לבצע את השינויים הבאים בקובץ main.tf:

מחליפים את הבלוק network_config וכוללים בלוק static_ip_config. לדוגמה:

  network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks = ["192.168.0.0/16"]
    host_config {
      dns_servers = ["10.254.41.1"]
      ntp_servers = ["216.239.35.8"]
    }
    static_ip_config {
      ip_blocks {
        netmask = "255.255.252.0"
        gateway = "10.251.31.254"
        ips {
          ip = "10.251.30.153"
          hostname = "vm-1"
        }
        ips {
          ip = "10.251.31.206"
          hostname = "vm-2"
        }
        ips {
          ip = "10.251.31.193"
          hostname = "vm-3"
        }
        ips {
          ip = "10.251.30.230"
          hostname = "vm-4"
        }
      }
    }
  }

מחליפים את הערכים הבאים בערכים שלכם:
- ‫service_address_cidr_blocks: טווח של כתובות IP בפורמט CIDR, שישמשו לשירותים באשכול. הטווח חייב להיות לפחות ‎/24.
- ‫pod_address_cidr_blocks: טווח של כתובות IP בפורמט CIDR, שישמשו לפודים באשכול. הטווח חייב להיות לפחות ‎/18.
- ‫dns_servers: רשימה של כתובות ה-IP של שרתי ה-DNS של המכונות הווירטואליות.
- ‫ntp_servers: רשימה של כתובות ה-IP של שרתי הזמן שהמכונות הווירטואליות יכולות להשתמש בהן.
- בבלוק static_ip_config, מחליפים את הערכים של netmask ו-gateway בכתובות של הרשת שלכם. מחליפים את ip ואת hostname בכתובות ה-IP ובשמות המארחים של צומתי העובדים.

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

מאתחלים ויוצרים את התוכנית ב-Terraform:
```
terraform init
```
‫Terraform מתקין את כל הספריות הנדרשות, כמו הספק Google Cloud .
בודקים את ההגדרות ומשנים אותן לפי הצורך:
```
terraform plan
```
מפעילים את התוכנית של Terraform כדי ליצור את אשכול המשתמש:
```
terraform apply
```
יצירת אשכול המשתמשים נמשכת כ-15 דקות או יותר, ויצירת מאגר הצמתים נמשכת עוד 15 דקות. אפשר לראות את אשכול GKE במסוף Google Cloud בדף GKE clusters.

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

במקרה הצורך, אפשר להריץ כלי שורת פקודה כמו ה-CLI של gcloud ו-gkectl כדי לבצע משימות הגדרה לפני שיוצרים את המשאבים. אתם מגדירים את שורות הפקודה להרצה בקובץ התצורה של Terraform באמצעות מנהל ההקצאות local-exec, שמאפשר לכם להשתמש שוב במשתני Terraform שהוגדרו.

בדוגמה הבאה אפשר לראות איך לשנות את main.tf כדי להריץ את הפקודה gkectl prepare לפני יצירת האשכול:

resource "null_resource" "gkectl_prepare" {
  provisioner "local-exec" {
    command = "gkectl prepare --kubeconfig=${var.kubeconfig} --cluster-name=${var.cluster_name} --vcenter-username=${var.vcenter_username} --vcenter-password=${var.vcenter_password} --vcenter-address=${var.vcenter_address} --datacenter=${var.datacenter} --datastore=${var.datastore} --network=${var.network} --os-image=${var.os_image} --service-account-key-file=${var.service_account_key_file} --location=${var.location}"
    working_dir = path.module  # Important: Set working directory
    environment = {
        # Optional: set environment variables if needed.
        # Example: GOOGLE_APPLICATION_CREDENTIALS = "/path/to/your/credentials.json"
    }
  }
}

resource "google_gkeonprem_vmware_cluster" "cluster" {
  # ... your cluster configuration ...
  # Ensure this depends on the null_resource
  depends_on = [null_resource.gkectl_prepare]

  # ... rest of your cluster configuration ...
  location = var.location
  name = var.cluster_name
  # ... other required fields ...
}

פתרון בעיות

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

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

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

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

gkectl

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

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

name

gkeOnPremVersion

enableAdvancedCluster

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

שימוש במרכז נתונים אחד ובאשכול vSphere אחד

שימוש באשכולות vSphere נפרדים

שימוש במרכזי נתונים נפרדים של vSphere

שימוש בחשבונות vCenter נפרדים

שימוש במכונות נפרדות של שרת vCenter

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

cloudAuditLogging

דוגמה לקובצי תצורה מלאים

user-ipblock.yaml

user-cluster.yaml

אימות קובץ התצורה

(אופציונלי) ייבוא קובצי אימג' של מערכת ההפעלה ל-vSphere, והעברת קובצי אימג' של קונטיינרים ל-registry פרטי

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

איתור קובץ kubeconfig של אשכול המשתמשים

איך מוודאים שאשכול המשתמש פועל

המסוף

קדימה, מתחילים

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

מישור הבקרה

Networking

מאזן עומסים

כלול ב-MetalLB

F5 BIG-IP

גלילה ידנית

תכונות

מאגרי צמתים

‫CLI של gcloud

איסוף מידע

התקנת גרסה אחרת

דוגמאות

‫MetalLB ו-DHCP

‫MetalLB וכתובות IP סטטיות

איזון עומסים ידני וכתובות IP סטטיות

דגלים של מישור הבקרה

דגלי vSphere

מעקב אחרי ההתקדמות של יצירת האשכול

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

דוגמאות לפקודות gcloud

‫MetalLB ו-DHCP

‫MetalLB וכתובות IP סטטיות

איזון עומסים ידני וכתובות IP סטטיות

Terraform

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

התקנת גרסה אחרת

דוגמה

‫main.tf ליצירת אשכול משתמשים

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

הגדרת Controlplane V2

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

אופציונלי: מצב כתובות ה-IP של צומת העובד

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

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

פתרון בעיות

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

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

`name`

`gkeOnPremVersion`

`enableAdvancedCluster`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`cloudAuditLogging`

‫`main.tf` ליצירת אשכול משתמשים

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