שלוש רמות של קנה מידה אוטומטי ב-Kubernetes: כיצד להשתמש בהן ביעילות

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

מאמר Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler ו-Vertical Pod Autoscaler תורגם על ידי הצוות שהטמיע קנה מידה אוטומטי Kubernetes aaS מ-Mail.ru.

למה חשוב לחשוב על קנה מידה

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

עם זאת, כדאי לחשוב גם על השאלות הבאות:

1. כיצד להתאים מודולים ויישומים?
2. איך לשמור על מכולות תפעוליות ויעילות?
3. איך להגיב לשינויים מתמידים בקוד ועומסי עבודה מהמשתמשים?

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

רמות קנה מידה אוטומטי של Kubernetes

קנה מידה אוטומטי יעיל דורש תיאום בין שתי רמות:

1. רמת הפוד, כולל אופקי (Horizontal Pod Autoscaler, HPA) ואוטוscaler אנכי (Vertical Pod Autoscaler, VPA). זה מרחיב את המשאבים הזמינים עבור המכולות שלך.
2. רמת Cluster, המנוהלת על ידי Cluster Autoscaler (CA), אשר מגדיל או מקטין את מספר הצמתים בתוך האשכול.

מודול Autoscaler אופקי (HPA).

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

דיאגרמת הפעלה HPA ברמה גבוהה:

1. ה-HPA בודק ברציפות את הערכים המטריים שצוינו במהלך ההתקנה במרווח ברירת מחדל של 30 שניות.
2. ה-HPA מנסה להגדיל את מספר המודולים אם מגיעים לסף שצוין.
3. ה-HPA מעדכן את מספר העתקים בתוך בקר הפריסה/שכפול.
4. לאחר מכן, בקר הפריסה/שכפול פורס את כל המודולים הנוספים הדרושים.

HPA מתחיל את תהליך פריסת המודול כאשר מגיעים לסף מטרי

בעת שימוש ב-HPA, שקול את הדברים הבאים:

• מרווח בדיקת ה-HPA המוגדר כברירת מחדל הוא 30 שניות. זה נקבע על ידי הדגל horizontal-pod-autoscaler-sync-period במנהל הבקר.
• שגיאת ברירת המחדל היחסית היא 10%.
• לאחר העלייה האחרונה במספר המודולים, HPA צופה שהמדדים יתייצב תוך שלוש דקות. מרווח זה נקבע על ידי הדגל horizontal-pod-autoscaler-upscale-delay.
• לאחר ההפחתה האחרונה במספר המודולים, ה-HPA ממתין חמש דקות להתייצב. מרווח זה נקבע על ידי הדגל horizontal-pod-autoscaler-downscale-delay.
• HPA עובד הכי טוב עם אובייקטי פריסה ולא עם בקרי שכפול. קנה מידה אוטומטי אופקי אינו תואם לעדכון מתגלגל, אשר מפעיל ישירות את בקרי השכפול. עם הפריסה, מספר העתקים תלוי ישירות באובייקטי הפריסה.

קנה מידה אוטומטי אנכי של פודים

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

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

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

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

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

ערכת תפעול VPA ברמה גבוהה:

1. VPA בודק באופן רציף את הערכים המטריים שצוינו במהלך ההתקנה במרווח ברירת מחדל של 10 שניות.
2. אם הסף שצוין הושג, ה-VPA מנסה לשנות את כמות המשאבים שהוקצו.
3. ה-VPA מעדכן את מספר המשאבים בתוך בקר הפריסה/שכפול.
4. כאשר מודולים מופעלים מחדש, כל המשאבים החדשים מוחלים על המופעים שנוצרו.

VPA מוסיף את כמות המשאבים הנדרשת

אנא זכור את הנקודות הבאות בעת השימוש ב-VPA:

• שינוי קנה מידה מחייב הפעלה מחדש של הפוד. זה הכרחי כדי למנוע פעולה לא יציבה לאחר ביצוע שינויים. לצורך אמינות, מודולים מופעלים מחדש ומופצים על פני צמתים בהתבסס על משאבים שהוקצו לאחרונה.
• VPA ו-HPA עדיין אינם תואמים זה לזה ואינם יכולים לפעול על אותם פודים. אם אתה משתמש בשני מנגנוני קנה המידה באותו אשכול, ודא שההגדרות שלך מונעות מהם להיות מופעלים על אותם אובייקטים.
• VPA מכוון בקשות מיכל למשאבים בהתבסס רק על שימוש בעבר ובהווה. זה לא מגדיר מגבלות שימוש במשאבים. ייתכנו בעיות עם יישומים שאינם פועלים כהלכה ומתחילים להשתלט על עוד ועוד משאבים, זה יוביל לכך ש-Kubernetes תכבה את הפוד הזה.
• VPA עדיין בשלב מוקדם של פיתוח. היו מוכנים לכך שהמערכת עשויה לעבור שינויים מסוימים בעתיד הקרוב. אתה יכול לקרוא על מגבלות ידועות и תוכניות פיתוח. לפיכך, ישנן תוכניות ליישם את הפעולה המשותפת של VPA ו-HPA, כמו גם פריסת מודולים יחד עם מדיניות קנה מידה אוטומטי אנכי עבורם (לדוגמה, תווית מיוחדת 'מחייבת VPA').

קנה מידה אוטומטי של אשכול Kubernetes

Cluster Autoscaler (CA) משנה את מספר הצמתים בהתבסס על מספר התרמילים הממתינים. המערכת בודקת מעת לעת מודולים ממתינים - ומגדילה את גודל האשכול אם יש צורך במשאבים נוספים ואם האשכול אינו חורג מהמגבלות שנקבעו. ה-CA מתקשר עם ספק שירותי הענן, מבקש ממנו צמתים נוספים או משחרר צמתים לא פעילים. הגרסה הראשונה הזמינה באופן כללי של CA הוצגה ב-Kubernetes 1.8.

סכימה ברמה גבוהה של פעולת SA:

1. CA בודק מודולים ממתינים במרווח ברירת מחדל של 10 שניות.
2. אם פוד אחד או יותר נמצאים במצב המתנה מכיוון שלאשכול אין מספיק משאבים זמינים כדי להקצות אותם, הוא מנסה לספק צמתים נוספים אחד או יותר.
3. כאשר ספק שירותי הענן מקצה את הצומת הנדרש, הוא מצטרף לאשכול ומוכן לשרת את הפודים.
4. מתזמן Kubernetes מפיץ תרמילים ממתינים לצומת החדש. אם לאחר מכן חלק מהמודולים עדיין נשארים במצב המתנה, התהליך חוזר על עצמו וצמתים חדשים מתווספים לאשכול.

הקצאה אוטומטית של צמתי אשכולות בענן

שקול את הדברים הבאים בעת שימוש ב-CA:

• CA מבטיח שלכל הפודים באשכול יהיה מקום לפעול, ללא קשר לעומס המעבד. הוא גם מנסה להבטיח שלא יהיו צמתים מיותרים באשכול.
• CA רושם את הצורך בקנה מידה לאחר כ-30 שניות.
• ברגע שכבר אין צורך בצומת, ברירת המחדל של ה-CA היא המתנה של 10 דקות לפני קנה המידה של המערכת.
• למערכת קנה המידה האוטומטי יש את הרעיון של מרחיבים. אלו הן אסטרטגיות שונות לבחירת קבוצת צמתים שאליה יתווספו צמתים חדשים.
• השתמש באפשרות באחריות cluster-autoscaler.kubernetes.io/safe-to-evict (true). אם תתקין הרבה פודים, או אם רבים מהם מפוזרים על פני כל הצמתים, תאבד במידה רבה את היכולת להרחיב את האשכול.
• השתמש PodDisruptionBudgetsכדי למנוע מחיקת תרמילים, מה שעלול לגרום לחלקים מהאפליקציה שלך להישבר לחלוטין.

כיצד קוברנטס אוטומטי scalers מתקשרים זה עם זה

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

1. HPAs או VPAs מעדכנים העתקים של פודים או משאבים המוקצים לתרמילים קיימים.
2. אם אין מספיק צמתים עבור קנה המידה המתוכנן, ה-CA מבחין בנוכחות של תרמילים במצב המתנה.
3. ה-CA מקצה צמתים חדשים.
4. מודולים מופצים לצמתים חדשים.

מערכת הרחבת Kubernetes שיתופית

טעויות נפוצות בקנה מידה אוטומטי של Kubernetes

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

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

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

תרחיש אידיאלי - 4 דקות:

1. 30 שניות. עדכון מדדי יעד: 30-60 שניות.
2. 30 שניות. HPA בודק ערכי מדדים: 30 שניות.
3. פחות מ-2 שניות. תרמילים נוצרים ועוברים למצב המתנה: שנייה אחת.
4. פחות מ-2 שניות. CA רואה מודולים ממתינים ושולח שיחות לצמתי אספקה: שנייה אחת.
5. 3 דקות. ספק הענן מקצה צמתים. K8s ממתינים עד שהם מוכנים: עד 10 דקות (תלוי במספר גורמים).

התרחיש הגרוע ביותר (ריאליסטי יותר) - 12 דקות:

1. 30 שניות. עדכון מדדי יעד.
2. 30 שניות. HPA בודק את הערכים המטריים.
3. פחות מ-2 שניות. הפודים נוצרים ונכנסים למצב המתנה.
4. פחות מ-2 שניות. ה-CA רואה את מודולי ההמתנה ומבצע שיחות לאספקת הצמתים.
5. 10 דקות. ספק הענן מקצה צמתים. K8s מחכה עד שהם מוכנים. זמן ההמתנה תלוי במספר גורמים, כגון עיכוב של ספקים, עיכוב במערכת ההפעלה וכלי תמיכה.

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

כיצד לנהל קנה מידה ב-Kubernetes

1. Kubernetes הוא כלי לניהול משאבים ותזמור. פעולות לניהול פודים ומשאבי אשכול הן אבן דרך מרכזית בשליטה ב-Kubernetes.
2. הבן את ההיגיון של מדרגיות תרמילים תוך התחשבות ב-HPA ו-VPA.
3. יש להשתמש ב-CA רק אם יש לך הבנה טובה של הצרכים של התרמילים והמיכלים שלך.
4. כדי להגדיר בצורה אופטימלית אשכול, עליך להבין כיצד מערכות קנה מידה שונות פועלות יחד.
5. בעת הערכת זמן קנה המידה, זכור תרחישים של המקרה הגרוע והמקרה הטוב ביותר.

מקור: www.habr.com