בקשות למשאבים ב-Autopilot

כדי לשפר את היציבות של עומסי העבודה, מצב Autopilot ב-Google Kubernetes Engine‏ (GKE) מנהל את הערכים של בקשות למשאבי Pod, כמו CPU, זיכרון או אחסון זמני. בדף הזה מופיעים הפרטים הבאים, שבעזרתם תוכלו לתכנן עומסי עבודה יעילים, יציבים וחסכוניים:

• ערכי ברירת מחדל ש-Autopilot מחיל על Pods שלא צוינו בהם ערכים.
• ערכי המינימום והמקסימום שהטייס האוטומטי אוכף לגבי בקשות למשאבים.
• איך ערכי ברירת המחדל, המינימום והמקסימום משתנים בהתאם לחומרה שה-Pods מבקשים.

הדף הזה מיועד לאנשי תפעול ולמפתחים שמקצים ומגדירים משאבי ענן ופורסים עומסי עבודה. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן ב Cloud de Confiance by S3NS תוכן זמין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

כדאי שתכירו את ניהול המשאבים ב-Kubernetes.

סקירה כללית של בקשות למשאבים ב-Autopilot

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

כשפורסים עומס עבודה באשכול Autopilot, ‏ GKE מאמת את הגדרת עומס העבודה מול הערכים המינימליים והמקסימליים המותרים עבור סוג המחשוב או הגדרת החומרה שנבחרו (למשל מעבדי GPU). אם מספר הבקשות נמוך מהמינימום, טייס אוטומטי משנה באופן אוטומטי את הגדרות העומס כדי שמספר הבקשות יהיה בטווח המותר. אם מספר הבקשות חורג מהמקסימום, Autopilot דוחה את עומס העבודה ומציג הודעת שגיאה.

הרשימה הבאה מסכמת את הקטגוריות של בקשות למשאבים:

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

איך מבקשים משאבים

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

• בחירת מחלקות מחשוב ל-Pods של Autopilot
• פריסת עומסי עבודה של GPU ב-Autopilot

בקשות ברירת מחדל למשאבים

אם לא מציינים בקשות למשאבים עבור חלק מהקונטיינרים ב-Pod,‏ Autopilot מחיל ערכי ברירת מחדל. הגדרות ברירת המחדל האלה מתאימות לעומסי עבודה קטנים רבים.

בנוסף, במצב Autopilot מוגדרות בקשות ברירת המחדל הבאות למשאבים, ללא קשר לסוג המחשוב או להגדרת החומרה שנבחרו:

• קונטיינרים ב-DaemonSets

  • מעבד (CPU):‏ 50 mCPU
  • זיכרון: 100 MiB
  • אחסון זמני: 100 MiB

• כל שאר המאגרים

  • אחסון זמני: ‎1 GiB

מידע נוסף על מגבלות של אשכולות Autopilot זמין במאמר בנושא מכסות ומגבלות.

בקשות ברירת מחדל לסוגי מחשוב

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

ב-Autopilot לא נאכפות בקשות ברירת מחדל ל-Pods של GPU ול-Pods שמשתמשים ב-ComputeClass‏ Performance.

בקשות מינימום ומקסימום למשאבים

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

• בקשה מינימלית לכל צומת: כשמשתמשים במודל חיוב מבוסס-Pod כדי להריץ עומסי עבודה במצב Autopilot באשכולות Standard, וסכום בקשות המשאבים של Pods שניתן לחייב בצומת נמוך מהבקשה המינימלית שתחול על Pod יחיד, מערכת GKE מוסיפה חיוב על הבקשה המינימלית הזו.

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

• בקשות לאחסון זמני:

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

    חומרה לחישובים שכוללת כונני SSD מקומיים כמו יחידות GPU מסוג A100 (80GB), יחידות GPU מסוג H100 (80GB), סדרת המכונות Z3 או סדרת המכונות Z4D תומכת בבקשה מקסימלית ששווה לגודל של כונן ה-SSD המקומי פחות תקורה של המערכת. מידע על התקורה של המערכת זמין במאמר אחסון זמני שמגובה על ידי כונני SSD מקומיים.

  • ב-GKE בגרסה ‎1.29.3-gke.1038000 ואילך, תרמילים מסוג Performance class Pods ו-hardware accelerator Pods תומכים בבקשת אחסון זמני מקסימלית של ‎56 TiB, אלא אם החומרה כוללת כונני SSD מקומיים.

    בכל שאר ה-Pods של Autopilot, ללא קשר לגרסת GKE, בקשת האחסון הכוללת לזמני צריכה להיות בין 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.

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

• אם האשכול תומך בשימוש זמני במשאבים מעבר למכסה, ב-Autopilot לא נאכפים תוספות של 0.25 vCPU לבקשות ה-CPU של ה-Pod. אם האשכול לא תומך בשימוש זמני במשאבים מעבר למכסה, מצב Autopilot מעגל את בקשות ה-CPU למספר הקרוב ביותר של 0.25 vCPU. כדי לבדוק אם האשכול תומך בשימוש ב-Bursting, אפשר לעיין במאמר זמינות של Bursting ב-GKE.

• יחס המעבד לזיכרון חייב להיות בטווח המותר עבור סוג המחשוב או תצורת החומרה שנבחרו. אם יחס המעבד לזיכרון חורג מהטווח המותר, Autopilot מגדיל אוטומטית את המשאב הקטן יותר. לדוגמה, אם תבקשו 1 vCPU ו-16 GiB של זיכרון (יחס של 1:16) בשביל Pods שפועלים בכיתה Scale-Out, ‏ Autopilot יגדיל את בקשת ה-CPU ל-4 vCPUs, וישנה את היחס ל-1:4.

ערכי מינימום ומקסימום לסוגי מחשוב

בטבלה הבאה מפורט יחס הזיכרון ל-CPU המינימלי, המקסימלי והמותר לכל מחלקה של מחשוב שנתמכת על ידי Autopilot:

כדי ללמוד איך לבקש מחלקות מחשוב ב-Pods של Autopilot, אפשר לעיין במאמר בחירת מחלקות מחשוב ל-Pods של Autopilot.

ערכי מינימום ומקסימום לשיפורי מהירות

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

אלא אם מציינים אחרת, נפח האחסון הזמני המקסימלי שנתמך הוא 56 TiB.

מידע על בקשת מעבדי GPU ב-Autopilot Pods זמין במאמר פריסת עומסי עבודה של GPU ב-Autopilot.

בקשות למשאבים להפרדה של עומסי עבודה ולמשך זמן ממושך

בתרחישים הבאים, Autopilot אוכף ערכים גבוהים יותר לבקשות ברירת המחדל ולבקשות המינימום למשאבים:

• משתמשים בpodFamily כלל עדיפות בכל מחלקה מותאמת אישית של Autopilot ComputeClass שלא מוגדרת כברירת מחדל ברמת האשכול.
• אתם פורסים עומסי עבודה שעומדים בשני הקריטריונים הבאים:
  • משתמשים באחת מהגדרות החישוב הבאות:
    • פלטפורמת ברירת המחדל של מחשוב שמותאמת לקונטיינרים באשכולות של Autopilot.
    • כל ComputeClass מובנה של Autopilot.
    • podFamily כללי עדיפות ב-ComputeClass בהתאמה אישית של Autopilot, שמוגדר גם כברירת המחדל ברמת האשכול.
    • ‫ComputeClasses‏ Balanced או Scale-Out באשכולות של Autopilot.
  • אפשר לשנות את ההתנהגות של תזמון ופינוי ב-Kubernetes באחת מהדרכים הבאות:
    • אתם משתמשים בהפרדה של עומסי עבודה כדי לוודא ש-Pods מסוימים מוצבים רק בצמתים ספציפיים.
    • משתמשים ב-Pod anti-affinity כדי למנוע מיקום משותף של Pods באותו צומת.
    • אתם יכולים להשתמש בהערה כדי להאריך את זמן הריצה של Autopilot Pods, ולמנוע את ההוצאה שלהם מהזיכרון בגלל שדרוגים אוטומטיים של הצמתים ואירועי הקטנה של קבוצת הצמתים, למשך עד שבעה ימים.

כברירת מחדל, אם בקשות המשאבים שלכם נמוכות מהערך המינימלי המותר, Autopilot מגדיל את בקשות המשאבים כדי לעמוד בדרישות המינימום. החריג להתנהגות הזו הוא Pod anti-affinity, שבו Autopilot דוחה את ה-Pod עם הודעת שגיאה.

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

מאגרי 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

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

• מעדכנים ידנית את בקשות המשאבים של קובץ ה-init container כך שיתאימו לבקשות הכוללות החדשות ב-Pod. כשמציינים את בקשות המשאבים באופן ידני, חשוב להביא בחשבון את הנקודות הבאות:
  • בקשות שקטנות מסך המשאבים של ה-Pod יכולות להגביל את קובץ האתחול של ה-container.
  • בקשות שגבוהות מהמשאבים הכוללים של ה-Pod יכולות להגדיל את העלויות.
• מסירים את בקשות המשאבים כדי לאפשר ל-Autopilot לחשב אותן מחדש. במצב Autopilot, המערכת תנסה להקצות מחדש את המשאבים לכל קונטיינר init על סמך סך כל המשאבים הנוכחיים שנדרשים על ידי כל קונטיינרי האפליקציה ב-Pod.

הגדרת מגבלות משאבים ב-Autopilot

ב-Kubernetes אפשר להגדיר גם requests וגם limits למשאבים במפרט של ה-Pod. ההתנהגות של ה-Pods משתנה בהתאם לכך שlimits שונים מrequests, כפי שמתואר בטבלה הבאה:

resources:
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "450m"
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"

ברוב המקרים, כדאי להגדיר בקשות מתאימות למשאבים ומגבלות שוות לעומסי העבודה.

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

כמה מאגרי תגים עם סה"כ מעבד (CPU) < 0.05 vCPU

קונטיינר יחיד עם זיכרון נמוך מדי בשביל המעבד המבוקש

בדוגמה הזו, הזיכרון נמוך מדי ביחס לכמות המעבדים (מינימום ‎1 vCPU:1 GiB). היחס המינימלי המותר בין CPU לזיכרון הוא 1:1. אם היחס נמוך יותר, בקשת הזיכרון גדלה.

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

• איך מגדירים Pod bursting ב-GKE
• איך בוחרים מחלקות מחשוב ל-Pods של Autopilot
• איך מאיצים את הפעלת האפליקציה באמצעות הגדלת מהירות ההפעלה של המעבד