ניטור משאבי אשכול Kubernetes

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

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

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

ולמרות שהאשכול צרך מעט יחסית מעבד (8%) וזיכרון RAM (40%), היו לנו כל הזמן בעיות עם תרמילים שהוקדמו כאשר הם ניסו להקצות יותר זיכרון ממה שהיה זמין בצומת. אז היה לנו רק לוח מחוונים אחד לניטור משאבי Kubernetes. ככה:

לוח המחוונים של Grafana עם מדדי cAdvisor בלבד

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

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

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

יש לי כמעט כל אשכולות Kubernetes מנוטר רק עם יצואן צמתים и מדדי מצב קיוב. Node Exporter מספק נתונים סטטיסטיים על שימוש ב-I/O ודיסק, במעבד וב-RAM, בעוד ש-Kube State Metrics מציג מדדי אובייקט Kubernetes כגון בקשות ומגבלות מעבד ומשאבי זיכרון.

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

לוח המחוונים של Kube Eagle

הצלחנו לפתור בעיות רבות במשאבים ולחסוך בציוד:

1. חלק מהמפתחים לא ידעו כמה משאבים דרושים מיקרו-שירותים (או פשוט לא הפריעו). לא הייתה לנו דרך למצוא בקשות שגויות למשאבים - בשביל זה אנחנו צריכים לדעת צריכה פלוס בקשות ומגבלות. כעת הם רואים מדדי Prometheus, עוקבים אחר השימוש בפועל ומתאים בקשות ומגבלות.
2. יישומי JVM לוקחים כמה שיותר RAM הם יכולים להתמודד. אספן האשפה משחרר זיכרון רק כאשר נעשה שימוש ביותר מ-75%. ומכיוון שלרוב השירותים יש זיכרון מתפרץ, הוא תמיד היה תפוס על ידי ה-JVM. לכן, כל שירותי Java הללו אכלו הרבה יותר זיכרון RAM מהצפוי.
3. חלק מהיישומים ביקשו יותר מדי זיכרון, ומתזמן Kubernetes לא נתן את הצמתים הללו ליישומים אחרים, למרות שלמעשה הם היו חופשיים יותר מצמתים אחרים. מפתח אחד הוסיף בטעות ספרה נוספת בבקשה ותפס חתיכת זיכרון RAM גדולה: 20 GB במקום 2. אף אחד לא שם לב. לאפליקציה היו 3 העתקים, כך שעד 3 צמתים הושפעו.
4. הצגנו מגבלות משאבים, תזמנו מחדש פודים עם הבקשות הנכונות וקיבלנו איזון אידיאלי של שימוש בחומרה בכל הצמתים. כמה צמתים היו יכולים להיסגר לגמרי. ואז ראינו שהיו לנו את המכונות הלא נכונות (מכוונות מעבד, לא מכוונות זיכרון). שינינו את הסוג ומחקנו עוד כמה צמתים.

תוצאות של

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

מקור: www.habr.com