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

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

לא משנה מה ההגדרה של Google Distributed Cloud, הצמתים והאשכולות צריכים לכלול מספיק משאבי CPU,‏ RAM ואחסון כדי לענות על הצרכים של האשכולות ועומסי העבודה שאתם מריצים.

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

כשמתקינים את Google Distributed Cloud, אפשר ליצור סוגים שונים של אשכולות:

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

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

  • ברירת מחדל: לפרופיל ברירת המחדל יש דרישות סטנדרטיות של משאבי מערכת, ואפשר להשתמש בו לכל סוגי האשכולות.

  • ‫Edge: פרופיל ה-Edge הפחית באופן משמעותי את הדרישות של משאבי המערכת. מומלץ להשתמש בפרופיל הזה במכשירי קצה עם משאבים מוגבלים. אפשר להשתמש בפרופיל Edge רק עבור אשכולות עצמאיים.

דרישות משאבים לכל סוגי האשכולות באמצעות פרופיל ברירת המחדל

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

משאב מינימום מומלץ
מעבדים / מעבדי vCPU* ‫4 ליבות ‫8 ליבות
RAM ‫16 GiB ‫‎32 GiB
אחסון ‫‎128 GiB ‫256 GiB

‫* Google Distributed Cloud תומך רק במעבדי x86-64 ובמעבדי vCPU ברמת המיקרו-ארכיטקטורה של המעבד v3 ‏ (x86-64-v3) ומעלה.

דרישות משאבים לאשכולות עצמאיים באמצעות פרופיל Edge

בטבלה הבאה מפורטות דרישות החומרה המינימליות והמומלצות שנדרשות ל-Google Distributed Cloud כדי להפעיל ולנהל אשכולות עצמאיים באמצעות פרופיל Edge:

משאב מינימום מומלץ
מעבדים / מעבדי vCPU* 2 ליבות ‫4 ליבות
RAM ‫Ubuntu: ‏ ‎5 GiB

RHEL: ‏ ‎6 GiB

 ‫Ubuntu: ‏ ‎8 GiB

‫RHEL: ‏ ‎12 GiB
אחסון ‫‎128 GiB ‫256 GiB

‫* Google Distributed Cloud תומך רק במעבדי x86-64 ובמעבדי vCPU ברמת המיקרו-ארכיטקטורה של המעבד v3 ‏ (x86-64-v3) ומעלה.

כדי להגדיר אשכולות עצמאיים באמצעות פרופיל Edge, כדאי לפעול לפי השיטות המומלצות הבאות:

  • מריצים את bmctl בתחנת עבודה נפרדת. אם אתם חייבים להריץ את bmctl בצומת של אשכול היעד, תצטרכו 2 GiB של זיכרון כדי לעמוד בדרישות המינימום. לדוגמה, צריך 6 GiB בשביל Ubuntu ו-8 GiB בשביל RHEL.

  • מגדירים את MaxPodsPerNode ל-110. באשכול מופעלים בממוצע עד 30 פודים של משתמשים לכל צומת. יכול להיות שתצטרכו משאבים נוספים כדי להגדיר MaxPodsPerNode תצורה גבוהה יותר או להפעיל יותר מ-30 פודים של משתמשים לכל צומת.

  • רכיבי VM Runtime ב-GDC לא נכללים בהגדרת המשאבים המינימלית הזו. הזמן הריצה של מכונות וירטואליות ב-GDC דורש משאבים נוספים בהתאם למספר המכונות הווירטואליות שנפרסו באשכול.

דרישות נוספות בנוגע לנפח האחסון

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

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

מידע נוסף על הגדרת נפח האחסון הנדרש זמין במאמר הגדרת נפח האחסון ב-Google Distributed Cloud.

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

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

  • עמידה בדרישות המינימליות לחומרה.
  • מערכת ההפעלה היא אחת מהפצות Linux הנתמכות. מידע נוסף, כולל דרישות ליבה, זמין במאמר בחירת מערכת ההפעלה.
  • גישה לאינטרנט.
  • קישוריות ברמה 3 לכל שאר מכונות הצמתים.
  • גישה ל-VIP של מישור הבקרה.
  • גישה ליציאות הנדרשות. בקטע שימוש ביציאות בדף דרישות הרשת מפורטות דרישות ספציפיות לניוד של צמתים במישור הבקרה, צמתים של עובדים וצמתים של איזון עומסים.
  • שרתי שמות של DNS שהוגדרו בצורה נכונה.
  • אין שמות מארחים כפולים.
  • אחד משירותי ה-NTP הבאים מופעל ועובד:
    • chrony
    • ntp
    • ntpdate
    • systemd-timesyncd
  • מנהל חבילות עובד, כמו apt או dnf.
  • ב-Ubuntu, צריך להשבית את חומת האש הפשוטה (UFW). מריצים את הפקודה systemctl stop ufw כדי להשבית את UFW.

צריך לטעון את מודולי ליבת הרשת nf-tables או iptables. אם טענתם את iptables בצורה נכונה, הפלט הבא יוצג:

iptables --version
iptables vVERSION (nf_tables)
להסיר את הגרסה הקודמת ולהתקין מחדש את מודול הליבה המעודכן של iptables.
To load a module, run the following command:

```sh
modprobe MODULE_NAME
```

  • הדרישות לגבי מקום פנוי בכונן:

    ‫1.29.100 ואילך

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

    ספרייה נפח האחסון שנדרש
    / (תיקיית הבסיס) ‫4 GiB‏ (4,294,967,296 בייטים)
    /var/log/fluent-bit-buffers ‫12 GiB‏ (12,884,901,888 בייטים)
    /var/opt/buffered-metrics ‫10,016 MiB ‏ (10,502,537,216 בייטים)
    /var/lib/containerd
    • ‫30 GiB ‏ (32,212,254,720 בייטים) לצמתים של מישור הבקרה
    • ‫10 GiB ‏ (10,485,760 בייט) לצמתי עובד
    /var/lib/kubelet ‫500 MiB ‏ (524,288,000 בייטים)
    /var/lib/etcd ‫20 GiB (21,474,836,480 בייט, רלוונטי רק לצמתים של מישור הבקרה)
    /var/lib/etcd-events ‫5 GiB (5,368,709,120 בייט, רלוונטי רק לצמתים של מישור הבקרה)

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

    כשמשדרגים אשכול לגרסה 1.29.100 ואילך, בדיקות קדם-הפעלה מוודאות שיש לפחות 2 GiB של שטח פנוי ב-/ (תיקיית שורש).

    ‫1.29.0 וגרסאות קודמות

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

    ספרייה נפח האחסון שנדרש
    / (תיקיית הבסיס) ‫17 GiB‏ (18,253,611,008 בייט)
    /var/lib/containerd
    • ‫30 GiB ‏ (32,212,254,720 בייטים) לצמתים של מישור הבקרה
    • ‫10 GiB ‏ (10,485,760 בייט) לצמתי עובד
    /var/lib/kubelet ‫500 MiB ‏ (524,288,000 בייטים)
    /var/lib/etcd ‫20 GiB (21,474,836,480 בייט, רלוונטי רק לצמתים של מישור הבקרה)
    /var/lib/etcd-events ‫5 GiB (5,368,709,120 בייט, רלוונטי רק לצמתים של מישור הבקרה)

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

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

  • הספריות /var/lib/etcd ו-/etc/kubernetes לא קיימות או ריקות.

  • במכונות שמופעלות באמצעות RHEL 9.2 או Ubuntu 22.04, המגבלות של ליבת Linux‏ inotify לגבי מספר מקסימלי של מופעי משתמשים וצפיות משתמשים צריכות להיות גדולות או שוות לערכים הבאים:

    • fs.inotify.max_user_instances: 8192
    • fs.inotify.max_user_watches: 524288

    מידע נוסף זמין במסמכי התיעוד בנושא הגדרות של RHEL או Ubuntu.

בנוסף לדרישות המוקדמות להתקנה ולהפעלה של Google Distributed Cloud, הלקוחות נדרשים לעמוד בתקנים הרלוונטיים שחלים על התעשייה או על מגזר העסקים שלהם, כמו דרישות PCI DSS לעסקים שמבצעים עיבוד של כרטיסי אשראי או Security Technical Implementation Guides (מדריכים טכניים להטמעה של אבטחה, STIG) לעסקים בתעשיית הביטחון.

דרישות מוקדמות למכונות של מאזן עומסים

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

  • המכונות נמצאות באותה תת-רשת בשכבה 2.
  • כל כתובות ה-VIP נמצאות בתת-הרשת של צמתי מאזן העומסים, ואפשר להפנות אליהן תעבורה מהשער של תת-הרשת.
  • השער של רשת המשנה של מאזן העומסים צריך להאזין ל-ARP מיותרים כדי להעביר מנות למאזן העומסים הראשי.

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