בקשות למשאבים ב-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. התנאים הבאים חלים:

• בקשה מינימלית לכל צומת: כשמשתמשים במודל החיוב מבוסס-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 ואילך, ל-Pods מסוג Performance class ול-Pods של מאיצי חומרה יש תמיכה בבקשת אחסון זמני מקסימלית של 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.

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

• אם האשכול שלכם תומך בשימוש זמני במשאבים מעבר למכסה, ב-Autopilot לא נאכפים תוספות של 0.25 vCPU לבקשות ה-CPU של ה-Pod. אם האשכול לא תומך ב-bursting, מצב 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 לא אוכף בקשות מינימליות של CPU, זיכרון או אחסון זמני עבור Pods שמשתמשים במאיצים. בטבלה הבאה מתוארים מספר הבקשות המקסימלי לכל אחד מהמשאבים האלה, על סמך מספר המאיצים וסוג המאיץ שבו אתם משתמשים.

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

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

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

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

• אתם משתמשים בpodFamily כלל עדיפות בכל מחלקה מותאמת אישית של Autopilot Compute שאינה ברירת המחדל ברמת האשכול.
• אתם פורסים עומסי עבודה שעומדים בשני הקריטריונים הבאים:
  • משתמשים באחת מהגדרות המחשוב הבאות:
    • פלטפורמת המחשוב שמותאמת לקונטיינרים שמוגדרת כברירת מחדל באשכולות של 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 container ב-Pod.
• סכום הבקשות לכל מאגרי האפליקציות ב-Pod.

מידע נוסף זמין במאמר בנושא ניהול אוטומטי של משאבים ב-Autopilot.

הקצאת משאבים ידנית למאגרי init

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

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

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

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

• איך מגדירים Pod bursting ב-GKE
• איך בוחרים מחלקות מחשוב ל-Pods של Autopilot
• מידע נוסף על Balanced ו-Scale-Out ComputeClasses באשכולות של Autopilot
• מידע נוסף על מכסות ומגבלות
• איך משתמשים בדיסקים לאחסון מתמיד ייעודיים כנפחים זמניים