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

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

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

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

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

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

אלה השלבים העיקריים בתהליך ההגדרה:

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

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

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

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

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

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

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

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

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

  • הגדרת מארח ESXi:

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

  • הגדרת Datastore:

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

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

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

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

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

govc datastore.mkdir -namespace=true data-disks

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

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

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

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

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

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

דוגמה ל-VLAN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כתובות IP לפודים ולשירותים

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

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

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

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

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

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

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

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

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

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

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

באופן ספציפי, טווחי הכתובות של השירותים וה-Pods לא יכולים לחפוף לטווחים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת Google Cloud CLI

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

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

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

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

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

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

כדי להקצות את התפקידים:

‫Linux ו-macOS

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

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

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

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

Windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    gcloud iam service-accounts list \
    --project PROJECT_ID

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

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

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

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

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

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

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

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

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

    gcloud iam service-accounts list \
    --project PROJECT_ID

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

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

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

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

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

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

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

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

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

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

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

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

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

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