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

בדף הזה מוסבר איך לנתח ולבצע אופטימיזציה של הקצאת המשאבים כדי לשפר את יעילות עומס העבודה ב-Google Kubernetes Engine‏ (GKE) באמצעות התאמה אוטומטית אנכית של Pods. ניתוח השימוש במשאבים של עומס העבודה לאורך זמן מאפשר לקבל המלצות לאופטימיזציה ולהתאים באופן אוטומטי את בקשות ה-CPU והזיכרון, ואת המגבלות של הקונטיינרים בתוך ה-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 מבוססת על VerticalPodAutoscaler API של Kubernetes בקוד פתוח, אבל היא הטמעה נפרדת שייחודית ל-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 לעומס שולחת הודעה ל-Cluster Autoscaler לפני העדכון, ומספקת את המשאבים שנדרשים לעומס העבודה שגודלו שונה לפני יצירה מחדש של עומס העבודה, כדי לצמצם את זמן ההפרעה.

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

שיפור הפעלת המעבד

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

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

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

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

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

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

תהליך ההטבה לעסקים מתחילים כולל שלושה שלבים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

האופן שבו GKE מטפל במגבלות של CPU תלוי בהגדרה של controlledValues ב-containerResourcePolicy:

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

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

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

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

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

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

מגבלות

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

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

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

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

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

  • ‫"Off": המערכת יוצרת עדכונים מומלצים, אבל לא מיישמת אותם באופן אוטומטי ב-Pod.
  • ‫"Initial": עדכונים מומלצים מוחלים רק כשמפעילים לראשונה את ה-Pod. עדכונים שמתרחשים בזמן שה-Pod כבר פועל לא מוחלים באופן אוטומטי.
  • ‫"Recreate": העדכונים המומלצים מוחלים על ידי יצירה מחדש של ה-Pod. ה-Pod הקיים מסתיים, ונוצר Pod חדש עם ההגדרה המעודכנת.
  • ‫"Auto": ערך ברירת המחדל שמחיל למעשה את מצב "Recreate".
  • ‫"InPlaceOrRecreate": עדכונים מומלצים מוחלים בלי ליצור מחדש את ה-Pod, אם אפשר.
minReplicas

int32

מספר הרפליקות המינימלי שצריך להיות פעיל כדי לנסות להוציא את ה-Pod (בהמתנה לבדיקות אחרות כמו תקציב לשיבוש Pod). מותר להשתמש רק בערכים חיוביים. ברירת המחדל היא 1 בגרסה 1.35.2 ואילך של GKE, ו-2 בגרסה 1.35.1 ובגרסאות קודמות. נתמך מגרסה GKE 1.22 ואילך.

PodResourcePolicy v1 autoscaling.k8s.io

שדות
containerPolicies

ContainerResourcePolicy array

מערך של מדיניות משאבים עבור מאגרי תגים נפרדים. יכולה להיות לכל היותר רשומה אחת לכל מאגר בעל שם, ואפשרות נוספת היא רשומה אחת עם wildcard ‏(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

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

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

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