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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

  • כדי להשתמש ב-Vertical Pod Autoscaling עם Horizontal Pod Autoscaling, צריך להשתמש ב-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 שמוגדר במפרט שלהם כדי למנוע יצירה מחדש. ההתנהגות הזו מתרחשת בבקשות לשינוי גודל בטייס אוטומטי, כולל כשמחילים משאבים מינימליים ואילוצים של יחס בין CPU לזיכרון.
  • כדי להשתמש ב-Vertical Pod Autoscaling (התאמה אנכית של קבוצות Pod לעומס), צריך אובייקט של עומס עבודה שמנהל את ה-Pods, כמו Deployment, ‏ StatefulSet, ‏ ReplicaSet או ReplicationControllers. אי אפשר להשתמש בשינוי אוטומטי של גודל ה-Pod באופן אנכי עם Pods עצמאיים, כי נדרש בקר של עומס עבודה כדי לנהל את תהליך היצירה מחדש של ה-Pod.

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

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

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

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

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