מידע על גודל הצמתים ב-GKE

בדף הזה מוסבר איך לתכנן את הגודל של הצמתים במאגרי הצמתים הרגילים של Google Kubernetes Engine ‏ (GKE) כדי לצמצם את הסיכון לשיבושים בעומסי העבודה ולסיום פעולה בגלל חוסר במשאבים.

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

היתרונות של צמתים בגודל הנכון

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

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

משאבים שניתן להקצות לצומת

צומתי GKE מריצים רכיבי מערכת שמאפשרים לצומת לפעול כחלק מהאשכול. הרכיבים האלה משתמשים במשאבי הצומת, כמו מעבד (CPU) וזיכרון. יכול להיות שתבחינו בהבדל בין סך המשאבים של הצומת, שמבוסס על הגודל של מופע Compute Engine הבסיסי, לבין המשאבים שזמינים לעומסי העבודה של GKE כדי לבקש. ההבדל הזה נובע מכך ש-GKE שומר כמות מוגדרת מראש של משאבים לפונקציונליות של המערכת ולמהימנות הצומת. המקום בכונן ש-GKE מקצה למשאבי המערכת משתנה בהתאם לתמונת הצומת. המשאבים שנותרו וזמינים לעומסי העבודה נקראים משאבים שניתנים להקצאה.

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

בדיקת המשאבים שניתן להקצות בצומת

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

kubectl get node NODE_NAME \
    -o=yaml | grep -A 7 -B 7 capacity

מחליפים את NODE_NAME בשם הצומת.

הפלט אמור להיראות כך:

allocatable:
  attachable-volumes-gce-pd: "127"
  cpu: 3920m
  ephemeral-storage: "47060071478"
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 13498416Ki
  pods: "110"
capacity:
  attachable-volumes-gce-pd: "127"
  cpu: "4"
  ephemeral-storage: 98831908Ki
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 16393264Ki
  pods: "110"

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

הזמנת משאבים ב-GKE

‫GKE שומר כמויות מסוימות של זיכרון ומשאבי CPU בצמתים, בהתאם לגודל הכולל של המשאב שזמין בצומת. סוגי מכונות גדולים יותר מריצים יותר קונטיינרים ו-Pods, ולכן ככל שהמכונות גדולות יותר, כמות המשאבים ש-GKE שומרת גדלה. צמתים של Windows Server גם דורשים יותר משאבים מצמתים מקבילים של Linux, כדי להריץ את מערכת ההפעלה Windows ואת רכיבי Windows Server שלא יכולים לפעול בקונטיינרים.

הקצאות זיכרון ומעבד (CPU)

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

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

הזמנות של זיכרון

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

  • אם מאגר הצמתים נוצר בגרסה 1.37 של GKE או בגרסה חדשה יותר, GKE משתמש בנוסחה הבאה:

    MemoryReserved = Min(EarlierMemoryReservation, (15 MiB * MaxPodsPerNode) + BaseOverhead)

    ב-GKE משתמשים בערך הנמוך יותר מבין חישוב שמביא בחשבון את צפיפות ה-Pod, או EarlierMemoryReservation, שהוא חישוב ההקצאה למאגרי צמתים שנוצרו בגרסה 1.36 או בגרסה קודמת.

    בנוסחה הזו, הערך של BaseOverhead תלוי בהגדרות של הצומת, באופן הבא:

    • קובץ אימג' של צומת של מערכת הפעלה שמותאמת לקונטיינרים: 500 MiB
    • תמונת צומת של Ubuntu: 700 MiB
    • הפעלת סטרימינג של תמונות: מאגר נוסף, כפי שמתואר בהקצאת זיכרון לסטרימינג של תמונות.

    בנוסף, נשמרים 100 MiB של זיכרון בשביל סף הפינוי של ה-Pod.

  • אם מאגר הצמתים נוצר עם גרסה 1.36 או גרסה מוקדמת יותר של GKE, ‏ GKE משתמש בנוסחה הבאה. ‫GKE משתמש בנוסחה הזו גם אם מאגר הצמתים משודרג בהמשך לגרסה 1.37 ואילך:

    • ‫255MiB למכונות עם זיכרון של פחות מ-1GiB
    • ‫25% מנפח הזיכרון של 4 ה-GiB הראשונים
    • ‫20% מ-4GB הבאים של הזיכרון (עד 8GB)
    • ‫10% מ-8GiB הזיכרון הבאים (עד 16GiB)
    • ‫6% מ-112GiB הבאים של הזיכרון (עד 128GiB)
    • ‫2% מכל זיכרון גדול מ-128GiB
    • עוד 100 MiB של זיכרון לערכי סף של הוצאת Pod
    • אם הפעלתם את התכונה 'סטרימינג של תמונות', יוקצה מאגר נוסף, כמו שמתואר במאמר הקצאת זיכרון לסטרימינג של תמונות.

הקצאות של מעבדים (CPU)

במאגרי צמתים שנוצרו ב-GKE בגרסה 1.37 ואילך, מערכת GKE מגבילה את ההזמנה הכוללת של CPU ל-vCPU אחד (1, 000 mCPU) או פחות עבור מכונות וירטואליות רגילות ולא חלקיות. רכיבי המערכת עדיין יכולים לחרוג מהמגבלה הזו כשצריך. המגבלה של 1 vCPU עוזרת לוודא שמכונות Compute Engine עם הרבה ליבות לא יאבדו כמה ליבות של קיבולת שניתנת להקצאה לטובת שמירת מקום במערכת. המגבלה של ליבת CPU וירטואלית אחת לא חלה על מאגרי צמתים שנוצרו ב-GKE בגרסה 1.36 או בגרסאות קודמות. מערכת GKE מחשבת את ההזמנות של CPU לפי הנוסחה הבאה:

  • ‫6% מהליבה הראשונה
  • ‫1% מהליבה הבאה (עד 2 ליבות)
  • ‫0.5% מ-2 הליבות הבאות (עד 4 ליבות)
  • ‫0.25% מכל ליבה מעל 4 ליבות

בסוגי מכונות E2 עם ליבת מעבד משותפת, GKE עדיין מקצה סך של 1,060 מילי-ליבות.

הזמנת אחסון מקומי זמני

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

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

‫GKE מחשב את הקצאת האחסון המקומי הזמני באופן הבא:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

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

אחסון זמני שמגובה בדיסק אתחול של צומת

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

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

סף ההוצאה תמיד יהיה 10% מהקיבולת הכוללת של דיסק האתחול.

מערכת GKE קובעת את הערך של ההקצאה למערכת באופן הבא:

SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)

סכום ההזמנה במערכת הוא הסכום הנמוך ביותר מבין האפשרויות הבאות:

  • 50% מנפח דיסק האתחול
  • ‫35% מנפח דיסק האתחול + 6GiB
  • ‫‎100 GiB

לדוגמה, אם דיסק האתחול הוא 300GiB, הערכים הבאים חלים:

  • ‫50% מהקיבולת: 150GiB
  • ‫35% מהקיבולת + 6GiB: ‏ 111GiB
  • ‫‎100 GiB

מערכת GKE תשמור את המשאבים הבאים:

  • הקצאת המערכת: ‎100 GiB (הערך הנמוך ביותר)
  • סף הפינוי: 30GiB

נפח האחסון הכולל הזמני ששמור הוא 130GiB. הנפח שנותר, 170GiB, הוא נפח אחסון זמני שניתן להקצאה.

אחסון זמני שמגובה בכונני SSD מקומיים

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

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB

בחישוב הזה, SSD_NUMBER הוא מספר כונני ה-SSD המקומיים שמצורפים. כל כונני ה-SSD המקומיים הם בגודל 375GiB, כך שסף הפינוי הוא 10% מנפח האחסון הזמני הכולל. הערה: החישוב הזה מתבצע לפני פירמוט הכוננים, ולכן הנפח שניתן לשימוש נמוך בכמה אחוזים, בהתאם לגרסאות התמונה של הצומת.

מערכת GKE מחשבת את ההקצאה למערכת בהתאם למספר כונני ה-SSD המצורפים, באופן הבא:

מספר כונני ה-SSD המקומיים הזמנה במערכת (GiB)
1 ‫50 GiB
2 ‫‎75 GiB
‫3 או יותר ‫‎100 GiB

שימוש בהקצאת משאבים כדי לתכנן את גודל הצמתים

  1. כדאי להתחשב בדרישות המשאבים של עומסי העבודה בזמן הפריסה ובעומס. זה כולל את הבקשות והמגבלות המתוכננות לעומסי העבודה, וגם את התקורה כדי להתאים להרחבה אנכית בהתאם לעומס (scale up).

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

    • מספר קטן של צמתים גדולים מתאים לעומסי עבודה עתירי משאבים שלא דורשים זמינות גבוהה. התאמה אוטומטית לעומס של צמתים היא פחות גמישה כי צריך להוציא יותר Podים כדי שתתרחש הקטנה של הגודל.
    • מספר גדול של צמתים קטנים מתאים לעומסי עבודה (workloads) עם זמינות גבוהה שלא דורשים הרבה משאבים. התאמה אוטומטית לעומס של הצמתים היא גמישה יותר כי צריך לפנות פחות Pods כדי להקטין את הקיבולת.

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

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

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

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

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