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

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

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

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

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

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

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

  • מדדים מותאמים אישית: מבוססים על כל מדד שמדווח על ידי אובייקט Kubernetes באשכול, כמו קצב הבקשות של הלקוח לשנייה או כתיבות קלט/פלט לשנייה.

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

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

    לדוגמה, יכול להיות שעומס העבודה שלכם יצטרך יותר CPU כשמבצעים המרה של מספר גדול של בקשות מצינור כמו Pub/Sub. אפשר ליצור מדד חיצוני לגודל התור, ולהגדיר את Horizontal Pod Autoscaler (HPA) כך שיגדיל באופן אוטומטי את מספר ה-Pods כשגודל התור מגיע לסף מסוים, ויקטין את מספר ה-Pods כשגודל התור קטן.

אפשר לשלב בין Horizontal Pod Autoscaler (HPA) לבין Vertical Pod Autoscaler (VPA), אבל יש כמה מגבלות.

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

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

משאבים לכל Pod

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

  • אם מציינים ערך גולמי למעבד או לזיכרון, המערכת משתמשת בערך הזה.
  • אם מציינים ערך באחוזים למעבד (CPU) או לזיכרון, הכלי Horizontal Pod Autoscaler (HPA) מחשב את ערך הניצול הממוצע כאחוז מתוך בקשות המעבד (CPU) או הזיכרון של ה-Pod.
  • מדדים מותאמים אישית ומדדים חיצוניים מוצגים כערכים גולמיים או כערכים ממוצעים.

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

תגובה למדדים רבים

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

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

מניעת העמסה

Thrashing מתייחס למצב שבו ה-Horizontal Pod Autoscaler (HPA) מנסה לבצע פעולות אוטומטיות עוקבות של שינוי גודל לפני שהעומס מסיים להגיב לפעולות קודמות של שינוי גודל. כדי למנוע תנודות חדות, הכלי האוטומטי לשינוי גודל של Pod אופקי בוחר את ההמלצה הגדולה ביותר מתוך חלון ייצוב שצוין. ההתנהגות הזו נשלטת על ידי השדה scaleDown.stabilizationWindowSeconds במפרט של HPA‏ behavior, שמוגדר כברירת מחדל ל-300 שניות (חמש דקות) ב-GKE.

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

שינוי גודל לאפס ומאפס

ב-GKE בגרסה 1.37 ואילך, אפשר להגדיר את הכלי האוטומטי לשינוי גודל של Pod אופקי כדי להקטין את עומס העבודה ל-0 רפליקות כשאין ביקוש, ולהגדיל את עומס העבודה באופן אוטומטי כשהביקוש מתחדש. התנהגויות שקשורות להרחבת היקף השימוש מ-0 ועד לשימוש מלא:

  • עקיפת סף הסבילות: כשעומס העבודה הוא 0 רפליקות, GKE עוקף את בדיקת סף הסבילות הרגילה של המדד (יחס של 0.9 עד 1.1). כל ערך של מדד שגדול מאפס, כמו הודעה אחת בתור, מפעיל באופן מיידי הגדלה של מספר העותקים לפחות ל-1, בלי לחכות לחציית סף הסבילות.
  • חלונות ייצוב: הגדלת הקיבולת מוגדרת כברירת מחדל ל-0 שניות (scaleUp.stabilizationWindowSeconds: 0) להפעלה מיידית, והקטנת הקיבולת מוגדרת כברירת מחדל ל-300 שניות (scaleDown.stabilizationWindowSeconds: 300) כדי להבטיח חמש דקות רצופות של אפס ביקוש לפני שינוי הגודל ל-0 רפליקות.
  • תנאי סטטוס: כשמבצעים שינוי גודל ל-0 רפליקות באמצעות HPA, הבקר מדווח על התנאי ScaledToZero: True ונשאר פעיל (ScalingActive: True). אם משנים את גודל עומס העבודה באופן ידני ל-0 רפליקות מחוץ ל-HPA (למשל באמצעות הפקודה kubectl scale), שינוי הגודל האוטומטי מושהה (ScalingActive: False) עד שעומס העבודה יוקטן בחזרה ל-1 רפליקות או יותר.

הוראות מפורטות זמינות במאמר שינוי קנה מידה של עומסי עבודה ב-GKE לאפס ומאפס באמצעות HPA.

מגבלות

  • אל תשתמשו ב-Horizontal Pod Autoscaler יחד עם Vertical Pod Autoscaler במעבד (CPU) או בזיכרון. אפשר להשתמש ב-Horizontal Pod Autoscaler (HPA) יחד עם Vertical Pod Autoscaler (VPA) למדדים אחרים. אתם יכולים להגדיר התאמה אוטומטית של גודל ה-Pod בכמה ממדים (בשלב בטא) כדי לשנות את הגודל אופקית לפי CPU ואנכית לפי זיכרון בו-זמנית.
  • אם יש לכם Deployment (פריסה), אל תגדירו את התכונה 'התאמה אופקית של קבוצות Pod לעומס' ב-ReplicaSet או ב-Replication Controller שמשמשים כגיבוי. כשמבצעים עדכון הדרגתי ב-Deployment או ב-Replication Controller, הוא מוחלף ב-Replication Controller חדש. במקום זאת, מגדירים התאמה אופקית של קבוצות Pod לעומס (autoscaling) בפריסת ה-Deployment עצמה.
  • אי אפשר להשתמש בהתאמה אופקית של קבוצות Pod לעומס עבור עומסי עבודה שלא ניתן להרחיב, כמו DaemonSets.
  • התאמה אופקית של קבוצות Pod לעומס חושפת מדדים כמשאבי Kubernetes, מה שמגביל את שמות המדדים, למשל אי אפשר להשתמש באותיות רישיות או בתווים '/'. יכול להיות שאפשר לשנות את השם של מתאם המדדים. לדוגמה, אפשר לעיין באופרטור prometheus-adapter as.
  • המידרוג האוטומטי של ה-Pods לא מצטמצם אם אחד מהמדדים שהוא מוגדר לעקוב אחריהם לא זמין. כדי לבדוק אם יש לכם מדדים לא זמינים, אפשר לעיין במאמר בנושא הצגת פרטים על מידרוג אוטומטי אופקי של Pod.

מדרגיות

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

  • ב-GKE בגרסה משנית 1.31 או 1.32, אם מוגדר פרופיל הביצועים של HPA, תקופת החישוב מחדש צריכה להיות עד 15 שניות עם עד 1,000 אובייקטים של HPA. איך מגדירים את פרופיל ה-HPA של הביצועים
  • ב-GKE בגרסה משנית 1.33 ומעלה, אם מוגדר פרופיל הביצועים של HPA, תקופת החישוב מחדש צריכה להיות עד 15 שניות עם עד 5,000 אובייקטים של HPA. פרופיל ה-HPA של הביצועים מופעל כברירת מחדל בכל האשכולות שעומדים בדרישות.
  • אם פרופיל הביצועים של HPA לא מוגדר, תקופת החישוב מחדש צריכה להיות עד 15 שניות עם עד 300 אובייקטים של HPA.

הגורמים הבאים יכולים גם להשפיע על הביצועים:

אינטראקציה עם אובייקטים של HorizontalPodAutoscaler

כדי להגדיר שינוי גודל אוטומטי של Pod אופקי לעומס עבודה, ולקבל מידע על אירועים של שינוי גודל אוטומטי ומה גרם להם, אפשר להיכנס לדף Workloads במסוף Cloud de Confiance .

כל Horizontal Pod Autoscaler קיים באשכול כאובייקט HorizontalPodAutoscaler. אפשר להשתמש בפקודות כמו kubectl get hpa או kubectl describe hpa HPA_NAME כדי ליצור אינטראקציה עם האובייקטים האלה.

אפשר גם ליצור אובייקטים של HorizontalPodAutoscaler באמצעות הפקודה kubectl autoscale.

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