התאמה אנכית של קבוצות Pod לעומס

טייס אוטומטי רגילה

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

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

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

לפני שקוראים את הדף הזה, חשוב להכיר את הבקשות והמגבלות של משאבים ב-Kubernetes.

כדי להרחיב במהירות את הקיבולת בתגובה לשימוש פתאומי במשאבים, אפשר להשתמש ב-Horizontal Pod Autoscaler.

כדי לקרוא על שיטות מומלצות להתאמה אוטומטית של גודל האשכול, אפשר לעיין במאמר שיטות מומלצות להרצה של אפליקציות Kubernetes שעברו אופטימיזציה של עלויות ב-GKE.

למה כדאי להשתמש בהתאמה אנכית של קבוצות Pod לעומס

התאמה אנכית של קבוצות Pod לעומס מספקת את היתרונות הבאים:

• הגדרת בקשות וגבולות נכונים של משאבים לעומסי העבודה משפרת את היציבות ואת היעילות מבחינת עלויות. אם גודלי המשאבים של ה-Pod קטנים יותר מהנדרש לעומסי העבודה, יכול להיות שהאפליקציה תעבור ויסות נתונים (throttling) או שהיא תיכשל בגלל שגיאות של חוסר זיכרון. אם גודל המשאבים גדול מדי, אתם מבזבזים משאבים ולכן מקבלים חשבונות גדולים יותר.
• השימוש בצמתים באשכול יעיל כי הפודים משתמשים בדיוק במה שהם צריכים.
• התזמון של ה-Pods מתבצע בצמתים שבהם יש את המשאבים המתאימים.
• לא צריך להריץ משימות השוואה לביצועים שגוזלות זמן כדי לקבוע את הערכים הנכונים לבקשות של CPU וזיכרון.
• אפשר לקצר את זמן התחזוקה כי הכלי להתאמה אוטומטית לעומס יכול לשנות את בקשות המעבד והזיכרון לאורך זמן בלי שתצטרכו לבצע פעולה כלשהי.
• התאמה אנכית של קבוצות Pod לעומס פועלת בצורה הטובה ביותר עם עומסי עבודה הומוגניים שפועלים לאורך זמן.

התאמה אנכית של קבוצות Pod לעומס ב-GKE מספקת את היתרונות הבאים בהשוואה ל-open source Kubernetes autoscaler:

• ההמלצה מתבססת על גודל הצומת המקסימלי ומכסות המשאבים.
• ההודעה מועברת אל המידרוג האוטומטי של האשכול כדי להתאים את קיבולת האשכול.
• החישוב מתבסס על נתונים היסטוריים, כולל מדדים שנאספו לפני שהפעלתם את VerticalPodAutoscaler.
• מפעיל פודים של VerticalPodAutoscaler כתהליכים של מישור הבקרה, במקום פריסות בצמתי העובדים.

איך פועלת התאמה אנכית של קבוצות Pod לעומס

Vertical Pod Autoscaling מאפשר לכם לנתח ולהגדיר את משאבי המעבד והזיכרון שנדרשים לקבוצות Pod. במקום להגדיר בקשות ומגבלות של מעבד (CPU) ובקשות ומגבלות של זיכרון עבור הקונטיינרים ב-Pods, אתם יכולים להגדיר שינוי אוטומטי של גודל ה-Pod כדי לקבל ערכים מומלצים לבקשות ולמגבלות של מעבד וזיכרון, שבהם תוכלו להשתמש כדי לעדכן את ה-Pods באופן ידני. לחלופין, תוכלו להגדיר שינוי אוטומטי של גודל ה-Pod כדי שהערכים יתעדכנו אוטומטית.

התכונה Vertical Pod Autoscaling מופעלת כברירת מחדל באשכולות Autopilot.

הקשר ל-VerticalPodAutoscaler בקוד פתוח של Kubernetes

התאמה אוטומטית אנכית של Pod ב-GKE מבוססת על Kubernetes בקוד פתוח VerticalPodAutoscaler API, אבל היא הטמעה נפרדת שייחודית ל-GKE. ההטמעה של GKE מיועדת להרחבה באמצעות כלי המלצות משלה, אבל היא שומרת על אותם סוגים ושדות של VerticalPodAutoscaler API שמוגדרים בגרסת הקוד הפתוח.

מידע נוסף זמין במאמרי העזרה של Kubernetes בנושא שינוי אוטומטי של גודל ה-Pod.

מצבים של התאמה אנכית של קבוצות Pod לעומס

אתם יכולים להגדיר איך שינויים במשאבים יחולו על ידי שימוש במצבי עדכון שונים.

מצב Auto (Recreate)

הערה: התנהגות המערכת במצבים Recreate ו-Auto זהה. אם לא מציינים את השדה updateMode באובייקט VerticalPodAutoscaler, מצב ברירת המחדל הוא Auto update.

במצב Recreate, שינוי אוטומטי של גודל ה-Pod (Vertical Pod Autoscaling) מפנה Pod אם צריך לשנות את בקשות המשאבים של ה-Pod. הפינוי נדרש כי בגלל מגבלות של Kubernetes בגרסאות קודמות ל-1.33, הדרך היחידה לשנות את בקשות המשאבים של Pod פעיל היא ליצור אותו מחדש.

כדי להגביל את מספר היצירות מחדש של ה-Pod, אפשר להשתמש בתקציב הפרעות של Pod . כדי לוודא שהאשכול יכול להתמודד עם הגדלים החדשים של עומסי העבודה, כדאי להשתמש בCluster Autoscaler ובnode auto-provisioning.

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

מצב Initial

אם האפשרות Initial מופעלת, התאמה אנכית של קבוצות Pod לעומס מקצה בקשות למשאבים רק בזמן יצירת ה-Pod, ולא משנה אותן בהמשך.

מצב InPlaceOrRecreate

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאי שירות הכלליים" בתנאים הספציפיים של השירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

המטרה של מצב InPlaceOrRecreate היא לצמצם את שיבוש השירות על ידי ניסיון לעדכן את משאבי ה-Pod בלי ליצור מחדש את ה-Pod.

כדי להשתמש במצב InPlaceOrRecreate, צריך להגדיר את השדה spec.updatePolicy.updateMode לערך "InPlaceOrRecreate" באובייקט VerticalPodAutoscaler. המצב הזה מסתמך על השדה resizePolicy שמוגדר במניפסט של עומס העבודה כדי לקבוע אם שינוי במשאב מחייב הפעלה מחדש. אם לא מגדירים את השדה resizePolicy, ברירת המחדל היא NotRequired למעבד ולזיכרון, כלומר המערכת תנסה לבצע עדכונים במקום.

אם קונטיינר מסתיים בגלל אירוע OOM (Out of Memory), שינוי גודל אוטומטי של Pods באופן אנכי במצב InPlaceOrRecreate פועל באופן דומה למצב Auto: הוא לומד מהכשל. במהלך היצירה מחדש של ה-Pod שמופעלת בעקבות הקריסה, מתבצעת המלצה של שינוי אוטומטי של גודל ה-Pod בצורה אנכית, שכוללת מאגר זמני של נתונים (בדרך כלל 20% זיכרון נוסף או 100MB, הגדול מביניהם) כדי למנוע חזרה מיידית של שגיאת OOM.

מצב InPlaceOrRecreate זמין ב-Kubernetes מגרסה 1.34.0-gke.2201000 ואילך.

תרחישי גיבוי למצב InPlaceOrRecreate

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

• קיבולת לא מספקת של הצומת: בקשת המשאבים המעודכנת חורגת מהקיבולת שניתן להקצות בצומת הנוכחי, ואי אפשר לתזמן את העדכון במקום (מצב 'לא אפשרי' או 'נדחה' למשך יותר מפסק זמן).
• שינוי בסיווג QoS: העדכון של המשאב ישנה את הסיווג של איכות השירות (QoS) של ה-Pod, למשל מ-Burstable ל-Guaranteed.
• מדיניות RestartContainer: השדה resizePolicy של ה-Pod מוגדר ל-RestartContainer עבור משאב שהתכונה 'התאמה אנכית של קבוצות Pod לעומס' מנסה לשנות.
• פסק זמן: בקשה לעדכון במקום נשארת במצב 'בהמתנה' יותר מדי זמן.

מצב Off

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

שיפור הביצועים של המעבד בהפעלה

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

מידע נוסף על הגדרת האצת הפעלת המעבד זמין במאמר האצת הפעלת האפליקציה באמצעות האצת הפעלת המעבד.

איך פועל שיפור ההפעלה של מעבד

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

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

הסבר על מחזור החיים של הכלים לשיפור השותפות עם המפרסמים

תהליך ההעברה של סטארטאפים כולל שלושה שלבים:

1. שלב ההרשאה: במהלך ההרשאה של ה-Pod, ה-webhook של ה-VPA interceptor מאזין לבקשה ומזריק את ערכי ה-CPU המוגדלים לפני ש-GKE מתזמן את ה-Pod.
2. שלב ההפעלה: האפליקציה מאותחלת באמצעות הקצאת המעבד (CPU) המוגדלת באופן זמני כדי למנוע ויסות נתונים של האתחול.
3. שלב ביטול ההגדלה: אחרי שה-Pod מגיע לסטטוס Ready ועובר פרק הזמן durationSeconds, ה-VPA מקטין את בקשת ה-CPU במקום לערך הבסיסי.

הערה: VPA Updater בודק את סטטוס ה-Pod במחזור קבוע של דקה אחת כדי לטפל בביטול ההגדלה. בגלל ההערכה התקופתית הזו, מערכת GKE מודדת את התקופה durationSecondsבמרווחי זמן של דקה אחת, מה שאומר שההגברה עשויה להימשך עד דקה אחת יותר מהזמן שהוגדר.

בחירת מצב עדכון לעומסי עבודה משופרים

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

• ‫updateMode: "Off": VPA מנהל רק את ההגדלה הראשונית במהלך הוספת Pod (שלב ביצירת Pod) ואת ההקטנה הבאה אחרי ההפעלה. הוא לא משנה את בקשות המשאבים במצב היציב של הקונטיינר.
• ‫updateMode: "Auto",‏ "Recreate" או "InPlaceOrRecreate": ‏VPA מנהל את ההגדרה של הגדלת המשאבים בהפעלה וממשיך להתאים את בקשות המשאבים של ה-Pod באופן אוטומטי על סמך השימוש השוטף.

איך מחושבת הקצאת משאבים של הגדלת מהירות המעבד

‫GKE מחשב את בקשת ה-CPU הזמנית המוגדלת באופן הבא:

1. קביעת מעבד הבסיס: בקשת מעבד הבסיס תלויה בשדה VPA updateMode:

   • ‫Auto,‏ Recreate או InPlaceOrRecreate: בקשת ה-CPU הבסיסית היא ההמלצה של VPA. אם לא קיימת המלצה,‏ GKE חוזר לבקשת המעבד שהוגדרה במפרט של ה-Pod.
   • ‫Off: בקשת מעבד (CPU) של בסיס להשוואה היא ערך הבקשה ממפרט ה-Pod.

2. חישוב של CPU מוגבר: החישוב תלוי בשיטת החישוב שאתם מציינים בשדה type של הגדרות ההגברה:

   • ‫Factor: מכפיל את בקשת ה-CPU הבסיסית:

     מעבד משופר  =  מעבד בסיסי  ×  factor

   • ‫Quantity: מוסיף כמות מוחלטת של CPU לבקשת ה-CPU הבסיסית:

     מעבד משופר  =  מעבד בסיסי  +  quantity

בקשת ה-CPU הסופית תלויה במצב האשכול:

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

הסבר על התנהגות מגבלת המעבד במהלך הגדלה

האופן שבו GKE מטפל במגבלות על יחידת עיבוד מרכזית (CPU) תלוי בהגדרה ב-containerResourcePolicy:controlledValues

• ‫RequestsAndLimits (ברירת מחדל): GKE מגדיל את בקשת ה-CPU ואת המגבלה, ושומר על היחס המקורי ביניהן כדי לשמור על סיווג איכות השירות (QoS) של הקונטיינר.
• ‫RequestsOnly: ב-GKE, רק בקשת ה-CPU מוגברת. ב-GKE, הבקשה המוגברת מוגבלת לערך נמוך יותר ממגבלת ה-CPU המוגדרת, כדי לשמור על איכות השירות.

שיקולים לגבי אשכולות של Autopilot

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

• ערכי מינימום ב-Autopilot: אם הבקשה המוגברת נמוכה מדרישות המינימום של מעבד (CPU) לעומסי עבודה ב-Autopilot (לדוגמה, 50m עבור General Purpose Pods), ‏ GKE לא יחיל את ההגדלה ויאכוף את ערכי המינימום הרגילים.
• הגבלת היחס (הגברות חלקיות או דילוג על הגברות): אם בקשת ההגברה של המעבד תחרוג מטווח היחס הנדרש בין המעבד לזיכרון,‏ GKE יגביל את ההגברה לערך הגבוה ביותר שלא חורג מהזיכרון שהוקצה. אם בקשת ה-Pod המקורית כבר משתמשת ביחס המקסימלי המותר בין CPU לזיכרון, GKE מדלג על ההגדלה כדי להימנע משינוי גודל הזיכרון.
• ‫Scale-Out ComputeClass: ב-Scale-Out ComputeClass מוגדר יחס קפדני של 1:4 (CPU:Memory). ניסיון להגביר את המעבד ב-Scale-Out Pod בלי להגדיל את הזיכרון שלו עלול לגרום ל-GKE להתעלם מההגברה.

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

מדיניות בנושא משאבים

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

ספים מינימליים ותקרות מקסימליות

אפשר לציין את הערכים המינימלי (minAllowed) והמקסימלי (maxAllowed) של משאב עבור קונטיינר.

• ‫minAllowed: התאמה אנכית של קבוצות Pod לעומס לא תמליץ על ערך נמוך מהמגבלה הזו. ההגבלה הזו שימושית כי היא עוזרת להבטיח רמת ביצועים בסיסית או לעמוד בדרישות ספציפיות של האפליקציה.
• ‫maxAllowed: התאמה אנכית של קבוצות Pod לעומס לא תמליץ על ערך גבוה מהמגבלה הזו. המגבלה הזו שימושית לשליטה בעלויות או למניעת מצב שבו מאגר יחיד צורך יותר מדי משאבי צומת.

משאבים מבוקרים

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

מגבלות

• כדי להשתמש ב-Vertical Pod Autoscaling עם Horizontal Pod Autoscaling, צריך להשתמש ב-multidimensional Pod autoscaling. אפשר גם להשתמש בשינוי גודל אוטומטי של Pods בצורה אנכית עם שינוי גודל אוטומטי של Pods בצורה אופקית במדדים מותאמים אישית וחיצוניים.
• אי אפשר להשתמש ב-Vertical Pod Autoscaling עם עומסי עבודה מבוססי JVM בגלל שאין נראות מלאה של השימוש בפועל בזיכרון של עומס העבודה.
• בגרסה 1.35.1 של GKE ובגרסאות קודמות, ההגדרה של קנה מידה אוטומטי של Pods אנכי היא שתי רפליקות מינימליות לפריסות, כדי להחליף את ה-Pods בערכי משאבים מתוקנים. בגרסה 1.35.2 ואילך, ברירת המחדל היא עותק אחד מינימלי. בגרסה 1.22 ואילך, אפשר לשנות את ההגדרה הזו על ידי ציון ערך בשדה minReplicas בשדה PodUpdatePolicy.
• אם משתמשים בInPlaceOrRecreate מצב העדכון של שינוי גודל אוטומטי של Pods לפי ציר אנכי, ועדכון במקום לא אפשרי (לדוגמה, כשמגדילים את ה-Pod מעבר לקיבולת הצומת), שינוי הגודל האוטומטי של ה-Pod לפי ציר אנכי מפנה את ה-Pod ויוצר אותו מחדש כדי להחיל את ההמלצה. הפינוי והיצירה מחדש מתרחשים גם ב-Pods שיש להם שדה resizePolicy שמוגדר במפרט שלהם כדי למנוע יצירה מחדש. ההתנהגות הזו מתרחשת בבקשות לשינוי גודל של Autopilot, כולל כשמחילים משאבים מינימליים ואילוצים של יחס CPU:זיכרון.
• כדי להשתמש ב-Vertical Pod Autoscaling, צריך אובייקט של עומס עבודה שמנהל את ה-Pods, כמו Deployment, ‏ StatefulSet, ‏ ReplicaSet או ReplicationControllers. אי אפשר להשתמש בשינוי אוטומטי של גודל ה-Pod באופן אנכי עם Pods עצמאיים, כי נדרש בקר של עומס עבודה כדי לנהל את תהליך היצירה מחדש של ה-Pod.

שיטות מומלצות

• הגבלת מספר האובייקטים VerticalPodAutoscaler כדי למנוע שיבושים בעדכון האשכול, מומלץ שמספר האובייקטים מסוג VerticalPodAutoscaler בכל אשכול יהיה מתחת ל-1,000.
• התאמה אנכית של קבוצות Pod לעומס פועלת הכי טוב עם עומסי עבודה הומוגניים לטווח ארוך.
  • פעילות לטווח ארוך: עומסי עבודה שפועלים במשך 24 שעות לפחות. כדי ליצור המלצות ברמת מהימנות גבוהה, התכונה 'שינוי אוטומטי של גודל ה-Pod' (Vertical Pod Autoscaling) צריכה כמות משמעותית של נתונים היסטוריים. במצב Auto או Recreate, העדכונים מתבצעים בדרך כלל אחרי שחלפו לפחות 24 שעות מאז הפעלת ה-Pod, כדי למנוע הפעלות מחדש תכופות של ה-Pod ושינויים תכופים.
  • הומוגני: פודים שמטורגטים על ידי אובייקט VerticalPodAutoscaler יחיד (כמו כל העותקים המשוכפלים בפריסה) צריכים להציג דפוסי צריכת משאבים דומים. הכלי Vertical Pod Autoscaler יוצר המלצות על ידי צבירת נתוני השימוש בכל ה-Pods המטורגטים. אם העותקים שלכם משמשים לשימושים שונים, למשל חלק מה-Pods לא פעילים ואחרים עמוסים מאוד, יכול להיות שהכלי Vertical Pod Autoscaler יספק המלצה להקצאת יתר של ה-Pods הלא פעילים או להקצאת חסר של ה-Pods העמוסים.
• משתמשים בהתאמה אופקית לעומס (HPA) עבור עומסי עבודה עם עליות פתאומיות בביקוש. התאמה אנכית של קבוצות Pod לעומס מיועדת להתאמת גודל במצב יציב, ולא כפתרון לעליות פתאומיות וקצרות בשימוש במשאבים. עבור עומסי עבודה עם תנודות מהירות בתנועה או בביקוש למעבד או לזיכרון, מומלץ להשתמש במקום זאת ב-Horizontal Pod Autoscaler.
• שימוש בהגנה מפני שגיאות OOM. למרות שהתאמה אנכית של קבוצות Pod לעומס היא תגובתית, היא כוללת הגנה אוטומטית מפני אירועים של חוסר זיכרון (OOM). אם ה-Pod הוא OOMKilled, ה-Pod האנכי לשינוי גודל יתבונן מיד באירוע ויגדיל את המלצת הזיכרון בכ-20% (או ב-100 MB, הגדול מביניהם) כדי לשפר את היציבות כשה-Pod נוצר מחדש. מידע נוסף על אירועי OOM זמין במאמר בנושא פתרון בעיות שקשורות לאירועי OOM.

הפניית API

זוהי הפניית API של v1. מומלץ מאוד להשתמש בגרסה הזו של ה-API.

VerticalPodAutoscaler v1 autoscaling.k8s.io

שדות
	TypeMeta קבוצה, גרסה וסוג של API.
metadata	ObjectMeta מטא-נתונים סטנדרטיים של אובייקטים.
spec	VerticalPodAutoscalerSpec ההתנהגות של VerticalPodAutoscaler.
status	VerticalPodAutoscalerStatus הסטטוס האחרון שנצפה של VerticalPodAutoscaler.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

שדות
targetRef	CrossVersionObjectReference הפניה לבקר שמנהל את קבוצת ה-Pods שהקנה לשינוי גודל אוטומטי צריך לשלוט בה, למשל Deployment או StatefulSet. אפשר להפנות VerticalPodAutoscaler לכל אמצעי בקרה שיש לו משאב משנה מסוג Scale. בדרך כלל, VerticalPodAutoscaler מאחזר את קבוצת ה-Pod מ-ScaleStatus של בקר. בבקרי DaemonSet, למשל, הפונקציה VerticalPodAutoscaler מאחזרת את קבוצת ה-Pod מהמפרט של הבקר.
updatePolicy	PodUpdatePolicy ההגדרה קובעת אם עדכונים מומלצים יוחלו כשמפעילים את ה-Pod, ואם עדכונים מומלצים יוחלו במהלך הפעילות של ה-Pod.
resourcePolicy	PodResourcePolicy המדיניות הזו מציינת איך מתבצעת התאמה של בקשות לשימוש במעבד ובזיכרון עבור מאגרי נתונים נפרדים. אפשר להשתמש במדיניות של המשאב כדי להגדיר אילוצים על ההמלצות לקונטיינרים בודדים. אם לא מציינים, הכלי לשינוי גודל אוטומטי מחשב את המשאבים המומלצים לכל הקונטיינרים ב-Pod, ללא אילוצים נוספים.
recommenders	VerticalPodAutoscalerRecommenderSelector array שירות ההמלצות שאחראי ליצירת המלצות לאובייקט VPA הזה. כדי להשתמש בברירת המחדל של כלי ההמלצות שסופק על ידי GKE, צריך להשאיר את השדה ריק. אחרת, הרשימה יכולה להכיל בדיוק רשומה אחת של מערכת חלופית להמלצות שסופקה על ידי המשתמש. נתמך מגרסה GKE 1.22 ואילך.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

שדות
	TypeMeta קבוצה, גרסה וסוג של API.
metadata	ObjectMeta מטא-נתונים סטנדרטיים של אובייקטים.
items	VerticalPodAutoscaler array רשימה של VerticalPodAutoscaler אובייקטים.

PodUpdatePolicy v1 autoscaling.k8s.io

שדות
updateMode	string המדיניות קובעת אם עדכונים מומלצים יוחלו כשמפעילים את ה-Pod, ואם עדכונים מומלצים יוחלו במהלך הפעילות של ה-Pod. הערכים האפשריים הם: ‫"Off": נוצרים עדכונים מומלצים, אבל הם לא מוחלים באופן אוטומטי על ה-Pod. ‫"Initial": עדכונים מומלצים מוחלים רק כשמתחילים להשתמש ב-Pod בפעם הראשונה. עדכונים שמתרחשים בזמן שה-Pod כבר פועל לא מוחלים באופן אוטומטי. ‫"Recreate": העדכונים המומלצים מוחלים על ידי יצירה מחדש של ה-Pod. ה-Pod הקיים מסתיים ונוצר Pod חדש עם ההגדרה המעודכנת. ‫"Auto": ערך ברירת המחדל שמחיל למעשה את מצב "Recreate". ‫"InPlaceOrRecreate": אם אפשר, העדכונים המומלצים מוחלים בלי ליצור מחדש את ה-Pod.
minReplicas	int32 מספר העותקים המינימלי שצריכים להיות פעילים כדי לנסות להוציא את ה-Pod (בהמתנה לבדיקות אחרות כמו תקציב הפרעה של Pod). אפשר להשתמש רק בערכים חיוביים. ברירת המחדל היא 1 ב-GKE מגרסה 1.35.2 ואילך, ו-2 בגרסה 1.35.1 ובגרסאות קודמות. נתמך מגרסה GKE 1.22 ואילך.

‫PodResourcePolicy v1 autoscaling.k8s.io

שדות
containerPolicies	ContainerResourcePolicy array מערך של מדיניות משאבים למאגרי תגים נפרדים. יכולה להיות לכל היותר רשומה אחת לכל מאגר בעל שם, ואפשרות נוספת של רשומה אחת עם התו כללי `containerName = '*'`, שמטפלת בכל המאגרים שאין להם כללי מדיניות נפרדים.

ContainerResourcePolicy v1 autoscaling.k8s.io

שדות
containerName	string שם מאגר התגים שהמדיניות חלה עליו. אם לא מציינים מדיניות, המדיניות הזו משמשת כמדיניות ברירת המחדל.
mode	ContainerScalingMode ההגדרה קובעת אם עדכונים מומלצים יחולו על הקונטיינר כשהוא יופעל, ואם עדכונים מומלצים יחולו במהלך חיי הקונטיינר. הערכים האפשריים הם Off ו-Auto. אם לא מציינים ערך, ברירת המחדל היא Auto.
minAllowed	ResourceList מציינת את בקשת המעבד המינימלית ואת בקשת הזיכרון המינימלית שמותרות עבור הקונטיינר. כברירת מחדל, לא מוגדר מינימום.
maxAllowed	ResourceList מציינת את בקשת המעבד המקסימלית ואת בקשת הזיכרון המקסימלית שמותרות עבור המאגר. כברירת מחדל, לא מוגדר מספר מקסימלי.
controlledResources	[]ResourceName מציין את סוג ההמלצות שיחושבו (ואולי ייושמו) על ידי VerticalPodAutoscaler. אם לא מציינים ערך, המערכת משתמשת בערך ברירת המחדל [ResourceCPU, ResourceMemory].

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

שדות
name	string שם המערכת להמלצות שאחראית ליצירת ההמלצה לאובייקט הזה.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

שדות
recommendation	RecommendedPodResources הבקשות המומלצות האחרונות ל-CPU ולזיכרון.
conditions	VerticalPodAutoscalerCondition array מתאר את המצב הנוכחי של VerticalPodAutoscaler.

‫RecommendedPodResources v1 autoscaling.k8s.io

שדות
containerRecommendations	RecommendedContainerResources array מערך של המלצות לגבי משאבים למאגרי תגים נפרדים.

‫RecommendedContainerResources v1 autoscaling.k8s.io

שדות
containerName	string השם של מאגר התגים שההמלצה רלוונטית לגביו.
target	ResourceList בקשת המעבד (CPU) המומלצת ובקשת הזיכרון המומלצת עבור הקונטיינר.
lowerBound	ResourceList בקשת המינימום המומלצת למעבד (CPU) ולזיכרון עבור הקונטיינר. לא מובטח שהסכום הזה יספיק כדי שהאפליקציה תהיה יציבה. הפעלה עם בקשות קטנות יותר של CPU וזיכרון צפויה להשפיע באופן משמעותי על הביצועים או על הזמינות.
upperBound	ResourceList הבקשה המומלצת המקסימלית ל-CPU ולזיכרון עבור הכלי המכיל. סביר להניח שבקשות ל-CPU ולזיכרון שגבוהות מהערכים האלה הן בזבוז.
uncappedTarget	ResourceList ההמלצה האחרונה לגבי משאבים שחושבה על ידי הכלי להתאמה אוטומטית לעומס, על סמך השימוש בפועל במשאבים, בלי להתחשב ב-ContainerResourcePolicy. אם השימוש בפועל במשאבים גורם לכך שהיעד לא עומד בדרישות של ContainerResourcePolicy, הערך הזה עשוי להיות שונה מההמלצה המוגבלת. השדה הזה לא משפיע על הקצאת המשאבים בפועל. הוא משמש רק לציון סטטוס.

‫VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

שדות
type	VerticalPodAutoscalerConditionType סוג התנאי שמתואר. הערכים האפשריים הם: RecommendationProvided,‏ LowConfidence,‏ NoPodsMatched ו-FetchingHistory.
status	ConditionStatus הסטטוס של התנאי. הערכים האפשריים הם True,‏ False ו-Unknown.
lastTransitionTime	Time הפעם האחרונה שבה התנאי עבר מסטטוס אחד לסטטוס אחר.
reason	string הסיבה למעבר האחרון מסטטוס אחד לסטטוס אחר.
message	string מחרוזת שאנשים יכולים לקרוא, עם פרטים על המעבר האחרון מסטטוס אחד לסטטוס אחר.

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

• איך מגדירים שינוי אוטומטי של גודל הפודים לאורך
• איך מאיצים את הפעלת האפליקציה באמצעות הגברת מהירות ההפעלה של המעבד
• מידע נוסף על שינוי אוטומטי של גודל ה-Pod באופן אופקי
• מידע נוסף על שינוי גודל אוטומטי של אשכולות