כדי לשפר את יציבות עומסי העבודה, במצב Autopilot של Google Kubernetes Engine (GKE) מתבצע ניהול של ערכי בקשות למשאבי Pod, כמו CPU, זיכרון או אחסון זמני. בדף הזה מופיע המידע הבא, שבעזרתו תוכלו לתכנן עומסי עבודה יעילים, יציבים וחסכוניים:
- ערכי ברירת מחדל ש-Autopilot מחיל על Pods שלא צוינו בהם ערכים.
- ערכי המינימום והמקסימום שהטייס האוטומטי אוכף לגבי בקשות למשאבים.
- איך ערכי ברירת המחדל, המינימום והמקסימום משתנים בהתאם לחומרה שה-Pods מבקשים.
הדף הזה מיועד לאופרטורים ולמפתחים שמקצים ומגדירים משאבי ענן, ופורסים עומסי עבודה. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן ב Google Cloudתוכן זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.
מומלץ להכיר את ניהול המשאבים ב-Kubernetes.
סקירה כללית של בקשות למשאבים ב-Autopilot
ב-Autopilot נעשה שימוש בבקשות למשאבים שאתם מציינים בהגדרות של עומס העבודה כדי להגדיר את הצמתים שמריצים את עומסי העבודה. ב-Autopilot, בקשות המשאבים המינימליות והמקסימליות נאכפות על סמך מחלקת המחשוב או תצורת החומרה שבהן נעשה שימוש בעומסי העבודה. אם לא מציינים בקשות לחלק מהמאגדים, Autopilot מקצה ערכי ברירת מחדל כדי לאפשר למאגדים האלה לפעול בצורה תקינה.
כשפורסים עומס עבודה באשכול Autopilot, GKE מאמת את הגדרת עומס העבודה מול הערכים המינימליים והמקסימליים המותרים עבור סוג המחשוב או הגדרת החומרה שנבחרו (למשל מעבדי GPU). אם מספר הבקשות נמוך מהמינימום, טייס אוטומטי משנה אוטומטית את הגדרות העומס כדי שמספר הבקשות יהיה בטווח המותר. אם מספר הבקשות חורג מהמקסימום, Autopilot דוחה את עומס העבודה ומציג הודעת שגיאה.
הרשימה הבאה מסכמת את הקטגוריות של בקשות למשאבים:
- בקשות ברירת מחדל למשאבים: Autopilot מוסיף אותן אם לא מציינים בקשות משלכם לעומסי עבודה
- בקשות מינימליות ומקסימליות למשאבים: Autopilot מאמת את הבקשות שציינתם כדי לוודא שהן בתחום המגבלות האלה. אם הבקשות שלכם חורגות מהמגבלות, Autopilot משנה את הבקשות לעומס העבודה.
- הפרדה של עומסי עבודה ובקשות למשך זמן ממושך: ל-Autopilot יש ערכי ברירת מחדל שונים וערכים מינימליים שונים לעומסי עבודה שמופרדים זה מזה, או ל-Pods שמקבלים הגנה מורחבת מפני הוצאה משימוש שמתבצעת על ידי GKE.
- בקשות למשאבים עבור DaemonSets: ל-Autopilot יש ערכי ברירת מחדל, מינימום ומקסימום שונים עבור קונטיינרים ב-DaemonSets.
איך מבקשים משאבים
ב-Autopilot, אתם מבקשים משאבים במפרט ה-Pod. המשאבים המינימליים והמקסימליים שנתמכים שניתן לבקש משתנים בהתאם להגדרת החומרה של הצומת שבו פועלים ה-Pods. כדי ללמוד איך לבקש הגדרות חומרה ספציפיות, אפשר לעיין בדפים הבאים:
בקשות ברירת מחדל למשאבים
אם לא מציינים בקשות למשאבים עבור חלק מהקונטיינרים ב-Pod, Autopilot מחיל ערכי ברירת מחדל. ברירות המחדל האלה מתאימות לעומסי עבודה קטנים רבים.
בנוסף, Autopilot מחיל את בקשות ברירת המחדל הבאות למשאבים, ללא קשר לסוג המחשוב או להגדרת החומרה שנבחרו:
קונטיינרים ב-DaemonSets
- מעבד (CPU): 50 mCPU
- זיכרון: 100 MiB
- שטח אחסון זמני: 100 MiB
כל שאר הקונטיינרים
- שטח אחסון זמני: 1 GiB
מידע נוסף על מגבלות של אשכולות Autopilot זמין במאמר מכסות ומגבלות.
בקשות ברירת מחדל לסוגי מחשוב
ב-Autopilot מוחלים ערכי ברירת המחדל הבאים על משאבים שלא מוגדרים במפרט של ה-Pod עבור Pods שפועלים בסוגי מחשוב. אם מגדירים רק אחת מהבקשות ומשאירים את השנייה ריקה, מערכת GKE משתמשת ביחס בין CPU לזיכרון שמוגדר בקטע בקשות מינימליות ומקסימליות כדי להגדיר את הבקשה החסרה לערך שתואם ליחס.
| סוגי מכונות וירטואליות | משאב | בקשת ברירת מחדל |
|---|---|---|
| לשימוש כללי (ברירת מחדל) | CPU | 0.5 vCPU |
| זיכרון | 2 GiB | |
| Accelerator | לא נאכפות בקשות ברירת מחדל. | |
| מאוזן | CPU | 0.5 vCPU |
| זיכרון | 2 GiB | |
| ביצועים | לא נאכפות בקשות ברירת מחדל. | |
| סילומיות אופקית (scale out) | CPU | 0.5 vCPU |
| זיכרון | 2 GiB | |
בקשות מינימום ומקסימום למשאבים
המשאבים הכוללים שנדרשים להגדרת הפריסה צריכים להיות בטווח הערכים המינימליים והמקסימליים שנתמכים ב-Autopilot. התנאים הבאים חלים:
בקשה מינימלית לכל צומת: כשמשתמשים במודל החיוב מבוסס-Pod כדי להריץ עומסי עבודה במצב Autopilot באשכולות Standard, וסכום בקשות המשאבים של Pods שניתן לחייב בצומת מסוים נמוך מהבקשה המינימלית שחלה על Pod יחיד, מערכת GKE מוסיפה חיוב על הבקשה המינימלית הזו.
בגלל האופן שבו Autopilot משנה את בקשות המשאבים של ה-Pod, סכום בקשות ה-Pod שניתנות לחיוב בצומת כמעט תמיד עומד בדרישת המינימום הזו לכל צומת או עולה עליה.
בקשות לאחסון זמני:
אחסון זמני משתמש בדיסק האתחול של ה-VM, אלא אם הצמתים שלכם כוללים כונני SSD מקומיים שמצורפים אליהם.
חומרה לחישובים שכוללת כונני SSD מקומיים, כמו יחידות GPU מסוג A100 (80GB), יחידות GPU מסוג H100 (80GB) או סדרת המכונות Z3, תומכת בבקשה מקסימלית ששווה לגודל של כונן ה-SSD המקומי פחות תקורה של המערכת. מידע על התקורה של המערכת זמין במאמר אחסון זמני שמגובה על ידי כונני SSD מקומיים.
ב-GKE בגרסה 1.29.3-gke.1038000 ואילך, פודים מסוג Performance class ופודים של מאיצי חומרה תומכים בבקשת אחסון זמני מקסימלית של 56 TiB, אלא אם החומרה כוללת כונני SSD מקומיים.
בכל שאר ה-Pods של Autopilot, ללא קשר לגרסת GKE, בקשת האחסון הכוללת לזמן קצר בכל הקונטיינרים ב-Pod צריכה להיות בין 10 MiB ל-10 GiB, אלא אם צוין אחרת.
לנפחים גדולים יותר, מומלץ להשתמש בנפחים זמניים גנריים, שמספקים פונקציונליות וביצועים שווים לאחסון זמני, אבל עם גמישות רבה יותר כי אפשר להשתמש בהם עם כל אפשרות אחסון ב-GKE. לדוגמה, הגודל המקסימלי של נפח אחסון זמני כללי באמצעות
pd-balancedהוא 64 TiB.
לגבי פודים של DaemonSet, דרישות המינימום למשאבים הן:
- אשכולות שתומכים בהתפרצות: 1 mCPU לכל Pod, 2 MiB של זיכרון לכל Pod ו-10 MiB של אחסון זמני לכל קונטיינר ב-Pod.
- קלאסטרים שלא תומכים בהתפרצות: 10 mCPU לכל Pod, 10 MiB של זיכרון לכל Pod ו-10 MiB של אחסון זמני לכל קונטיינר ב-Pod.
כדי לבדוק אם האשכול שלכם תומך בשימוש בנפח אחסון זמני, אפשר לעיין במאמר בנושא זמינות של נפח אחסון זמני ב-GKE.
אם האשכול תומך ב-bursting, Autopilot לא אוכף תוספות של 0.25 vCPU לבקשות ה-CPU של ה-Pod. אם האשכול לא תומך בשימוש זמני במשאבים מעבר למכסה, מצב Autopilot מעגל את בקשות ה-CPU למספר הקרוב ביותר של ליבות CPU וירטואליות (vCPU) שמתחלק ב-0.25. כדי לבדוק אם האשכול תומך ב-Bursting, אפשר לעיין במאמר זמינות של Bursting ב-GKE.
יחס ה-CPU לזיכרון חייב להיות בטווח המותר לסוג המחשוב או להגדרת החומרה שנבחרו. אם יחס המעבד לזיכרון חורג מהטווח המותר, Autopilot מגדיל אוטומטית את המשאב הקטן יותר. לדוגמה, אם תבקשו 1 vCPU ו-16 GiB של זיכרון (יחס של 1:16) עבור Pods שפועלים במחלקה
Scale-Out, Autopilot יגדיל את בקשת ה-CPU ל-4 vCPUs, וישנה את היחס ל-1:4.
ערכי מינימום ומקסימום לסוגי מחשוב
בטבלה הבאה מפורט יחס הזיכרון ל-CPU המינימלי, המקסימלי והמותר לכל מחלקה של מחשוב שנתמכת ב-Autopilot:
| סוגי מכונות וירטואליות | יחס בין יחידת העיבוד המרכזית (CPU) לזיכרון (vCPU:GiB) | משאב | מינימום | מקסימום |
|---|---|---|---|---|
| לשימוש כללי (ברירת מחדל) | בין 1:1 ל-1:6.5 | CPU | הערך תלוי בשאלה אם האשכול תומך בהתפרצות (bursting), באופן הבא:
כדי לבדוק אם האשכול שלכם תומך בשימוש ב-Bursting, אפשר לעיין במאמר בנושא זמינות של Bursting ב-GKE. |
30 vCPU |
| זיכרון | הערך תלוי בשאלה אם האשכול תומך בהתפרצות (bursting), באופן הבא:
כדי לבדוק אם האשכול שלכם תומך בשימוש ב-Bursting, אפשר לעיין במאמר בנושא זמינות של Bursting ב-GKE. |
110 GiB | ||
| Accelerator | ערכי מינימום ומקסימום למאיצים | |||
| מאוזן | בין 1:1 ל-1:8 | CPU | 0.25 vCPU | 222 vCPU אם נבחרה האפשרות minimum CPU platform (פלטפורמת מעבד מינימלית):
|
| זיכרון | 0.5 GiB | 851 GiB אם נבחרה האפשרות minimum CPU platform (פלטפורמת מעבד מינימלית):
|
||
| ביצועים | לא רלוונטי | CPU | אין אכיפה של דרישות מינימליות |
|
| זיכרון | אין אכיפה של דרישות מינימליות |
|
||
| שטח אחסון זמני | אין אכיפה של דרישות מינימליות |
|
||
| סילומיות אופקית (scale out) | בדיוק 1:4 | CPU | 0.25 vCPU |
|
| זיכרון | 1 GiB |
|
||
כדי ללמוד איך לבקש מחלקות מחשוב ב-Pods של Autopilot, אפשר לעיין במאמר בחירת מחלקות מחשוב ל-Pods של Autopilot.
ערכי מינימום ומקסימום לשיפורי מהירות
GKE לא אוכף בקשות מינימליות של CPU, זיכרון או אחסון זמני עבור Pods שמשתמשים במאיצים. בטבלה הבאה מתוארים מספר הבקשות המקסימלי לכל אחד מהמשאבים האלה, על סמך מספר המאיצים וסוג המאיץ שבו אתם משתמשים.
אלא אם מצוין אחרת, נפח האחסון הזמני המקסימלי שנתמך הוא 56 TiB.
| סוג המאיץ | משאב | מקסימום |
|---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני |
|
|
NVIDIA H200 (141GB)nvidia-h200-141gb |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני |
|
|
NVIDIA H100 Mega (80GB)nvidia-h100-mega-80gb |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני |
|
|
NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני |
|
|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
CPU |
סכום בקשות המעבד של כל ה-DaemonSets שפועלים בצומת של GPU מסוג A100 לא יכול להיות גדול מ-2 vCPU. |
| זיכרון |
סכום בקשות הזיכרון של כל ה-DaemonSets שפועלים בצומת GPU מסוג A100 לא יכול לחרוג מ-14 GiB. |
|
NVIDIA A100 (80GB)nvidia-a100-80gb |
CPU |
סכום בקשות המעבד של כל ה-DaemonSets שפועלים בצומת GPU A100 (80GB) לא יכול לחרוג מ-2 vCPU. |
| זיכרון |
סכום בקשות הזיכרון של כל DaemonSets שפועלים בצומת GPU A100 (80GB) לא יכול לחרוג מ-14 GiB. |
|
| שטח אחסון זמני |
|
|
NVIDIA RTX PRO 6000nvidia-rtx-pro-6000 |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני |
|
|
NVIDIA L4nvidia-l4 |
CPU |
סכום בקשות המעבד של כל DaemonSets שפועלים בצומת L4 GPU לא יכול לחרוג מ-2 vCPU. |
| זיכרון |
סכום בקשות הזיכרון של כל ה-DaemonSets שפועלים בצומת L4 GPU לא יכול להיות גבוה מ-14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| זיכרון |
|
|
Ironwood (TPU7x) (תצוגה מקדימה)tpu7x |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני | 56 TiB | |
TPU v6e (תצוגה מקדימה)tpu-v6e-slice |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני | 56 TiB | |
TPU v5etpu-v5-lite-podslice |
CPU |
|
| זיכרון |
|
|
| שטח אחסון זמני | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPU |
| זיכרון | 448 GiB | |
| שטח אחסון זמני | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPU |
| זיכרון | 407 GiB | |
| שטח אחסון זמני | 56 TiB |
מידע על בקשת מעבדי GPU ב-Autopilot Pods זמין במאמר פריסת עומסי עבודה של GPU ב-Autopilot.
בקשות למשאבים להפרדה של עומסי עבודה ולמשך מורחב
ב-Autopilot אפשר לשנות את ההתנהגות של תזמון ופינוי ב-Kubernetes באמצעות שיטות כמו:
- כדי לוודא שחלק מה-Pods ימוקמו רק בצמתים ספציפיים, אפשר להשתמש בtaints and tolerations ובnode selectors. פרטים נוספים זמינים במאמר הגדרת הפרדה בין עומסי עבודה ב-GKE.
- כדי למנוע מיקומי Pods משותפים באותו צומת, משתמשים בPod anti-affinity. בקשות ברירת המחדל והבקשות המינימליות למשאבים עבור עומסי עבודה שמשתמשים בשיטות האלה כדי לשלוט בהתנהגות התזמון גבוהות יותר מאשר עבור עומסי עבודה שלא משתמשים בהן.
- אפשר להשתמש בהערה כדי להגן על ה-Pods מפני הוצאה (eviction) שנגרמת בגלל שדרוגים אוטומטיים של הצומת ואירועי הקטנה (scale-down) למשך עד שבעה ימים. פרטים נוספים זמינים במאמר בנושא הארכת זמן הריצה של Autopilot Pods.
אם הבקשות שציינתם נמוכות מהערכים המינימליים, ההתנהגות של הטייס האוטומטי משתנה בהתאם לשיטה שבה השתמשתם, באופן הבא:
- Taints, tolerations, selectors, and extended duration Pods: Autopilot modifies your Pods to increase the requests when scheduling the Pods.
- Pod anti-affinity: Autopilot rejects the Pod and displays an error message.
בטבלה הבאה מתוארות בקשות ברירת המחדל ובקשות המינימום למשאבים שאפשר לציין. אם הגדרה או מחלקת מחשוב לא מופיעות בטבלה הזו, Autopilot לא אוכף ערכי מינימום או ערכי ברירת מחדל מיוחדים.
| סוגי מכונות וירטואליות | משאב | ברירת מחדל | מינימום |
|---|---|---|---|
| לשימוש כללי | CPU | 0.5 vCPU | 0.5 vCPU |
| זיכרון | 2 GiB | 0.5 GiB | |
| מאוזן | CPU | 2 vCPU | 1 vCPU |
| זיכרון | 8 GiB | 4 GiB | |
| סילומיות אופקית (scale out) | CPU | 0.5 vCPU | 0.5 vCPU |
| זיכרון | 2 GiB | 2 GiB |
מאגרי תגים של Init
Init
containers
פועלים ברצף, וכל init containers חייבים לסיים את הפעולה לפני ש-application
containers יכולים להתחיל. באשכולות במצב Autopilot, אם לא מציינים בקשות ל-CPU או לזיכרון עבור מאגרי init או אם לא מגדירים בקשות באופן מפורש ל-0, Autopilot משנה את ה-Pods במהלך היצירה כדי להוסיף בקשות למשאבים לכל מאגר init. הבקשות שמוקצות לכל מאגר init שוות לסכום הבקשות של כל מאגרי האפליקציות ב-Pod. זו התנהגות ברירת המחדל.
ההתנהגות הזו שונה מאשכולות רגילים, שבהם קונטיינרים של init משתמשים בכל המשאבים שלא הוקצו שזמינים בצומת שבו מתוזמן ה-Pod.
הקצאת משאבים אוטומטית למאגרי init
הקצאת המשאבים האוטומטית לקונטיינרים של init מתרחשת בזמן יצירת ה-Pod. מומלץ לא לציין באופן ידני בקשות למשאבים עבור קובצי init container באשכולות Autopilot, כדי שכל קובץ container יקבל כברירת מחדל את כל המשאבים שזמינים ל-Pod.
אם משנים את בקשות המשאבים של קונטיינרים שאינם קונטיינרים של init ב-Pod אחרי היצירה, Autopilot לא משנה אוטומטית את בקשות המשאבים של קונטיינרים של init. כתוצאה מכך, יכול להיות שתבחינו בחיובים שלא תואמים לשימוש בפועל במשאבים של ה-Pod. החיוב מבוסס על בקשת המשאבים האפקטיבית של ה-Pod, שהיא הגדולה מבין האפשרויות הבאות:
- בקשת המשאבים הגדולה ביותר של כל קונטיינר init ב-Pod.
- סכום הבקשות לכל מאגרי האפליקציות ב-Pod.
מידע נוסף זמין במאמר בנושא ניהול אוטומטי של משאבים ב-Autopilot.
הקצאת משאבים ידנית למאגרי init
אם אתם צריכים לשנות את בקשות המשאבים הקיימות עבור מאגרי האפליקציות כדי לנהל את העלויות והמשאבים, מומלץ לבצע אחת מהפעולות הבאות כדי לשנות את בקשות מאגרי האתחול:
- מעדכנים ידנית את בקשות המשאבים של קובץ האתחול כך שיתאימו לבקשות הכוללות החדשות ב-Pod. כשמציינים את בקשות המשאבים באופן ידני, חשוב להביא בחשבון את הנקודות הבאות:
- בקשות שקטנות מהמשאבים הכוללים של ה-Pod יכולות להגביל את קונטיינר האתחול.
- בקשות שגבוהות מהמשאבים הכוללים של ה-Pod עלולות להגדיל את העלויות.
- מסירים את בקשות המשאבים כדי לאפשר ל-Autopilot לחשב אותן מחדש. כברירת מחדל, במצב Autopilot, המערכת תקצה מחדש את המשאבים לכל קונטיינר init על סמך סך המשאבים הנוכחיים שנדרשים על ידי כל קונטיינרי האפליקציה ב-Pod.
הגדרת מגבלות משאבים ב-Autopilot
ב-Kubernetes אפשר להגדיר גם requests וגם limits למשאבים במפרט ה-Pod. ההתנהגות של ה-Pods משתנה בהתאם לכך שlimits שונים מrequests, כמו שמתואר בטבלה הבאה:
| ערכים שהוגדרו | אופן הפעולה של הטייס האוטומטי |
|---|---|
requests equal to limits |
ה-Pods משתמשים במחלקת ה-QoS Guaranteed.
|
requests set, limits not set |
ההתנהגות תלויה בשאלה אם האשכול תומך בשימוש זמני במשאבים מעבר למכסה, באופן הבא:
כדי לבדוק אם האשכול שלכם תומך בשימוש ב-Bursting, אפשר לעיין במאמר בנושא זמינות של Bursting ב-GKE. |
requests לא מוגדר, limits מוגדר |
ב-Autopilot, הערך של requests מוגדר לערך של limits, שזו התנהגות ברירת המחדל של Kubernetes.
לפני: resources:
limits:
cpu: "400m"אחרי: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests פחות מ-limits |
ההתנהגות תלויה בשאלה אם האשכול תומך בשימוש זמני במשאבים מעבר למכסה, באופן הבא:
כדי לבדוק אם האשכול שלכם תומך בשימוש ב-Bursting, אפשר לעיין במאמר בנושא זמינות של Bursting ב-GKE. |
requests greater than limits |
הטייס האוטומטי מגדיר את requests לערך של limits.
לפני: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"אחרי: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests not set, limits not set |
Autopilot מגדיר את ההתנהגות של
כדי לבדוק אם האשכול שלכם תומך בשימוש ב-Bursting, אפשר לעיין במאמר בנושא זמינות של Bursting ב-GKE. |
ברוב המקרים, כדאי להגדיר בקשות מספיקות למשאבים ומכסות שוות לעומסי העבודה.
עבור עומסי עבודה שזקוקים באופן זמני ליותר משאבים מאשר במצב יציב, כמו במהלך אתחול או בתקופות של נפח תנועה גבוה יותר, צריך להגדיר את המגבלות גבוה יותר מהבקשות כדי לאפשר ל-Pods להשתמש ביותר משאבים. פרטים נוספים זמינים במאמר הגדרת Pod bursting ב-GKE.
ניהול אוטומטי של משאבים ב-Autopilot
אם בקשות המשאבים שציינתם לעומסי העבודה חורגות מהטווחים המותרים, או אם לא ביקשתם משאבים לחלק מהקונטיינרים, מצב הטייס האוטומטי משנה את הגדרות עומס העבודה כדי לעמוד במגבלות המותרות. במצב אוטומטי, המערכת מחשבת את יחסי המשאבים ואת הדרישות להגדלת המשאבים אחרי שהיא מחילה ערכי ברירת מחדל על קונטיינרים שלא צוינה להם בקשה.
- בקשות חסרות: אם לא מבקשים משאבים בחלק מהקונטיינרים, Autopilot מחיל את בקשות ברירת המחדל עבור מחלקת המחשוב או תצורת החומרה.
- יחס בין CPU לזיכרון: מצב Autopilot מגדיל את המשאב הקטן יותר כדי שהיחס יהיה בטווח המותר.
- אחסון זמני: Autopilot משנה את הבקשות שלכם לאחסון זמני כדי לעמוד בכמות המינימלית שנדרשת לכל קונטיינר. הערך המצטבר של בקשות האחסון בכל כלי המכיל לא יכול להיות גדול מהערך המקסימלי המותר. לפני גרסה 1.28.6-gke.1317000, מצב Autopilot מצמצם את האחסון הזמני המבוקש אם הערך חורג מהערך המקסימלי. בגרסה 1.28.6-gke.1317000 ואילך, מצב Autopilot דוחה את עומס העבודה.
- בקשות מתחת למינימום: אם תבקשו פחות משאבים מהמינימום המותר להגדרת החומרה שנבחרה, Autopilot ישנה אוטומטית את ה-Pod כך שיבקש לפחות את ערך המשאב המינימלי.
כברירת מחדל, כש-Autopilot מגדיל באופן אוטומטי את המשאב כדי לעמוד בערך מינימלי או בערך ברירת מחדל של המשאב, GKE מקצה את הקיבולת הנוספת לקונטיינר הראשון במניפסט של ה-Pod. ב-GKE בגרסה 1.27.2-gke.2200 ואילך, אפשר להורות ל-GKE להקצות את המשאבים הנוספים לקונטיינר ספציפי על ידי הוספת הקוד הבא לשדה annotations במניפסט של ה-Pod:
autopilot.gke.io/primary-container: "CONTAINER_NAME"
מחליפים את CONTAINER_NAME בשם הקונטיינר.
דוגמאות לשינוי משאבים
בתרחיש הדוגמה הבא אפשר לראות איך Autopilot משנה את הגדרת עומס העבודה כדי לעמוד בדרישות של ה-Pods והקונטיינרים הפועלים.
קונטיינר יחיד עם פחות מ-0.05 vCPU
| מספר מאגר התגים | הבקשה המקורית | בקשה ששונתה |
|---|---|---|
| 1 |
מעבד: 30 mCPU זיכרון: 0.5 GiB שטח אחסון זמני: 10 MiB |
CPU: 50 mCPU Memory: 0.5 GiB Ephemeral storage: 10 MiB |
כמה מאגרי תגים עם סה"כ מעבד (CPU) < 0.05 vCPU
| מספר מאגר התגים | בקשות מקוריות | בקשות ששונו |
|---|---|---|
| 1 | מעבד: 10 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
CPU: 30 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
| 2 | מעבד: 10 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
מעבד: 10 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
| 3 | מעבד: 10 mvCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
מעבד: 10 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
| סך כל המשאבים של ה-Pod | CPU: 50 mCPU זיכרון: 1.5 GiB אחסון זמני: 30 MiB |
קונטיינר יחיד עם זיכרון נמוך מדי בשביל המעבד המבוקש
בדוגמה הזו, הזיכרון נמוך מדי ביחס לכמות המעבד (מינימום 1 vCPU:1 GiB). היחס המינימלי המותר בין מעבד לזיכרון הוא 1:1. אם היחס נמוך יותר, בקשת הזיכרון גדלה.
| מספר מאגר התגים | הבקשה המקורית | בקשה ששונתה |
|---|---|---|
| 1 | מעבד: 4 vCPU זיכרון: 1 GiB אחסון זמני: 10 MiB |
מעבד: 4 vCPU זיכרון: 4 GiB אחסון זמני: 10 MiB |
| סך כל המשאבים של ה-Pod | מעבד: 4 vCPU זיכרון: 4 GiB אחסון זמני: 10 MiB |
המאמרים הבאים
- איך מגדירים Pod bursting ב-GKE
- איך בוחרים מחלקות מחשוב עבור Autopilot Pods
- מידע נוסף על Balanced ו-Scale-Out ComputeClasses באשכולות של Autopilot
- מידע נוסף על מכסות ומגבלות
- איך משתמשים בדיסקים ייעודיים לאחסון מתמיד כנפחים זמניים