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

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

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

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

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

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

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

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

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

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

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

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) שמוגדרות כברירת מחדל, על סמך סוג המכונה.

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

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

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

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

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

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

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

    בנוסף, שמורים 100 MiB של זיכרון לערכי הסף של הוצאת Pod.

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

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

שמירת משאבי CPU

במאגרי צמתים שנוצרו ב-GKE בגרסה 1.37 ואילך, מערכת GKE מגבילה את ההזמנה הכוללת של CPU ל-vCPU אחד (1, 000 mCPU) או פחות עבור מופעי מחשוב רגילים ולא חלקיים. רכיבי המערכת עדיין יכולים לחרוג מהמגבלה הזו כשצריך. ההגבלה של ליבת vCPU אחת עוזרת לוודא שמופעי מחשוב עם מספר ליבות גבוה לא יאבדו ליבות רבות של קיבולת להקצאה בגלל הקצאות למערכת. המגבלה של ליבת 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% מהקיבולת: 150‎ GiB
  • ‫35% מהקיבולת + 6 GiB: ‏ 111 GiB
  • ‫‎100 GiB

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

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

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

אחסון זמני שמגובה על ידי כונני 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. כדאי להתחשב בדרישות המשאבים של עומסי העבודה בזמן הפריסה ובעומס. זה כולל את הבקשות והמגבלות המתוכננות של עומסי העבודה, וגם את התקורה שנדרשת כדי להתאים את המכסות להגדלה.

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

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

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

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

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

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

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