Kubernetes Autoscaling: HPA, VPA ו-Cluster Autoscaler

מאת צוות מדיה דיל · 05.09.2026 · טכנולוגיה · 6 דק׳

איך HPA מוסיף Pods, VPA מתאים גודל, Cluster Autoscaler מוסיף Nodes, הקונפליקט בין HPA ל-VPA, וזמני תגובה אמיתיים לעומס פתאומי.

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

HPA: הוספה והפחתה של מספר ה-Pods

Horizontal Pod Autoscaler עוקב אחרי מדד — לרוב אחוז ניצול CPU או זיכרון מול Request שהוגדר — ומשווה אותו ל-Target שהוגדר מראש כל 15 שניות כברירת מחדל. אם הניצול הממוצע חורג מה-Target, HPA מחשב את מספר ה-Replicas הרצוי לפי נוסחה יחסית (יחס בין הניצול הנוכחי ליעד) ומעדכן את ה-Deployment בהתאם. זו התגובה המהירה ביותר לעומס — הוספת Pod חדש, לא שדרוג משאבים לקיים.

Custom ו-External Metrics: מעבר ל-CPU בלבד

CPU לא תמיד המדד הנכון — שירות שמעבד תור הודעות צריך לסקל לפי אורך התור, לא לפי ניצול מעבד. KEDA (Kubernetes Event-Driven Autoscaling) מרחיב את HPA לתמוך במדדים חיצוניים כאלה — אורך תור ב-Redis או Kafka, קצב בקשות, מדד עסקי מותאם — כך שהסקיילינג משקף את העומס האמיתי, לא רק את הסימפטום שלו במעבד.

VPA: התאמת גודל ה-Pod עצמו

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

הקונפליקט: HPA ו-VPA על אותו מדד

הרצת HPA מבוסס CPU ו-VPA שמכוון Requests של CPU על אותו Deployment יוצרת לולאת משוב לא יציבה — VPA משנה את ה-Request, מה שמשנה את אחוז הניצול שHPA רואה, מה שגורם ל-HPA להגיב, וחוזר חלילה. הפתרון המקובל: VPA במצב Recommendation בלבד (בלי עדכון אוטומטי) לצד HPA פעיל, או הפרדה ברורה — VPA על מדדים ש-HPA לא נוגע בהם.

Cluster Autoscaler: כשאין מקום לעוד Pods

כשHPA מבקש עוד Pods אבל אין Node עם משאבים פנויים להריץ אותם, ה-Pods נשארים במצב Pending. Cluster Autoscaler עוקב אחרי מצב כזה ומוסיף Node חדש אוטומטית מקבוצת ה-Node Pool המוגדרת — ובכיוון ההפוך, מסיר Node שהניצול בו נמוך מדי, תוך כיבוד Pod Disruption Budget כדי לא לפנות יותר מדי Pods בבת אחת ולפגוע בזמינות.

זמן תגובה אמיתי: לא הכל קורה מיד

הוספת Pod חדש כשיש כבר Node פנוי לוקחת שניות — משיכת Image (אם לא ב-Cache), אתחול הקונטיינר, Readiness Probe. אבל כשגם צריך Node חדש, הזמן קופץ לדקות שלמות — הקצאת מכונה מהספן הענן, אתחול, הצטרפות לאשכול. עומס פתאומי וחד (Spike) עלול לפגוע במשתמשים באותם דקות ביניים, לפני שCluster Autoscaler בכלל סיים להוסיף קיבולת.

מלכודות נפוצות: תנודתיות (Thrashing) וחלון ייצוב

הגדרת Target רגיש מדי גורמת ל-HPA להוסיף ולהסיר Pods לסירוגין בתגובה לתנודות טבעיות בעומס — כל שינוי כזה גורר עלות Restart ואי-יציבות. חלון ייצוב (Stabilization Window) מגביל את קצב ההקטנה כדי למנוע תגובת יתר, במחיר של תגובה איטית יותר להורדת עומס אמיתית — כוונון בין השניים דורש מדידה בפועל, לא ערך ברירת מחדל שרירותי.

איך זה מתחבר לבחירה בין Kubernetes ל-Serverless

כל שכבות הסקיילינג האלה דורשות תשתית, ניטור וכוונון מתמשך — עלות תפעולית אמיתית שכדאי לשקול מול Serverless, שם הסקיילינג מובנה ואוטומטי לגמרי אבל במחיר גמישות נמוכה יותר. ופריסת גרסה חדשה לתוך אשכול שממילא מתנודד בכמות Pods דורשת אסטרטגיה זהירה — ראו Blue-Green ו-Canary Deployment לגישה הנכונה לשילוב בין השניים.

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

תגיות: Kubernetes · Autoscaling · HPA · VPA · Cluster Autoscaler

← חזרה לבלוג · צור קשר