הגדרת HPA Kubernetes: Horizontal Pod Autoscaler לפרודקשן

מדוע HPA Kubernetes לא מבצע סקיילינג לפי העומס האמיתי

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

המקור הראשון — ספים שנקבעו «בעין». HPA מחשב אחוז לא מ-limits אלא מ-requests, לכן בקשת CPU נמוכה מדי מחזיקה את השירות במצב עומס יתר ודוחפת את המונה למקסימום, ובקשה גבוהה מדי מסתירה חוסר ברפליקות תחת עומס עד לכשלים הראשונים. רמת היעד נלקחת ממדידות, לא מתחושות.

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

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

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

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

מה נותן סקיילינג אוטומטי מנוהל של אפליקציות

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

מהירות התגובה לשיא נקבעת לא «בעין», אלא מפרופיל השירות: עבור מעבדים סינכרוניים ניצולת היעד היא בדרך כלל 60–70%, עבור עיבוד תורים — לפי מספר ההודעות לרפליקה אחת.

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

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

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

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

מצבי סקיילינג אוטומטי: השוואת גישות

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

הבחירה תלויה במידת הידיעה מראש של פרופיל התעבורה ובשאלה אם לשירות יש מדד שמשקף נאמנה את היקף העבודה שלא הושלמה.

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

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

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

הטמעת HPA Kubernetes: שלבי העבודה ההנדסית

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

1. אודיט פרופיל עומס. אוספים מדדים לתקופה אופיינית — יממה, שבוע, חודש — ובנפרד מסמנים שיאים של מבצעים, חלונות דיווח ומשימות אצווה ליליות. קובעים לפי איזה אות לבצע סקיילינג לכל עומס עבודה: לעתים קרובות זה לא CPU, אלא השהיית תגובה או אורך התור.
2. תכנון הסכימה. מגדירים רשימת עומסי עבודה לסקיילינג אוטומטי, גבולות מספר רפליקות, קישור לסקיילינג צמתים והתנהגות בעת הסרת עומס. מתאמים מה נחשב למצב חירום ומה לשיא שגרתי.
3. הגדרת ספי סקיילינג. קובעים ערכי יעד לאותות, חלונות מיצוע, השהיות תגובה ומדיניות התנהגות בעלייה ובירידה. מגבילי צעד לא נותנים לקלאסטר לצאת מכלל שליטה כשהמדד קופץ.
4. בדיקה תחת עומס. מריצים תרחישים במעגל בדיקות, תוך חזרה על פרופיל התעבורה האמיתי, ומשווים את זמן היציאה לקיבולת הנדרשת לזמן הצפוי. בנפרד בודקים כשל של רפליקה אחת ואובדן צומת.
5. מסירה לתפעול. מוסרים תצורות, סכימה, התראות על הגעה לגבול העליון ותקנון לשינוי ספים, כדי שצוות התחזוקה יוכל לשנות אותם בלעדינו.

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

מה נשאר בפרויקט: תצורות ותקנונים

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

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

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

מקרה בוחן: הסרנו כשלים והשבתה בשיאי עומס

איך היה ומה שינינו

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

בשעות השיא שיעור הבקשות הלא זמינות הגיע לכמה אחוזים. המשמרת התורנית הגיבה ידנית: בממוצע 8–10 התערבויות בשבוע של 15–20 דקות, כי האוטומציה פעלה בהשהיה ולא ראתה את תור הבקשות.

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

לאחר השינויים, שיעור אי-הזמינות בשיאים ירד מכמה אחוזים לשברי אחוז, התערבויות המשמרת התורנית הצטמצמו למקרים בודדים בחודש, והתגובה לעלייה בעומס התקצרה מ-15–20 דקות ל-1–2. צריכת המשאבים לא עלתה: הקלאסטר הפסיק להחזיק רפליקות מיותרות בשעות ירידה.

במה שונה חישוב לפי מדדים מלוח זמנים

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

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

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

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

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

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

ספקות טכניים לפני ההפעלה

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

הרפליקות «ירעדו» — תתווספנה ותיעלמנה?

הרעד מוסר בהגדרות התנהגות: חלון ייצוב בירידת עומס, צעד שינוי מספר רפליקות, מרווח בין סף ההפעלה לערך העבודה. למעלה מבצעים סקיילינג מהר, למטה — בהשהיה, כדי שפרץ קצר לא יגרור אחריו נסיגה.

הסקיילינג האוטומטי יגמור את בסיס הנתונים?

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

כיצד לבדוק את התצורה לפני תפעול בייצור?

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

נדון במשימה: ממה מתחילה ההטמעה

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

מהמזמין מספיק:

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

הצד שלנו בשלב זה: ניתוח פרופיל העומס, ניסוח דרישות לעמידות בכשלים, טיוטת מדיניות ומדדים ל-HPA Kubernetes, תוכנית הטמעה עם בדיקה על סטנד עומסים ורשימת נקודות כשל. נחזור עם הערכה, לוחות זמנים ורשימת סיכונים.

תארו את המשימה — נחזור עם הערכה ותוכנית.