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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצב Auto (Recreate)

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

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

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

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

מצב Off

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

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

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

מגבלות מינימליות ומקסימליות

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

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

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

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

מגבלות

  • כדי להשתמש בהתאמה אנכית של קבוצות Pod לעומס עם התאמה אופקית של קבוצות Pod לעומס, צריך להשתמש ב-multidimensional Pod autoscaling. אפשר גם להשתמש בהתאמה אנכית של קבוצות Pod לעומס עם התאמה אופקית של קבוצות Pod לעומס במדדים מותאמים אישית וחיצוניים.
  • התאמה אנכית של קבוצות Pod לעומס לא מוכנה לשימוש עם עומסי עבודה מבוססי JVM, כי יש נראות מוגבלת של השימוש בפועל בזיכרון של עומס העבודה.
  • ב-התאמה אנכית של קבוצות Pod לעומס, הגדרת ברירת המחדל היא שתי רפליקות מינימליות לפריסות, כדי להחליף את ה-Pods בערכי משאבים מתוקנים. ב-GKE בגרסה 1.22 ואילך, אפשר לשנות את ההגדרה הזו על ידי ציון ערך לשדה minReplicas בשדה PodUpdatePolicy.
  • אם משתמשים בInPlaceOrRecreate מצב העדכון של התאמה אנכית של קבוצות Pod לעומס ועדכון במקום לא אפשרי (לדוגמה, כשמגדילים את ה-Pod מעבר לקיבולת הצומת), התאמה אנכית של קבוצות Pod לעומס מפנה את ה-Pod ויוצר אותו מחדש כדי להחיל את ההמלצה. הפינוי והיצירה מחדש מתרחשים גם עבור Pods שמוגדר בהם שדה resizePolicy במפרט כדי למנוע יצירה מחדש. ההתנהגות הזו מתרחשת בבקשות לשינוי גודל בטייס אוטומטי, כולל כשמחילים משאבים מינימליים ואילוצים של יחס CPU:זיכרון.
  • התאמה אנכית של קבוצות 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 לעומס מיועדת להתאמת גודל במצב יציב, ולא לפתרון של עליות פתאומיות וקצרות בשימוש במשאבים. עבור עומסי עבודה עם תנודות מהירות בתנועה או בביקוש למעבד או לזיכרון, מומלץ להשתמש במקום זאת בכלי לשינוי גודל אוטומטי של Pod אופקי.
  • שימוש בהגנה מפני שגיאות OOM. למרות שהתאמה אנכית של קבוצות Pod לעומס היא תגובתית, היא כוללת הגנה אוטומטית מפני אירועים של חוסר זיכרון (OOM). אם ה-Pod הוא OOMKilled, הכלי Vertical Pod Autoscaler מתעד את האירוע באופן מיידי ומגדיל את המלצת הזיכרון בכ-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). מותר להשתמש רק בערכים חיוביים. ברירת המחדל היא 2. נתמך החל מ-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

שדות
containerRecommendation

RecommendedContainerResources array

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

‫RecommendedContainerResources v1 autoscaling.k8s.io

שדות
containerName

string

השם של מאגר התגים שההמלצה רלוונטית לגביו.
target

ResourceList

בקשת ה-CPU המומלצת ובקשת הזיכרון המומלצת עבור הקונטיינר.
lowerBound

ResourceList

בקשת ה-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

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

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