כדי לשפר את היציבות של עומסי העבודה, במצב Autopilot של Google Kubernetes Engine (GKE) מנוהלים הערכים של בקשות המשאבים של Pod, כמו מעבד (CPU), זיכרון או אחסון זמני. בדף הזה מופיע המידע הבא, שבעזרתו תוכלו לתכנן עומסי עבודה יעילים, יציבים וחסכוניים:
- ערכי ברירת המחדל ש-Autopilot מחיל על פודים שלא צוינו בהם ערכים.
- ערכי המינימום והמקסימום ש-Autopilot אוכף לבקשות משאבים.
- איך ערכי ברירת המחדל, המינימום והמקסימום משתנים בהתאם לחומרה שה-Pods מבקשים.
הדף הזה מיועד למפעילים ולמפתחים שמקצים ומגדירים משאבים בענן ופורסים עומסי עבודה. במאמר תפקידים ומשימות נפוצים של משתמשי GKE מפורט מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן של Google Cloud.
אתם צריכים להכיר את ניהול המשאבים ב-Kubernetes.
סקירה כללית של בקשות למשאבים ב-Autopilot
במצב Autopilot, המערכת משתמשת בבקשות למשאבים שציינתם בהגדרות של עומס העבודה כדי להגדיר את הצמתים שמריצים את עומסי העבודה. ב-Autopilot נאכפות בקשות מינימליות ומקסימליות למשאבים, בהתאם למחלקת המחשוב או להגדרת החומרה שבהן משתמשים עומסי העבודה. אם לא תציינו בקשות לחלק מהקונטיינרים, מצב Autopilot יקצה ערכי ברירת מחדל כדי לאפשר לקונטיינרים האלה לפעול בצורה תקינה.
כשפורסים עומס עבודה באשכול Autopilot, GKE מאמת את הגדרות עומס העבודה מול ערכי המינימום והמקסימום המותרים לסוג המחשוב או להגדרות החומרה (כמו GPUs) שנבחרו. אם הבקשות שלכם קטנות מהמינימום, מצב Autopilot משנה באופן אוטומטי את הגדרת עומס העבודה כדי שהבקשות יהיו בטווח המותר. אם הבקשות שלכם חורגות מהמקסימום, Autopilot דוחה את עומס העבודה ומציגה הודעת שגיאה.
הרשימה הבאה מסכמת את הקטגוריות של בקשות למשאבים:
- בקשות ברירת מחדל למשאבים: בקשות שנוספות על ידי Autopilot אם לא מציינים בקשות משלכם לעומסי עבודה.
- בקשות מינימליות ומקסימליות למשאבים: Autopilot מאמת את הבקשות שציינתם כדי לוודא שהן עומדות במגבלות האלה. אם הבקשות שלכם חורגות מהמגבלות, Autopilot משנה את הבקשות של עומס העבודה.
- בקשות להפרדת עומסי עבודה ולהארכת משך הזמן: ב-Autopilot יש ערכי ברירת מחדל שונים וערכי מינימום שונים לעומסי עבודה שאתם מפרידים זה מזה, או לפודים שמקבלים הגנה מורחבת מפני פינוי ביוזמת GKE.
- בקשות למשאבים של DaemonSets: ב-Autopilot יש ערכי ברירת מחדל, ערכי מינימום וערכי מקסימום שונים לקונטיינרים ב-DaemonSets.
איך מבקשים משאבים
במצב Autopilot, אתם מבקשים משאבים במפרט ה-Pod. המשאבים המינימליים והמקסימליים הנתמכים שאפשר לבקש משתנים בהתאם להגדרת החומרה של הצומת שבו פועלים ה-Pods. כדי ללמוד איך לבקש הגדרות חומרה ספציפיות, אפשר לעיין בדפים הבאים:
בקשות ברירת מחדל למשאבים
אם לא תציינו בקשות למשאבים לחלק מהקונטיינרים ב-Pod, Autopilot יחיל ערכי ברירת מחדל. הגדרות ברירת המחדל האלה מתאימות להרבה עומסי עבודה קטנים יותר.
בנוסף, מצב Autopilot מחיל את בקשות ברירת המחדל הבאות למשאבים, בלי קשר למחלקת המחשוב או להגדרת החומרה שנבחרו:
קונטיינרים ב-DaemonSets
- מעבד (CPU): 50 mCPU
- זיכרון: 100 MiB
- אחסון זמני: 100 MiB
כל שאר המאגרים
- אחסון זמני: 1GiB
מידע נוסף על המגבלות של אשכולות Autopilot מופיע במאמר מכסות ומגבלות.
בקשות ברירת מחדל למחלקות מחשוב
ב-Autopilot, ערכי ברירת המחדל הבאים חלים על משאבים שלא מוגדרים במפרט ה-Pod של Pods שפועלים במחלקות מחשוב. אם מגדירים רק אחת מהבקשות ומשאירים את השנייה ריקה, GKE משתמש ביחס בין מעבד (CPU) לזיכרון שמוגדר בקטע בקשות מינימום ומקסימום כדי להגדיר את הבקשה החסרה לערך שתואם ליחס.
במצב Autopilot לא נאכפות בקשות ברירת מחדל לפודים של GPU ולפודים שמשתמשים ב-ComputeClass Performance.
| סוג המחשוב | משאב | בקשה שמוגדרת כברירת מחדל |
|---|---|---|
לשימוש כללי (ברירת המחדל autopilot או autopilot-arm) |
CPU | 0.5 vCPU |
| זיכרון | 2 GiB | |
| מאוזן | CPU | 0.5 vCPU |
| זיכרון | 2 GiB | |
| הרחבה אופקית (scale out) | CPU | 0.5 vCPU |
| זיכרון | 2 GiB |
בקשות מינימליות ומקסימליות למשאבים
סך המשאבים שביקשתם בהגדרות הפריסה צריך להיות בטווח הערכים המינימליים והמקסימליים שנתמכים ב-Autopilot. התנאים הבאים חלים:
בקשת מינימום לכל צומת: כשמשתמשים במודל החיוב שמבוסס על Pod כדי להריץ עומסי עבודה במצב Autopilot באשכולות Standard, וסכום בקשות המשאבים של Pod שניתן לחייב בצומת קטן מבקשת המינימום שתחול על Pod יחיד, GKE מוסיף חיוב על בקשת המינימום הזו.
בגלל האופן שבו Autopilot משנה את בקשות המשאבים של Pod, סכום בקשות ה-Pod הניתנות לחיוב בצומת כמעט תמיד עומד בבקשת המינימום הזו לכל צומת או חורג ממנה.
בקשות לאחסון זמני:
באחסון זמני נעשה שימוש בדיסק האתחול של המכונה הווירטואלית, אלא אם לצמתים מחוברים כונני SSD מקומיים.
חומרת מחשוב שכוללת כונני SSD מקומיים, כמו מעבדי GPU מסוג A100 (80GB), מעבדי GPU מסוג H100 (80GB), סדרת המכונות Z3 או סדרת המכונות Z4D, תומכת בבקשה מקסימלית ששווה לגודל של כונן ה-SSD המקומי פחות כל תקורה של המערכת. למידע נוסף על התקורה של המערכת, ראו אחסון זמני שמגובה על ידי כונני SSD מקומיים.
בגרסה 1.29.3-gke.1038000 של GKE ואילך, פודים מסוג Performance ופודים של שיפור מהירות באמצעות חומרה תומכים בבקשה לאחסון זמני בנפח של עד 56TiB, אלא אם החומרה כוללת כונני SSD מקומיים.
בכל שאר ה-Pods של Autopilot, בלי קשר לגרסת GKE, הבקשה הכוללת לאחסון זמני בכל הקונטיינרים ב-Pod צריכה להיות בין 10 MiB ל-10 GiB, אלא אם צוין אחרת.
לנפחים גדולים יותר, השתמשו בנפחים זמניים גנריים, שמספקים פונקציונליות וביצועים שווי ערך לאחסון זמני, אבל עם גמישות רבה יותר, כי אפשר להשתמש בהם עם כל אפשרות אחסון ב-GKE. לדוגמה, הגודל המקסימלי של נפח אחסון זמני גנרי באמצעות
pd-balancedהוא 64 TiB.
אלה בקשות המשאבים המינימליות לפודים של DaemonSet:
- אשכולות שתומכים בפרצי שימוש: 1 mCPU לכל Pod, 2 MiB של זיכרון לכל Pod ו-10 MiB של אחסון זמני לכל קונטיינר ב-Pod.
- אשכולות שלא תומכים ב-bursting: 10 mCPU לכל Pod, 10 MiB של זיכרון לכל Pod ו-10 MiB של אחסון זמני לכל קונטיינר ב-Pod.
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE.
אם האשכול תומך ב-bursting, Autopilot לא אוכף את המרווחים של 0.25 vCPU לבקשות ה-CPU של ה-Pod. אם האשכול לא תומך ב-bursting, מצב Autopilot מעגל את בקשות ה-CPU ל-0.25 vCPU הקרוב ביותר. כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE.
היחס בין המעבד (CPU) לזיכרון חייב להיות בטווח המותר לסוג המחשוב או להגדרת החומרה שנבחרו. אם היחס בין המעבד (CPU) לזיכרון חורג מהטווח המותר, Autopilot מגדיל אוטומטית את המשאב הקטן יותר. לדוגמה, אם מבקשים vCPU אחד ו-16 GiB של זיכרון (יחס של 1:16) לפודים שפועלים במחלקה
Scale-Out, Autopilot מגדיל את בקשת המעבד ל-4 vCPU, מה שמשנה את היחס ל-1:4.
ערכי מינימום ומקסימום לסוגי מחשוב
בטבלה הבאה מתוארים היחס המינימלי, המקסימלי והמותר בין המעבד (CPU) לזיכרון לכל סוג מחשוב שנתמך ב-Autopilot:
| סוג המחשוב | היחס בין המעבד (CPU) לזיכרון (vCPU:GiB) | משאב | מינימום | מקסימום |
|---|---|---|---|---|
לשימוש כללי (ברירת המחדל autopilot או autopilot-arm) |
בין 1:1 ל-1:6.5 | CPU | הערך תלוי בשאלה אם האשכול תומך ב-bursting, באופן הבא:
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE. |
30 vCPU |
| זיכרון | הערך תלוי בשאלה אם האשכול תומך ב-bursting, באופן הבא:
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE. |
110 GiB | ||
| מאוזן | בין 1:1 ל-1:8 | CPU | 0.25 vCPU | 222 vCPU אם נבחרה פלטפורמת CPU מינימלית:
|
| זיכרון | 0.5 GiB | 851 GiB אם נבחרה פלטפורמת CPU מינימלית:
|
||
| ביצועים | לא רלוונטי | CPU | אין דרישה למספר מינימלי של בקשות |
|
| זיכרון | אין דרישה למספר מינימלי של בקשות |
|
||
| אחסון זמני | אין דרישה למספר מינימלי של בקשות |
|
||
| הרחבה אופקית (scale out) | בדיוק 1:4 | CPU | 0.25 vCPU |
|
| זיכרון | 1 GiB |
|
במאמר בחירת מחלקות מחשוב לפודים של Autopilot מוסבר איך לבקש מחלקות מחשוב בפודים של 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 |
סך כל בקשות ה-CPU של כל ה-DaemonSets שפועלים בצומת GPU מסוג A100 לא יכול להיות יותר מ-2 vCPU. |
| זיכרון |
הסכום של בקשות הזיכרון של כל ה-DaemonSets שפועלים בצומת GPU מסוג A100 לא יכול להיות גדול מ-14GiB. |
|
thought
NVIDIA A100 (80GB)nvidia-a100-80gb |
CPU |
סך כל בקשות ה-CPU של כל ה-DaemonSets שפועלים בצומת GPU מסוג A100 (80GB) לא יכול לחרוג מ-2 vCPU. |
| זיכרון |
הסכום של בקשות הזיכרון של כל ה-DaemonSets שפועלים בצומת GPU מסוג A100 (80GB) לא יכול להיות יותר מ-14GiB. |
|
| אחסון זמני |
|
|
NVIDIA RTX PRO 6000nvidia-rtx-pro-6000
|
CPU |
|
| זיכרון |
|
|
| אחסון זמני |
|
|
NVIDIA L4nvidia-l4 |
CPU |
סך כל בקשות המעבד (CPU) של כל ה-DaemonSets שפועלים בצומת GPU מסוג L4 לא יכול לחרוג מ-2 vCPU. |
| זיכרון |
הסכום של בקשות הזיכרון של כל ה-DaemonSets שפועלים בצומת GPU מסוג L4 לא יכול להיות גדול מ-14GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| זיכרון |
|
|
Ironwood (TPU7x)tpu7x |
CPU |
|
| זיכרון |
|
|
| אחסון זמני | 56 TiB | |
TPU v6e (גרסת טרום-השקה (Preview))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 אוכף ערכים גבוהים יותר לבקשות ברירת המחדל ולבקשות המינימליות למשאבים:
- אתם משתמשים בכלל עדיפות של
podFamilyבכל ComputeClass בהתאמה אישית של Autopilot שהוא לא ברירת המחדל ברמת האשכול. - אתם פורסים עומסי עבודה שעומדים בשני הקריטריונים הבאים:
- משתמשים באחת מהגדרות המחשוב הבאות:
- פלטפורמת המחשוב שמותאמת לקונטיינרים כברירת מחדל באשכולות Autopilot.
- כל ComputeClass מובנה של Autopilot.
-
podFamilyכללי עדיפות ב-ComputeClass בהתאמה אישית של Autopilot, שמוגדר גם כברירת המחדל ברמת האשכול. - ComputeClasses מסוג
BalancedאוScale-Outבאשכולות Autopilot.
- לשנות את ההתנהגות של התזמון והפינוי ב-Kubernetes באחת מהדרכים הבאות:
- אתם משתמשים בהפרדת עומסי עבודה כדי לוודא ש-Pods מסוימים ימוקמו רק בצמתים ספציפיים.
- משתמשים בPod anti-affinity כדי למנוע מיקום משותף של Pods באותו צומת.
- אתם יכולים להשתמש בהערה כדי להאריך את זמן הריצה של פודים ב-Autopilot, וכך למנוע פינוי בגלל שדרוגים אוטומטיים של צמתים ואירועים של צמצום אנכית בהתאם לעומס (scale down) למשך עד שבעה ימים.
- משתמשים באחת מהגדרות המחשוב הבאות:
כברירת מחדל, אם בקשות המשאבים נמוכות מהערך המינימלי המותר, Autopilot מגדיל את בקשות המשאבים כדי לעמוד במינימום. החריג להתנהגות הזו הוא אי-קרבה של Pod, שבה Autopilot דוחה את ה-Pod עם הודעת שגיאה.
בטבלה הבאה מתוארות בקשות ברירת המחדל והבקשות המינימליות למשאבים שאפשר לציין בתרחישים האלה:
| הגדרות אישיות | ברירת מחדל | מינימום |
|---|---|---|
פודים שמשנים את התזמון או את התנהגות הפינוי ומשתמשים באחת מההגדרות הבאות:
|
|
|
פודים שמשתמשים בכללי podFamily ב-ComputeClasses בהתאמה אישית שהם לא ברירת המחדל |
|
|
פודים שמשנים את ההתנהגות של התזמון או הפינוי ומשתמשים ב-ComputeClass של Balanced באשכולות Autopilot |
|
|
פודים שמשנים את ההתנהגות של התזמון או הפינוי ומשתמשים ב-ComputeClass של Scale-Out באשכולות Autopilot |
|
|
קונטיינרים של Init
קונטיינרים של Init פועלים ברצף, וכולם חייבים לסיים לפעול לפני שקונטיינרים של אפליקציות יכולים להתחיל לפעול. באשכולות Autopilot, אם לא מציינים בקשות למעבד (CPU) או לזיכרון בשביל קונטיינרים של init, או אם מגדירים במפורש בקשות ל-0, Autopilot משנה את ה-Pods במהלך היצירה כדי להוסיף בקשות למשאבים לכל קונטיינר של init. הבקשות שמוקצות לכל קונטיינר init שוות לסכום הבקשות של כל קונטיינרי האפליקציות ב-Pod. זו פעולת ברירת המחדל.
ההתנהגות הזו שונה מאשכולות רגילים, שבהם קונטיינרים של init משתמשים בכל המשאבים שלא הוקצו וזמינים בצומת שבו מתוזמן ה-Pod.
הקצאת משאבים אוטומטית למאגרי init
הקצאת המשאבים האוטומטית לקונטיינרים של init מתרחשת בזמן יצירת ה-Pod. אנחנו ממליצים לא לציין באופן ידני בקשות למשאבים בשביל קונטיינרים של init באשכולות Autopilot, כדי שכל קונטיינר יקבל כברירת מחדל את כל המשאבים שזמינים ל-Pod.
אם משנים את בקשות המשאבים של קונטיינרים שאינם init ב-Pod אחרי היצירה, Autopilot לא משנה באופן אוטומטי את בקשות המשאבים של קונטיינרי ה-init. כתוצאה מכך, יכול להיות שתבחינו בחיובים שלא תואמים לשימוש בפועל במשאבים של ה-Pod. החיוב מבוסס על בקשת המשאבים בפועל של ה-Pod, שהיא הערך הגבוה מבין הבאים:
- בקשת המשאבים הגדולה ביותר של קונטיינר init יחיד ב-Pod.
- סכום הבקשות של כל קונטיינרי האפליקציות ב-Pod.
מידע נוסף זמין במאמר ניהול משאבים אוטומטי ב-Autopilot.
הקצאת משאבים ידנית לקונטיינרים של init
אם אתם צריכים לשנות את בקשות המשאבים הקיימות של קונטיינרים של אפליקציות כדי לנהל את העלויות והמשאבים, מומלץ לבצע אחת מהפעולות הבאות כדי לשנות את הבקשות של קונטיינר ה-init:
- מעדכנים ידנית את בקשות המשאבים של מאגר ה-init כך שיתאימו לבקשות החדשות הכוללות ב-Pod. כשמציינים באופן ידני את בקשות המשאבים, חשוב להביא בחשבון את הדברים הבאים:
- בקשות שקטנות מסך המשאבים של ה-Pod יכולות להגביל את מאגר ה-init.
- בקשות שגבוהות מסך המשאבים של ה-Pod יכולות להגדיל את העלויות.
- מסירים את בקשות המשאבים כדי לאפשר ל-Autopilot לחשב אותן מחדש. כברירת מחדל, Autopilot יקצה מחדש את המשאבים לכל קונטיינר init על סמך סך כל המשאבים שביקשו כל קונטיינרי האפליקציות ב-Pod.
הגדרת מגבלות על משאבים ב-Autopilot
ב-Kubernetes אפשר להגדיר גם requests וגם limits למשאבים במפרט של ה-Pod. ההתנהגות של ה-Pods משתנה בהתאם להבדלים בין limits לבין requests, כפי שמתואר בטבלה הבאה:
| הערכים שהוגדרו | התנהגות של Autopilot |
|---|---|
requests שווה ל-limits |
ה-Pods משתמשים במחלקת QoS מסוג Guaranteed.
|
requests מוגדר, limits לא מוגדר |
ההתנהגות תלויה בשאלה אם האשכול תומך ב-bursting, באופן הבא:
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE. |
requests לא מוגדר, limits מוגדר |
במצב Autopilot, הערך של requests מוגדר לערך של limits, שהוא התנהגות ברירת המחדל של Kubernetes.
לפני: resources:
limits:
cpu: "400m"אחרי: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests פחות מ-limits |
ההתנהגות תלויה בשאלה אם האשכול תומך ב-bursting, באופן הבא:
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE. |
requests גדול מ-limits |
מצב Autopilot מגדיר את requests לערך של limits.
לפני: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"אחרי: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests לא מוגדר, limits לא מוגדר |
במצב Autopilot, הערכים של ההתנהגות של
כדי לבדוק אם האשכול תומך ב-bursting, קראו את המאמר זמינות של bursting ב-GKE. |
ברוב המקרים, כדאי להגדיר בקשות משאבים מתאימות ומגבלות שוות לעומסי העבודה.
לעומסי עבודה שבאופן זמני דורשים יותר משאבים מאשר במצב היציב שלהם, כמו במהלך ההפעלה או בתקופות של תנועה גבוהה יותר, הגדירו את המגבלות גבוהות יותר מהבקשות כדי לאפשר ל-Pods להתפרץ. למידע נוסף, קראו את המאמר הגדרת התפרצות Pod ב-GKE.
ניהול משאבים אוטומטי ב-Autopilot
אם בקשות המשאבים שציינתם לעומסי העבודה שלכם חורגות מהטווחים המותרים, או אם לא ביקשתם משאבים לחלק מהקונטיינרים, Autopilot משנה את הגדרת עומס העבודה כך שתתאים למגבלות המותרות. במצב Autopilot, המערכת מחשבת את יחסי המשאבים ואת הדרישות להגדלת המשאבים אחרי שהיא מחילה ערכי ברירת מחדל על קונטיינרים שלא צוינה בהם בקשה.
- בקשות חסרות: אם לא תבקשו משאבים בקונטיינרים מסוימים, מצב Autopilot יחיל את בקשות ברירת המחדל על מחלקת המחשוב או על הגדרת החומרה.
- היחס בין המעבד (CPU) לזיכרון: במצב Autopilot, המשאב הקטן יותר מוגדל כדי שהיחס יהיה בטווח המותר.
- אחסון זמני: מצב Autopilot משנה את הבקשות לאחסון זמני כדי לעמוד בכמות המינימלית שנדרשת לכל קונטיינר. הערך המצטבר של בקשות האחסון בכל הקונטיינרים לא יכול להיות גדול מהערך המקסימלי המותר. בגרסאות שקדמו ל-1.28.6-gke.1317000, מצב Autopilot מצמצם אנכית בהתאם לעומס (scale down) את האחסון הארעי המבוקש אם הערך חורג מהמקסימום. בגרסה 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 משנה את הגדרת עומס העבודה כדי לעמוד בדרישות של ה-Pod והקונטיינרים שפועלים.
קונטיינר יחיד עם פחות מ-0.05 vCPU
| מספר המכולה | הבקשה המקורית | הבקשה שונתה |
|---|---|---|
| 1 |
מעבד (CPU): 30mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
מעבד: 50 mCPU זיכרון: 0.5 GiB אחסון זמני: 10 MiB |
כמה קונטיינרים עם מעבד (CPU) כולל של פחות מ-0.05 vCPU
| מספר המכולה | בקשות מקוריות | בקשות ששונו |
|---|---|---|
| 1 | מעבד (CPU): 10mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
מעבד (CPU): 30mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
| 2 | מעבד (CPU): 10mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
מעבד (CPU): 10mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
| 3 | מעבד (CPU): 10mvCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
מעבד (CPU): 10mCPU זיכרון: 0.5GiB אחסון זמני: 10MiB |
| סה"כ משאבי Pod | מעבד (CPU): 50mCPU זיכרון: 1.5GiB אחסון זמני: 30MiB |
קונטיינר יחיד עם זיכרון נמוך מדי למעבד (CPU) המבוקש
בדוגמה הזו, הזיכרון נמוך מדי לכמות המעבדים (מינימום 1 vCPU:1 GiB). היחס המינימלי המותר בין המעבד לזיכרון הוא 1:1. אם היחס נמוך יותר, בקשת הזיכרון גדלה.
| מספר המכולה | הבקשה המקורית | הבקשה שונתה |
|---|---|---|
| 1 | מעבד (CPU): 4 vCPU זיכרון: 1 GiB אחסון זמני: 10 MiB |
מעבד (CPU): 4vCPU זיכרון: 4GiB אחסון זמני: 10MiB |
| סה"כ משאבי Pod | מעבד (CPU): 4vCPU זיכרון: 4GiB אחסון זמני: 10MiB |
המאמרים הבאים
- איך מגדירים התפרצות Pod ב-GKE
- איך בוחרים מחלקות מחשוב לפודים של Autopilot
- איך מאיצים את הפעלת האפליקציה באמצעות שיפור ביצועי המעבד (CPU) בזמן ההפעלה