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

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

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

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

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

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

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

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

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

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

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

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

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

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

התאמה אנכית של קבוצות Pod לעומס מופעלת כברירת מחדל באשכולות Autopilot.

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

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

מידע נוסף זמין במאמרי העזרה של Kubernetes בנושא התאמה אנכית של קבוצות Pod לעומס.

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

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

מצב Auto (Recreate)

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

כדי להגביל את מספר היצירות מחדש של ה-Pod, אפשר להשתמש בתקציב הפרעות של Pod . כדי לוודא שהאשכול יכול להתמודד עם הגדלים החדשים של עומסי העבודה, כדאי להשתמש בCluster Autoscaler ובהקצאת צמתים אוטומטית (NAP).

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

מצב Initial

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

מצב InPlaceOrRecreate

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. חישוב של השימוש המוגבר במעבד: החישוב תלוי בשיטת החישוב שציינתם בשדה 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 לא יחיל את ההגדלה ויאכוף את ערכי המינימום הרגילים.
  • הגבלת יחס (הגברות חלקיות או דילוג על הגברות): אם בקשת ההגברה של המעבד (CPU) תחרוג מטווח היחס הנדרש בין המעבד לזיכרון, GKE יגביל את ההגברה לערך הגבוה ביותר שלא חורג מהזיכרון שהוקצה. אם בקשת ה-Pod המקורית כבר משתמשת ביחס המקסימלי המותר בין CPU לזיכרון, GKE מדלג על ההגדלה כדי להימנע משינוי גודל הזיכרון.
  • ‫Scale-Out ComputeClass: ב-Scale-Out ComputeClass מוגדר יחס קפדני של 1:4 (CPU:Memory). ניסיון להגדיל את המעבד ב-Scale-Out Pod בלי להגדיל את הזיכרון עלול לגרום ל-GKE להתעלם מההגדלה.

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

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

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

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

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

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

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

מגבלות

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

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

  • הגבלת מספר האובייקטים VerticalPodAutoscaler כדי למנוע שיבושים בעדכון האשכול, מומלץ שמספר האובייקטים מסוג VerticalPodAutoscaler בכל אשכול יהיה מתחת ל-1,000.
  • התאמה אנכית של קבוצות Pod לעומס פועלת הכי טוב עם עומסי עבודה הומוגניים לטווח ארוך.
    • פעילות לטווח ארוך: עומסי עבודה שפועלים במשך 24 שעות לפחות. כדי ליצור המלצות ברמת סמך גבוהה, התאמה אנכית של קבוצות Pod לעומס צריכה כמות משמעותית של נתונים היסטוריים. במצב Auto או Recreate, העדכונים מתבצעים בדרך כלל אחרי שחלפו לפחות 24 שעות מאז הפעלת ה-Pod, מה שעוזר למנוע הפעלות מחדש תכופות של ה-Pod ושינויים תכופים.
    • הומוגני: פודים שמטורגטים על ידי אובייקט VerticalPodAutoscaler יחיד (כמו כל העותקים המשוכפלים בפריסה) צריכים להציג דפוסי צריכת משאבים דומים. הכלי Vertical Pod Autoscaler יוצר המלצות על ידי צבירת נתוני השימוש בכל ה-Pods המטורגטים. אם הרפליקות שלכם משמשות לשימושים שונים, למשל חלק מה-Pods בלי פעילות ואחרים עמוסים מאוד, יכול להיות שהכלי Vertical Pod Autoscaler יספק המלצה להקצאת יתר של ה-Pods בלי פעילות או להקצאת חסר של ה-Pods העמוסים.
  • משתמשים בהתאמה אופקית של קבוצות Pod לעומס עבור עומסי עבודה עם עליות פתאומיות בביקוש. התאמה אנכית של קבוצות 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

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

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