בדף הזה מוסבר איך לתכנן את הגודל של הצמתים במאגרי צמתים רגילים של Google Kubernetes Engine (GKE) כדי לצמצם את הסיכון לשיבושים בעומסי העבודה ולסיום פעולה בגלל חוסר במשאבים.
אין צורך בתכנון הזה ב-GKE Autopilot כי Google Cloud מנהל את הצמתים בשבילכם. עם זאת, המאמר הזה עוזר למפעילים של אשכולות במצב Autopilot להבין כמה מקיבולת המשאבים בצומת זמינה לשימוש בעומסי העבודה שלהם.
היתרונות של צמתים בגודל הנכון
הקפדה על גודל נכון של הצמתים כדי להתאים לעומסי העבודה ולטפל בעליות פתאומיות בפעילות מספקת יתרונות כמו:
- אמינות טובה יותר של עומסי העבודה בגלל סיכון מופחת של פינוי בגלל חוסר במשאבים.
- שיפור יכולת ההתאמה של המערכת כדי להרחיב את עומסי העבודה בתקופות של תנועה גבוהה.
- העלויות נמוכות יותר כי הצמתים לא גדולים מדי ביחס לצרכים שלכם, מה שיכול להוביל לבזבוז משאבים.
משאבים שניתנים להקצאה לצומת
בצמתים של GKE מופעלים רכיבי מערכת שמאפשרים לצומת לתפקד כחלק מהאשכול. הרכיבים האלה משתמשים במשאבי הצומת, כמו מעבד (CPU) וזיכרון. יכול להיות שתבחינו בהבדל בין סך המשאבים של הצומת, שמבוססים על הגודל של המכונה הווירטואלית (VM) הבסיסית של 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) כברירת מחדל, על סמך סוג המכונה.
Google Cloudהזמנות זיכרון
למשאבי זיכרון, מערכת GKE שומרת את המשאבים הבאים:
- 255MiB של זיכרון למכונות עם פחות מ-1GiB של זיכרון
- 25% מנפח הזיכרון של 4 הגיביבייט הראשונים
- 20% מ-4 ה-GiB הבאים של הזיכרון (עד 8GB)
- 10% מ-8 ה-GiB הבאים של הזיכרון (עד 16GiB)
- 6% מ-112 הגיביבייט הבאים של הזיכרון (עד 128 גיביבייט)
- 2% מכל זיכרון מעל 128GiB
בנוסף, GKE שומר 100MiB של זיכרון בכל צומת כדי לטפל בהוצאה של Pod.
שמירת מעבד (CPU)
במשאבי CPU, GKE שומר את המשאבים הבאים:
- 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% מהקיבולת + 6GiB: 111GiB
- 100 GiB
מערכת GKE תשמור את המשאבים הבאים:
- הזמנת מערכת: 100 GiB (הערך הנמוך ביותר)
- סף לסילוק: 30GiB
נפח האחסון הכולל הזמני ששמור הוא 130GiB. הנפח שנותר, 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 |
שימוש בשמירת מקום למשאבים כדי לתכנן את גודלי הצמתים
כדאי להתחשב בדרישות המשאבים של עומסי העבודה בזמן הפריסה ובעומס. זה כולל את הבקשות והמגבלות המתוכננות לעומסי העבודה, וכן את התקורה שנדרשת כדי להתאים את המכסות להגדלה.
כדאי לשקול אם אתם רוצים מספר קטן של צמתים גדולים או מספר גדול של צמתים קטנים להרצת עומסי העבודה.
- מספר קטן של צמתים גדולים מתאים לעומסי עבודה (workloads) עתירי משאבים שלא דורשים זמינות גבוהה. התאמת גודל אוטומטית של צמתים היא פחות גמישה כי צריך להוציא יותר Podים כדי להקטין את גודל הצמתים.
- מספר גדול של צמתים קטנים מתאים לעומסי עבודה (workloads) עם זמינות גבוהה שלא דורשים הרבה משאבים. התאמה אוטומטית לעומס של צמתים היא גמישה יותר כי צריך להוציא פחות Pods כדי להקטין את גודל הקבוצה.
כדי לקבוע את סדרת המכונות ואת משפחת המכונות שרוצים להשתמש בהן בצמתים, אפשר להיעזר במדריך להשוואה בין משפחות של מכונות ב-Compute Engine.
כדאי לקחת בחשבון את דרישות האחסון הזמני של עומסי העבודה. האם דיסק האתחול של הצומת מספיק גדול? האם אתם צריכים כונני SSD מקומיים?
מחשבים את המשאבים שניתן להקצות בסוג המכונה שבחרתם באמצעות המידע שבקטעים הקודמים. משווים את זה למשאבים ולתקורה שאתם צריכים.
- אם סוג המכונה שבחרתם גדול מדי, כדאי לבחור מכונה קטנה יותר כדי להימנע מתשלום על משאבים נוספים.
- אם סוג המכונה שבחרתם קטן מדי, כדאי לבחור מכונה גדולה יותר כדי לצמצם את הסיכון לשיבושים בעומס העבודה.