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

Autopilot Standard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצב Auto (Recreate)

הערה: המצבים Recreate ו-Auto פועלים באותו אופן. מצב העדכון Auto הוא מצב ברירת המחדל אם השדה updateMode לא צוין באובייקט VerticalPodAutoscaler.

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

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

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

מצב Initial

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

מצב InPlaceOrRecreate

תצוגה מקדימה

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

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

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

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

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

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

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

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

מצב Off

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

האצת המעבד בזמן אתחול

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

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

איך פועלת האצת המעבד בזמן אתחול

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

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

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

תהליך שיפור ההפעלה מורכב משלושה שלבים:

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

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

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

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

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

איך מחושבת הקצאת המשאבים של שיפור ביצועי המעבד (CPU)

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

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

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

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

   • ‫Factor: החלת מכפיל על בקשת המעבד (CPU) הבסיסית:

     מעבד (CPU) מוגבר  =  מעבד (CPU) בסיסי  ×  factor

   • ‫Quantity: הוספת כמות מוחלטת של מעבד (CPU) לבקשת המעבד הבסיסית:

     מעבד (CPU) מוגבר  =  מעבד (CPU) בסיסי  +  quantity

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

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

הסבר על ההתנהגות של מגבלת המעבד (CPU) במהלך הגדלת המשאבים

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

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

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

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

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

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

כללי מדיניות לגבי משאבים

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

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

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

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

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

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

מגבלות

• כדי להשתמש בהתאמה אנכית של קבוצות Pod לעומס עם התאמה אופקית של קבוצות Pod לעומס ב-CPU, צריך להשתמש ב-HPA rightsizing with VPA (גרסת טרום-השקה) או בהתאמה רב-ממדית של קבוצות Pod לעומס. אפשר גם להשתמש בהתאמה אנכית של קבוצות Pod לעומס יחד עם התאמה אופקית של קבוצות Pod לעומס במדדים בהתאמה אישית ובמדדים חיצוניים.
• התאמה אנכית של קבוצות Pod לעומס לא מוכנה לשימוש עם עומסי עבודה שמבוססים על JVM, בגלל חשיפה מוגבלת לשימוש בפועל בזיכרון של עומס העבודה.
• בגרסה 1.35.1 של GKE ובגרסאות קודמות, ההגדרה שמוגדרת כברירת מחדל להתאמה אנכית של קבוצות Pod לעומס היא שתי רפליקות מינימליות לפריסות, כדי להחליף קבוצות Pod בערכי משאבים מתוקנים. בגרסה 1.35.2 ואילך, ברירת המחדל היא רפליקה אחת לפחות. בגרסה 1.22 ואילך, אפשר לשנות את ההגדרה הזו על ידי ציון ערך לשדה minReplicas בשדה PodUpdatePolicy.
• אם אתם משתמשים במצב העדכון InPlaceOrRecreate של התאמה אנכית של קבוצות Pod לעומס, ואי אפשר לבצע עדכון במקום (לדוגמה, כשמגדילים את קבוצת ה-Pod מעבר לקיבולת של הצומת), התכונה "התאמה אנכית של קבוצות Pod לעומס" מפנה את קבוצת ה-Pod ויוצרת אותה מחדש כדי ליישם את ההמלצה. הפינוי והיצירה מחדש מתרחשים גם בפודים שבהם מוגדר השדה resizePolicy במפרט שלהם כדי למנוע יצירה מחדש. ההתנהגות הזו מתרחשת בבקשות לשינוי כמות ב-Autopilot, כולל כשמחילים אילוצים על משאבי מינימום ועל היחס בין המעבד (CPU) לזיכרון.
• כדי להשתמש בהתאמה אנכית של קבוצות Pod לעומס, צריך אובייקט של עומס עבודה שמנהל את קבוצות ה-Pod, כמו Deployment, ‏ StatefulSet, ‏ ReplicaSet או ReplicationControllers. אי אפשר להשתמש בהתאמה אנכית של קבוצות Pod לעומס עם קבוצות Pod עצמאיות, כי נדרש בקר עומס עבודה כדי לנהל את תהליך היצירה מחדש של קבוצות Pod.
• התאמה אנכית של קבוצות Pod לעומס יוצרת המלצות ומחילה עדכונים רק על בקשות למשאבים ומגבלות ברמת הקונטיינר (spec.containers[].resources). התאמה אנכית של קבוצות Pod לעומס לא תומכת במפרטי משאבים ברמת ה-Pod (spec.resources).

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

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

מאמרי העזרה של ה-API

זהו מאמר העזרה של v1 API. אנחנו ממליצים מאוד להשתמש בגרסה הזו של ה-API.

‫VerticalPodAutoscaler v1 autoscaling.k8s.io

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

‫VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

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

‫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 ומטה. נתמך החל מגרסה 1.22 של GKE.

‫PodResourcePolicy v1 autoscaling.k8s.io

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

‫ContainerResourcePolicy v1 autoscaling.k8s.io

שדות
containerName	string שם מאגר התגים שהמדיניות חלה עליו. אם לא מציינים את המדיניות, היא משמשת כמדיניות ברירת המחדל.
mode	ContainerScalingMode ההגדרה קובעת אם העדכונים המומלצים יחולו על הקונטיינר כשהוא מופעל, ואם העדכונים המומלצים יחולו במהלך חיי הקונטיינר. הערכים האפשריים הם "Off" ו-"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) ולזיכרון שגבוהות מהערכים האלה כנראה יתבזבזו.
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 לעומס
• איך מתאימים את הגודל של עומסי עבודה של HPA באמצעות VPA
• איך מאיצים את הפעלת האפליקציה באמצעות שיפור ביצועי המעבד (CPU) בזמן ההפעלה
• מידע נוסף על התאמה אופקית של קבוצות Pod לעומס
• מידע נוסף על מידרוג אוטומטי של אשכול.