מגבלות מעבד ומצערת אגרסיבית ב-Kubernetes

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

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

TL; DR:
אנו ממליצים בחום להשבית את מגבלות ה-CPU ב-Kubernetes (או להשבית מכסות CFS ב-Kubelet) אם אתה משתמש בגרסה של ליבת לינוקס עם באג מכסת CFS. בליבה имеется רציני ו ידוע היטב באג שמוביל למצערת ועיכובים מוגזמים.

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

סיכום המאמר:

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

כמה מילים על קונטיינרים ו-Kubernetes

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

מיכלים

בעבר, היינו צריכים ליצור חפצים כמו Java JARs/WARs, Python Eggs או קובצי הפעלה כדי לרוץ על שרתים. עם זאת, כדי לגרום להם לתפקד, היה צריך לעשות עבודה נוספת: התקנת סביבת הריצה (Java/Python), הצבת הקבצים הדרושים במקומות הנכונים, הבטחת תאימות לגרסה ספציפית של מערכת ההפעלה וכו'. במילים אחרות, היה צורך להקדיש תשומת לב קפדנית לניהול תצורה (שהיה לעתים קרובות מקור למחלוקת בין מפתחים ומנהלי מערכת).

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

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

קוברנט

כפי שצוין קודם לכן, Kubernetes הוא מתזמר מכולות. זה עובד ככה: אתה נותן לו מאגר של מכונות, ואז אומר: "היי, Kubernetes, בואו נשיק עשרה מופעים של הקונטיינר שלי עם 2 מעבדים ו-3 GB של זיכרון כל אחד, ונמשיך לפעול!" Kubernetes ידאג לכל השאר. הוא ימצא קיבולת פנויה, ישיק קונטיינרים ויפעיל אותם מחדש במידת הצורך, יוציא עדכון בעת ​​שינוי גרסאות וכו'. בעיקרו של דבר, Kubernetes מאפשר לך לפשט את רכיב החומרה והופכת מגוון רחב של מערכות למתאימים לפריסה והרצה של יישומים.

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

מהן בקשות ומגבלות ב-Kubernetes

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

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

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

כיצד מיושמים בקשות ומגבלות ב-Kubernetes

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

בקשת מעבד

כיצד מיושמת בקשת CPU

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

K8s משתמש במנגנון קבוצת בקרה (cgroups) כדי לשלוט בהקצאת משאבים (זיכרון ומעבד). זמין עבורו מודל היררכי: הילד יורש את גבולות קבוצת ההורים. פרטי ההפצה מאוחסנים במערכת קבצים וירטואלית (/sys/fs/cgroup). במקרה של מעבד זהו /sys/fs/cgroup/cpu,cpuacct/*.

K8s משתמש בקובץ cpu.share להקצאת משאבי מעבד. במקרה שלנו, ה-cgroup השורש מקבל 4096 שיתופים של משאבי CPU - 100% מהספק המעבד הזמין (ליבה אחת = 1; זהו ערך קבוע). קבוצת השורש מחלקת משאבים באופן פרופורציונלי בהתאם למניות הצאצאים הרשומים בה cpu.share, והם, בתורם, עושים אותו דבר עם צאצאיהם וכו'. בצומת Kubernetes טיפוסי, ל-cgroup השורש יש שלושה ילדים: system.slice, user.slice и kubepods. שתי קבוצות המשנה הראשונות משמשות לחלוקת משאבים בין עומסי מערכת קריטיים ותוכניות משתמש מחוץ ל-K8s. אחרון - kubepods - נוצר על ידי Kubernetes כדי להפיץ משאבים בין תרמילים.

התרשים שלמעלה מראה שתת-הקבוצה הראשונה והשנייה קיבלו כל אחת 1024 מניות, כאשר תת-קבוצת kuberpod הוקצתה 4096 מניות איך זה אפשרי: אחרי הכל, לקבוצת השורש יש גישה בלבד 4096 מניות, וסכום המניות של צאצאיה עולה באופן משמעותי על מספר זה (6144)? הנקודה היא שהערך הגיוני, ולכן מתזמן לינוקס (CFS) משתמש בו כדי להקצות באופן פרופורציונלי משאבי CPU. במקרה שלנו, שתי הקבוצות הראשונות מקבלים 680 מניות ריאליות (16,6% מ-4096), ו-kubepod מקבל את הנותרים 2736 מניות במקרה של השבתה, שתי הקבוצות הראשונות לא ישתמשו במשאבים שהוקצו.

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

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

מגבלת מעבד

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

K8s מעורב מנגנון מכסת CFS ליישם מגבלות. ההגדרות שלהם מצוינות בקבצים cfs_period_us и cfs_quota_us בספריית cgroup (הקובץ נמצא גם שם cpu.share).

В отличие от cpu.share, על בסיס המכסה תקופת זמן, ולא בכוח המעבד הזמין. cfs_period_us מציין את משך התקופה (עידן) - זה תמיד 100000 מיקרומטר (100 אלפיות השנייה). יש אפשרות לשנות את הערך הזה ב-K8s, אבל הוא זמין רק באלפא לעת עתה. המתזמן משתמש בעידן כדי להפעיל מחדש מכסות בשימוש. קובץ שני cfs_quota_us, מציין את הזמן הזמין (מכסה) בכל תקופה. שימו לב שהוא מצוין גם במיקרו-שניות. המכסה עשויה לחרוג מאורך העידן; במילים אחרות, הוא עשוי להיות גדול מ-100 אלפיות השנייה.

בואו נסתכל על שני תרחישים על מכונות 16 ליבות (סוג המחשב הנפוץ ביותר שיש לנו באומיו):

תרחיש 1: 2 שרשורים ומגבלה של 200 אלפיות השנייה. אין מצערת

תרחיש 2: 10 שרשורים ומגבלה של 200 אלפיות השנייה. המצערת מתחילה לאחר 20 אלפיות השנייה, הגישה למשאבי המעבד חוזרת לאחר 80 אלפיות השנייה

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

וכאן מתחיל הכיף. כפי שהוזכר לעיל, המכסה הזמינה היא 200 אלפיות השנייה. אם אתה עובד במקביל עשר חוטים במכונה בעלת 12 ליבות (ראה איור לתרחיש 2), בעוד שכל שאר התרמילים אינם פעילים, המכסה תמוצה תוך 20 אלפיות השנייה בלבד (מכיוון 10*20 אלפיות השנייה = 200 אלפיות השנייה), וכל החוטים של התרמיל הזה יתלו » (מַצעֶרֶת) למשך 80 האלק' הבאות. האמור כבר באג מתזמן, עקב כך מתרחשת צרור יתר והמיכל לא יכול אפילו לעמוד במכסה הקיימת.

כיצד להעריך מצערת בתרמילים?

פשוט היכנס ל-pod ובצע cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - המספר הכולל של תקופות מתזמן;
• nr_throttled - מספר תקופות מצערות בהרכב nr_periods;
• throttled_time - זמן מצטבר מצטבר בננו-שניות.

מה באמת קורה?

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

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

החלטה והשלכות

הכל פשוט כאן. נטשנו את מגבלות המעבד והתחלנו לעדכן את ליבת מערכת ההפעלה באשכולות לגרסה העדכנית ביותר, שבה תוקן הבאג. מספר השגיאות (HTTP 5xx) בשירותים שלנו ירד באופן משמעותי באופן מיידי:

שגיאות HTTP 5xx

שגיאות HTTP 5xx עבור שירות קריטי אחד

זמן תגובה p95

זמן אחזור בקשת שירות קריטי, אחוזון 95

עלויות תפעול

מספר שעות המופע שהושקע

מהו המלכוד?

כפי שנאמר בתחילת המאמר:

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

הנה המלכוד. מיכל רשלני אחד יכול לאכול את כל משאבי המעבד הזמינים במכונה. אם יש לך ערימת יישומים חכמה (לדוגמה, JVM, Go, Node VM מוגדרים כראוי), אז זו לא בעיה: אתה יכול לעבוד בתנאים כאלה במשך זמן רב. אבל אם היישומים עברו אופטימיזציה גרועה או לא עברו אופטימיזציה כלל (FROM java:latest), המצב עלול לצאת משליטה. ב-Omio יש לנו Dockerfiles אוטומטיים עם הגדרות ברירת מחדל נאותות עבור מחסנית השפה העיקרית, כך שבעיה זו לא הייתה קיימת.

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

תזכור

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

• kernel.org → מתזמן CFS;
• kernel.org → בקרת רוחב פס של CFS;
• הבנת תזמון מיכל לינוקס;
• כל מה שאתה צריך לדעת על מיכלי לינוקס, חלק א': קבוצות בקרה של לינוקס ובידוד תהליכים;
• סיפורי כישלון של Kubernetes - חפש את "הצערת המעבד".

דיווח על באגים של Kubernetes:

• #51135: הימנע מהגדרת מגבלות מעבד עבור תרמילים מובטחים;
• #67577: מכסות CFS יכולות להוביל למצערת מיותרת;
• CFS אגרסיבי מדי.

האם נתקלת בבעיות דומות בתרגול שלך או שיש לך ניסיון הקשור למצערת בסביבות ייצור במכולות? שתפו את הסיפור שלכם בתגובות!

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «קנה מידה אוטומטי וניהול משאבים ב-Kubernetes (סקירה כללית ודוח וידאו)";
• «כיצד פועל מנהל המעבד ב-Kubernetes";
• «מה קורה ב-Kubernetes כשאתה מפעיל את kubectl run? חלק 2".

מקור: www.habr.com