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

ב-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 באמצעות גרסה 1.29 של gkectl. אין חשיבות לגרסאות התיקון. לדוגמה, אפשר להשתמש בגרסה gkectl 1.29.0-gke.1456 כדי ליצור אשכול עם גרסת תיקון גבוהה יותר, כמו 1.29.1000-gke.94.
- הגרסה המשנית gkectl לא יכולה להיות גבוהה ביותר משתי גרסאות משניות מגרסת האשכול. לדוגמה, אם יוצרים אשכול בגרסה 1.28, הגרסה של gkectl יכולה להיות 1.29 או 1.30. אבל אי אפשר להשתמש בגרסה gkectl 1.31 כי היא גבוהה בשלוש גרסאות משניות מהגרסה של האשכול.
במקרה הצורך, אפשר לעיין במאמר בנושא הורדה של gkectl כדי להוריד גרסה נתמכת של gkectl.
אם עדיין לא עשיתם זאת, הגדירו את Google Cloud המשאבים שלכם כמו שמתואר במסמכים הבאים:
במהלך ההגדרה של פרויקט המארח של צי הרכבים, חשוב לזכור את הכלי שבחרתם, כי אם בחרתם באחד מלקוחות GKE On-Prem API, יש ממשקי API נוספים שצריך להפעיל. רשימת ממשקי ה-API מופיעה במאמר בנושא הפעלת ממשקי API בפרויקט המארח של הצי.
לפני שיוצרים אשכול משתמשים, צריך שיהיה אשכול אדמינים לניהול אשכול המשתמשים. אם עדיין לא עשיתם את זה, אתם צריכים ליצור תחנת עבודה לאדמין ואשכול אדמין.
קובעים את הגרסה של אשכול המשתמשים שרוצים להתקין. כשיוצרים אשכול משתמשים, בדרך כלל מתקינים את הגרסה שתואמת לגרסה של אשכול האדמין. אם רוצים להתקין גרסה אחרת באשכול משתמשים, אפשר לעיין במאמר בנושא כללי גרסה.
אם אתם מתכננים להתקין את גרסה 1.30 או גרסה מתקדמת יותר, נדרש Controlplane V2. גם אם אתם מתקינים גרסה 1.29 או גרסה מוקדמת יותר, מומלץ להפעיל את Controlplane V2. כש-Controlplane V2 מופעל, מישור הבקרה של אשכול המשתמשים פועל בצומת אחד או יותר באשכול המשתמשים עצמו. אפשרות אחרת היא ליצור אשכול משתמשים שמשתמש ב-kubeception. במקרה של kubeception, מישור הבקרה של אשכול המשתמשים פועל על צומת אחד או יותר באשכול האדמין.
בודקים את מסמך התכנון של כתובות ה-IP ומוודאים שיש מספיק כתובות IP זמינות.
כדאי לעיין בסקירה הכללית על איזון עומסים ולשקול מחדש את ההחלטה לגבי סוג מאזן העומסים שבו רוצים להשתמש. אפשר להשתמש במאזן העומסים MetalLB שכלול בחבילה, או להגדיר באופן ידני מאזן עומסים לפי בחירתכם. כדי לבצע איזון עומסים ידני, צריך להגדיר את מאזן העומסים לפני שיוצרים את אשכול המשתמשים.
כדאי לחשוב כמה מאגרי צמתים אתם צריכים ואיזו מערכת הפעלה אתם רוצים להפעיל בכל אחד מהמאגרים.
כדאי לחשוב אם רוצים להשתמש באשכולות vSphere נפרדים לאשכול הניהול ולאשכולות המשתמשים, ואם רוצים להשתמש במרכזי נתונים נפרדים. כדאי גם לחשוב אם רוצים להשתמש במופעים נפרדים של vCenter Server.
בגרסה 1.29 ומעלה, בדיקות מקדימות בצד השרת מופעלות כברירת מחדל. בדיקות קדם-הפעלה בצד השרת דורשות כללי חומת אש נוספים. בקטע Firewall rules for admin clusters (כללי חומת אש לאשכולות אדמין), מחפשים את האפשרות Preflight checks (בדיקות לפני המראה) ומוודאים שכל כללי חומת האש הנדרשים מוגדרים.

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

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

בקטע הזה מוסבר איך ליצור אשכול משתמשים באמצעות 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.34.100-gke.93.

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

`name`

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

`gkeOnPremVersion`

השדה הזה כבר מלא בשבילכם. ההגדרה הזו מציינת את הגרסה של Google Distributed Cloud. לדוגמה, 1.34.100-gke.93.

`enableAdvancedCluster`

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

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

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

`enableControlplaneV2`

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

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

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

kubeception

אם מגדירים את השדה הזה ל-false, האשכול ישתמש ב-kubecetption. ב-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 Server

במצבים מסוימים, כדאי ליצור אשכול משתמשים שמשתמש במופע משלו של 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 לשירות הכניסה של אשכול המשתמשים. צריך לספק את משתמשי ה-VIP כערכים של loadBalancer.vips.controlPlaneVIP ושל loadBalancer.vips.ingressVIP.

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

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

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

`advancedNetworking`

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

`multipleNetworkInterfaces`

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

`storage`

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

`masterNode`

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

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

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

`nodePools`

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

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

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

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

`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.
האזור שמוגדר ב-stackdriver.clusterLocation צריך להיות זהה לאזור שמוגדר ב-cloudAuditLogging.clusterLocation וב-gkeConnect.location. Google Cloud בנוסף, אם gkeOnPremAPI.enabled הוא true, צריך להגדיר את אותו אזור ב-gkeOnPremAPI.location.

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

`gkeConnect`

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

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

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

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.34.100-gke.93
enableControlplaneV2: true
enableDataplaneV2: 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"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  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"
  enableVPC: false
  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 הם עבור הצמתים של מישור הבקרה והצמתים של ה-worker. הסיבה לכך היא שלצמתי העובדים יש כתובות IP סטטיות. אם צמתי ה-worker מקבלים את כתובות ה-IP שלהם משרת DHCP, שרתי ה-DNS וה-NTP האלה הם רק לצמתי מישור הבקרה.
כתובות ה-IP הסטטיות של שלושת הצמתים של מישור הבקרה מצוינות בקטע network.controlPlaneIPBlock של קובץ התצורה של אשכול המשתמשים. אין צורך בכתובת IP נוספת בבלוק הזה.
‫Controlplane V2 מופעל.
השדה masterNode.replicas מוגדר ל-3, ולכן לאשכול יהיה מישור בקרה עם זמינות גבוהה.
כתובת ה-VIP של מישור הבקרה וכתובת ה-VIP של הכניסה נמצאות באותו VLAN כמו צמתי העובדים וצמתי מישור הבקרה.
כתובות ה-VIP שמוקצות לשירותים מסוג LoadBalancer מצוינות בקטע loadBalancer.metalLB.addressPools של קובץ התצורה של אשכול המשתמשים. כתובות ה-IP הווירטואליות האלה נמצאות באותו 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 והעברה בדחיפה של תמונות של קונטיינרים למאגר פרטי

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

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

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

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

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

מישור הבקרה

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

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

Networking

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

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

מאזן עומסים

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

בוחרים את סוג מאזן העומסים מהרשימה.

כלול בחבילה עם 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 של תעבורת הנתונים הנכנסת (ingress), לוחצים על + הוספת טווח כתובות IP ומזינים טווח כתובות אחר.
  
  כתובות ה-IP בכל מאגר לא יכולות להיות חופפות, והן צריכות להיות באותה רשת משנה כמו צמתי האשכול.
4. בקטע הקצאת כתובות IP, בוחרים באחת מהאפשרויות הבאות:
  - אוטומטי: בוחרים באפשרות הזו אם רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP ממאגר הכתובות לשירותים מסוג LoadBalancer.
  - ידני: בוחרים באפשרות הזו אם רוצים להשתמש בכתובות ממאגר הכתובות כדי לציין כתובות לשירותים מסוג LoadBalancer באופן ידני.
5. אם רוצים שהבקר של MetalLB לא ישתמש בכתובות מהמאגר שמסתיימות ב-‎ .0 או ב-‎ .255, לוחצים על Avoid buggy IP addresses. כך נמנעת הבעיה של מכשירים צרכניים עם באגים שגורמים להם להפסיק בטעות את התעבורה שנשלחת לכתובות ה-IP המיוחדות האלה.
6. כשמסיימים, לוחצים על סיום.
במקרה הצורך, לוחצים על הוספת מאגר כתובות.
בקטע Virtual IPs, מזינים את הפרטים הבאים:
- כתובת IP וירטואלית של מישור הבקרה: כתובת ה-IP של היעד שבה יש להשתמש לתנועה שנשלחת אל שרת ה-API של Kubernetes של אשכול המשתמשים. שרת Kubernetes API של אשכול המשתמשים פועל בצומת באשכול האדמין. כתובת ה-IP הזו צריכה להיות באותו דומיין L2 כמו הצמתים של אשכול האדמין. אל תוסיפו את הכתובת הזו לקטע מאגרי כתובות.
- כתובת IP וירטואלית של Ingress: כתובת ה-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.
- כתובת IP וירטואלית של Ingress: כתובת ה-IP שצריך להגדיר במאזן העומסים עבור שרת ה-Proxy של Ingress.
בשדה כתובת, מזינים את הכתובת של מאזן העומסים F5 BIG-IP.
בשדה Partition, מזינים את השם של מחיצת BIG-IP שיצרתם עבור אשכול המשתמשים.
בשדה sNAT pool name, מזינים את השם של מאגר כתובות ה-SNAT, אם רלוונטי.
לוחצים על Continue.

גלילה ידנית

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

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

תכונות

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

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

מאגרי צמתים

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

בקטע ברירות מחדל של מאגר צמתים, מבצעים את הפעולות הבאות:
1. מזינים את השם של מאגר הצמתים או מאשרים את השם default-pool.
2. מזינים את מספר vCPUs לכל צומת במאגר (מינימום 4 לכל עובד באשכול משתמשים).
3. מזינים את גודל הזיכרון במביבייט (MiB) לכל צומת במאגר (מינימום 8,192MiB לכל צומת עובד באשכול משתמשים, והערך חייב להיות כפולה של 4).
4. בשדה Nodes, מזינים את מספר הצמתים במאגר (מינימום 3). אם הזנתם כתובות IP סטטיות עבור כתובות ה-IP של הצמתים בקטע רשת, ודאו שהזנתם מספיק כתובות IP כדי להתאים לצמתים של אשכול המשתמשים.
5. בוחרים את סוג תמונת מערכת ההפעלה: Ubuntu,‏ Ubuntu Containerd או COS.
6. מזינים את גודל דיסק האתחול בגיביבייט (GiB) (מינימום 40GiB).
7. אם אתם משתמשים ב-MetalLB כמאזן העומסים, צריך להפעיל את MetalLB במאגר צמתים אחד לפחות. משאירים את האפשרות Use this node pool for MetalLB load balancing מסומנת, או מוסיפים עוד מאגר צמתים לשימוש ב-MetalLB.
בקטע Node pool metadata (optional) (מטא-נתונים של מאגר צמתים (אופציונלי)), אם רוצים להוסיף תוויות של Kubernetes וtaints, מבצעים את הפעולות הבאות:
1. לוחצים על + הוספת תוויות Kubernetes. מזינים את המפתח ואת הערך של התווית. חוזרים לפי הצורך.
2. לוחצים על + הוספת כתם. מזינים את המפתח, הערך וההשפעה של ה-taint. חוזרים לפי הצורך.
לוחצים על אימות והשלמה כדי ליצור את אשכול המשתמשים. יצירת אשכול המשתמשים נמשכת 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 של הכניסה חייבת להיות באחד ממאגרי הכתובות. כדי לציין 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של צי כלי הרכב אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמשים. בדגל --admin-cluster-membership אפשר להשתמש בשם המלא של האשכול, שהוא בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, מריצים את הפקודה gcloud container fleet memberships list.
‫REGION: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הרכיבים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול
- הנתונים של רכיבי המערכת ב-Cloud Logging וב-Cloud Monitoring
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
השם, הפרויקט והמיקום של האשכול מזהים אותו באופן ייחודי ב- Google Cloud.

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

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

‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, לשימוש בשירותים באשכול. הטווח חייב להיות לפחות /24.
לדוגמה: --service-address-cidr-blocks=10.96.0.0/20
‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, לשימוש ב-Pods באשכול. הטווח חייב להיות לפחות /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 לא יקצה ל-Services כתובות IP שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירים צרכניים עם באגים שגורמים להם להפסיק בטעות את התעבורה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False.
- ‫manual-assign: אם לא רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, צריך להגדיר את הערך הזה ל-True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני אחת מהכתובות ממאגר הכתובות. אם לא מציינים ערך, manual-assign מוגדר לערך False.
- ברשימה של addresses: כל כתובת צריכה להיות טווח בסימון CIDR או בפורמט של טווח עם מקף. כדי לציין כתובת IP יחידה במאגר (למשל עבור כתובת ה-VIP של הכניסה), משתמשים ב-‎ /32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
שימו לב לנקודות הבאות:
- מקיפים את כל הערך במירכאות בודדות.
- אסור להשתמש ברווחים.
- מפרידים בין כל טווח כתובות IP באמצעות נקודה-ופסיק.
לדוגמה:
```
--metal-lb-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 של הכניסה חייבת להיות באחד ממאגרי הכתובות. כדי לציין 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של צי כלי הרכב אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמשים. בדגל --admin-cluster-membership אפשר להשתמש בשם המלא של האשכול, שהוא בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, מריצים את הפקודה gcloud container fleet memberships list.
‫REGION: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הרכיבים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול
- הנתונים של רכיבי המערכת ב-Cloud Logging וב-Cloud Monitoring
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
השם, הפרויקט והמיקום של האשכול מזהים אותו באופן ייחודי ב- Google Cloud.

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

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

‫SERVICE_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, לשימוש בשירותים באשכול. הטווח חייב להיות לפחות /24.
לדוגמה: --service-address-cidr-blocks=10.96.0.0/20
‫POD_CIDR_BLOCK: טווח של כתובות IP בפורמט CIDR, לשימוש ב-Pods באשכול. הטווח חייב להיות לפחות /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 לא יקצה ל-Services כתובות IP שמסתיימות ב-‎ .0 או ב-‎ .255. כך נמנעת הבעיה של מכשירים צרכניים עם באגים שגורמים להם להפסיק בטעות את התעבורה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False.
- ‫manual-assign: אם לא רוצים שבקר MetalLB יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, צריך להגדיר את הערך הזה ל-True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני אחת מהכתובות ממאגר הכתובות. אם לא מציינים ערך, manual-assign מוגדר לערך False.
- ברשימה של addresses: כל כתובת צריכה להיות טווח בסימון CIDR או בפורמט של טווח עם מקף. כדי לציין כתובת IP יחידה במאגר (למשל עבור כתובת ה-VIP של הכניסה), משתמשים ב-‎ /32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
שימו לב לנקודות הבאות:
- מקיפים את כל הערך במירכאות בודדות.
- אסור להשתמש ברווחים.
- מפרידים בין כל טווח כתובות IP באמצעות נקודה-ופסיק.
לדוגמה:
```
--metal-lb-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 בודדת או בלוק של כתובות IP בפורמט CIDR.
- מפרידים בין כל כתובת 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, כל אחד מהרכיבים הבאים נחשף על ידי שירות Kubernetes מסוג LoadBalancer: שרת Kubernetes API, פרוקסי של Ingress ושירות התוסף לצבירת יומנים. אתם יכולים לבחור ערכי nodePort משלכם בטווח 30000 עד 32767 עבור השירותים האלה. לפרוקסי של תעבורת נתונים נכנסת (ingress), בוחרים ערך 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 של הפרויקט שנבחר. אי אפשר לשנות את פרויקט המארח של צי כלי הרכב אחרי שיוצרים את האשכול.
‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין שמנהל את אשכול המשתמשים. בדגל --admin-cluster-membership אפשר להשתמש בשם המלא של האשכול, שהוא בפורמט הבא:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
לחלופין, אפשר להגדיר את --admin-cluster-membership לשם של אשכול האדמין, כמו בפקודה לדוגמה. כשמשתמשים רק בשם של אשכול האדמין, צריך להגדיר את מזהה הפרויקט של אשכול האדמין באמצעות --admin-cluster-membership-project ואת המיקום באמצעות --admin-cluster-membership-location. המיקום של אשכול האדמין הוא global או אזור Google Cloud . אם אתם צריכים למצוא את האזור, מריצים את הפקודה gcloud container fleet memberships list.
‫REGION: האזור שבו פועלים GKE On-Prem API‏ (gkeonprem.googleapis.com), שירות Fleet‏ (gkehub.googleapis.com) ושירות Connect‏ (gkeconnect.googleapis.com). Google Cloud מציינים us-west1 או אזור נתמך אחר. אי אפשר לשנות את האזור אחרי שיוצרים את האשכול. ההגדרה הזו מציינת את האזור שבו מאוחסנים הרכיבים הבאים:
- המטא-נתונים של אשכול המשתמשים שנדרשים ל-GKE On-Prem API כדי לנהל את מחזור החיים של האשכול
- הנתונים של רכיבי המערכת ב-Cloud Logging וב-Cloud Monitoring
- יומן הביקורת של האדמין שנוצר על ידי יומני הביקורת של Cloud
השם, הפרויקט והמיקום של האשכול מזהים אותו באופן ייחודי ב- Google Cloud.

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

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

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

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

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

לדוגמה: --ingress-vip=203.0.113.4
‫INGRESS_HTTP_NODE_PORT: ערך nodePort לתעבורת HTTP לשרת ה-proxy של ה-Ingress (כגון 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 בודדת או בלוק של כתובות IP בפורמט CIDR.
- מפרידים בין כל כתובת 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: מספר ליבות ה-vCPU (מינימום 4) לכל צומת של מישור הבקרה באשכול המשתמשים. אם לא מציינים ערך, ברירת המחדל היא 4 מעבדים וירטואליים.
‫--memory=MEMORY: גודל הזיכרון במביבייט (MiB) לכל מישור בקרה באשכול המשתמשים. הערך המינימלי הוא 8,192 והוא חייב להיות כפולה של 4. אם לא מציינים ערך, ברירת המחדל היא 8,192.
‫--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: אם לא כוללים את הדגל הזה, רכיבי vSphere Container Storage Interface ‏ (CSI) נפרסים באשכול המשתמש. מנהל התקן ה-CSI פועל באשכול Kubernetes מקורי שנפרס ב-vSphere כדי להקצות נפחי אחסון מתמיד באחסון vSphere. מידע נוסף זמין במאמר בנושא שימוש בדרייבר של vSphere Container Storage Interface. אם לא רוצים לפרוס את רכיבי ה-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 דקות או יותר. אפשר לראות את האשכול במסוף 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_containerd או cos.
‫BOOT_DISK_SIZE: גודל דיסק האתחול בגיביבייט (GiB) לכל צומת במאגר. הנפח המינימלי הוא 40GiB.
‫vCPUs: מספר ה-vCPU לכל צומת במאגר הצמתים. הערך המינימלי הוא 4.
‫MEMORY: גודל הזיכרון במביבייט (MiB) לכל צומת במאגר. הערך המינימלי הוא 8,192MiB לכל צומת עובד באשכול משתמשים, והערך חייב להיות כפולה של 4.
‫NODES: מספר הצמתים במאגר הצמתים. המספר המינימלי הוא 3.
אם אתם משתמשים ב-MetalLB כמאזן העומסים, אתם יכולים לכלול את --enable-load-balancer אם אתם רוצים לאפשר לרמקול MetalLB לפעול בצמתים במאגר. צריך להפעיל את 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.34.100-gke.93 \
    --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.34.100-gke.93 \
    --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.34.100-gke.93 \
    --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 אחרי שיוצרים את האשכול.
- ‫region: האזור שבו פועלים GKE On-Prem API ‏ (gkeonprem.googleapis.com), שירות Fleet ‏(gkehub.googleapis.com) ושירות Connect ‏(gkeconnect.googleapis.com). Google Cloud מציינים 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.
- ‫cluster_name: שם לבחירתכם לאשכול המשתמשים. אי אפשר לשנות את השם אחרי שיוצרים את האשכול. השם צריך:
  - לכלול עד 40 תווים
  - להכיל רק תווים אלפאנומריים באותיות קטנות או מקף (-)
  - להתחיל בתו אלפביתי
  - להסתיים בתו אלפאנומרי
- ‫control_plane_node_cpus: מספר ה-vCPU לכל צומת של מישור הבקרה באשכול המשתמשים. המינימום הוא 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 של התעבורה הנכנסת.
- ‫lb_address_pools: רשימה של מיפויים שמגדירים את מאגרי הכתובות שבהם ישתמש מאזן העומסים MetalLB. כתובת ה-VIP של הכניסה חייבת להיות באחת מהמאגרים האלה. צריך לציין את הפרטים הבאים:
  - name: שם המאגר.
  - ‫addresses: טווח כתובות בסימון CIDR או בפורמט של טווח עם מקף. כדי לציין כתובת IP יחידה במאגר (למשל עבור כתובת ה-VIP של ה-Ingress), משתמשים ב-‎ /32 בסימון CIDR, לדוגמה: 192.0.2.1/32.
  מחליפים את כתובות ה-IP לדוגמה בערכים שלכם, ומוסיפים מאגרי כתובות נוספים אם צריך.
שומרים את השינויים ב-terraform.tfvars. אם לא רוצים לבצע שינויים אופציונליים ב-main.tf, אפשר לדלג לקטע הבא, יצירת האשכול ומאגר הצמתים.

הגדרת Controlplane V2

בגרסה 1.30 ומעלה, צריך להפעיל את Controlplane V2. הקובץ main.tf בדוגמה לא מאפשר Controlplane V2. כדי להפעיל את Controlplane V2 ולהוסיף את כתובות ה-IP של השער, מסכת הרשת וצמתי מישור הבקרה, צריך לשנות את main.tf. לפני שמבצעים שינויים, צריך ליצור גיבוי של 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, לשימוש ב-Pods באשכול. הטווח חייב להיות לפחות /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 דקות. אפשר לראות את האשכול במסוף Google Cloud בדף GKE clusters.

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

אם צריך, אפשר להריץ כלי שורת פקודה כמו ה-CLI של gcloud ו-gkectl כדי לבצע משימות הגדרה או קביעת הגדרות לפני יצירת משאבים. מגדירים את שורות הפקודה להפעלה בקובץ התצורה של Terraform באמצעות local-exec provisioner, שמאפשר לכם לעשות שימוש חוזר במשתני 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 Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

cloudAuditLogging

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

user-ipblock.yaml

user-cluster.yaml

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

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

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

איתור קובץ ה-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`