בקשות למשאבים ב-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 או סדרת המכונות Z4D תומכת בבקשה מקסימלית ששווה לגודל של כונן ה-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.

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

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

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

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

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

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