כיצד סדרי עדיפויות של תרמילים ב-Kubernetes גרמו להשבתה במעבדות Grafana

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

ביום שישי, 19 ביולי, שירות Hosted Prometheus ב-Grafana Cloud הפסיק לפעול למשך כ-30 דקות. אני מתנצל בפני כל הלקוחות שהושפעו מההפסקה. התפקיד שלנו הוא לספק את כלי הניטור הדרושים לך, ואנחנו מבינים שאי זמינותם יכולה להקשות על חייך. אנו מתייחסים לאירוע הזה ברצינות רבה. הערה זו מסבירה מה קרה, איך הגבנו ומה אנחנו עושים כדי להבטיח שזה לא יקרה שוב.

פרהיסטוריה

שירות Grafana Cloud Hosted Prometheus מבוסס על קלף מוח - פרויקט CNCF ליצירת שירות פרומתאוס הניתן להרחבה אופקית, זמין במיוחד, מרובה דיירים. ארכיטקטורת Cortex מורכבת מקבוצה של מיקרו-שירותים בודדים, שכל אחד מהם מבצע את תפקידו: שכפול, אחסון, שאילתות וכו'. Cortex נמצאת בפיתוח פעיל ומוסיפה כל הזמן תכונות חדשות ומשפרת ביצועים. אנו פורסים באופן קבוע מהדורות חדשות של Cortex לאשכולות כדי שלקוחות יוכלו לנצל את התכונות הללו - למרבה המזל, ניתן לעדכן את Cortex ללא זמן השבתה.

עבור עדכונים חלקים, שירות Ingester Cortex דורש העתק נוסף של Ingester במהלך תהליך העדכון. (הערה. תרגום: אינגסטר - המרכיב הבסיסי של הקורטקס. תפקידו הוא לאסוף זרם קבוע של דגימות, לקבץ אותם לנתחי פרומתאוס ולאחסן אותם במסד נתונים כמו DynamoDB, BigTable או Cassandra.) זה מאפשר לאינגסטרים ישנים להעביר נתונים נוכחיים לאינגסטרים חדשים. ראוי לציין כי אינגסטרים דורשים משאבים. כדי שהם יעבדו, אתה צריך שיהיה לך 4 ליבות ו-15 GB זיכרון לכל פוד, כלומר. 25% מכוח העיבוד והזיכרון של מכונת הבסיס במקרה של אשכולות Kubernetes שלנו. באופן כללי, בדרך כלל יש לנו הרבה יותר משאבים לא מנוצלים באשכול מאשר 4 ליבות ו-15 ג'יגה-בייט של זיכרון, כך שנוכל בקלות לסובב את הגורמים הנוספים הללו במהלך שדרוגים.

עם זאת, לעתים קרובות קורה שבמהלך פעולה רגילה לאף אחת מהמכונות אין 25% משאבים לא בשימוש. כן, אנחנו אפילו לא מתאמצים: מעבד וזיכרון תמיד יהיו שימושיים עבור תהליכים אחרים. כדי לפתור בעיה זו, החלטנו להשתמש קוברנטס Pod Priorities. הרעיון הוא לתת לאינגסטרס עדיפות גבוהה יותר משירותי מיקרו אחרים (חסרי מדינה). כאשר אנו צריכים להפעיל אינגסטר נוסף (N+1), אנו מחליפים באופן זמני תרמילים אחרים, קטנים יותר. תרמילים אלה מועברים למשאבים פנויים במכונות אחרות, ומשאירים "חור" גדול מספיק כדי להפעיל אינגסטר נוסף.

ביום חמישי, 18 ביולי, השקנו ארבע רמות עדיפות חדשות לאשכולות שלנו: קריטי, גבוה, בינוני и נמוך. הם נבדקו על אשכול פנימי ללא תעבורת לקוחות במשך כשבוע. כברירת מחדל, תרמילים ללא עדיפות מוגדרת התקבלו בינוני בראש סדר העדיפויות, הכיתה נקבעה עבור Ingesters עם גבוה עדיפות. קריטי היה שמור לניטור (Prometheus, Alertmanager, node-exporter, kube-state-metrics וכו'). התצורה שלנו פתוחה, ואתה יכול לראות את יחסי הציבור כאן.

תאונה

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

לאשכול Kubernetes לא היו מספיק משאבים לאשכול ה-Cortex החדש, ואשכול Cortex הייצור הקיים לא עודכן (Ingesters נותרו ללא высокого עדיפות). מאז האינגסטרים של האשכול החדש כברירת מחדל בינוני priority, והפודים הקיימים בייצור עבדו ללא עדיפות כלל, ה-Ingesters של האשכול החדש החליפו את ה-Ingesters מאשכול הייצור הקיים של Cortex.

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

בולטים הם מצביים ומאחסנים נתונים עבור 12 השעות הקודמות. זה מאפשר לנו לדחוס אותם בצורה יעילה יותר לפני כתיבתם לאחסון לטווח ארוך. כדי להשיג זאת, Cortex מחלק נתונים על פני סדרות באמצעות טבלת Hash Distributed (DHT) ומשכפלת כל סדרה על פני שלושה Ingesters באמצעות עקביות מניין בסגנון Dynamo. Cortex לא כותב נתונים לאינגסטרים מושבתים. לפיכך, כאשר מספר רב של אינגסטרים עוזבים את ה-DHT, קורטקס אינו יכול לספק שכפול מספק של הערכים, והם קורסים.

איתור ותיקון

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

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

10 דקות נוספות הושקעו באבחון ותיקון שגיאות מחוץ לזיכרון (OOM) מפרוקסי הפוכות של אימות הממוקמים מול Cortex. שגיאות OOM נגרמו על ידי עלייה של פי עשרה ב-QPS (לדעתנו עקב בקשות אגרסיביות מדי משרתי Prometheus של הלקוח).

תופעות

זמן ההשבתה הכולל היה 26 דקות. שום נתונים לא אבדו. שולטים טענו בהצלחה את כל הנתונים בזיכרון לאחסון לטווח ארוך. במהלך הכיבוי, שרתי Prometheus של הלקוח שנמחקו במאגר (מְרוּחָק) הקלטות באמצעות ממשק API חדש מבוסס על WAL (נכתב על ידי קאלום סטיין מ-Grafana Labs) וחזר על הכתיבה הכושלת לאחר ההתרסקות.

פעולות כתיבת אשכול ייצור

ממצאים

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

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

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

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

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

נ.ב מהמתרגם

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

• «קנה מידה אוטומטי וניהול משאבים ב-Kubernetes (סקירה כללית ודוח וידאו)";
• «Kubernetes adventure Dailymotion: יצירת תשתית בעננים + מקומית";
• «מעבר טינדר ל-Kubernetes";
• «סיפורי הצלחה של Kubernetes בהפקה. חלק 10: Reddit".

מקור: www.habr.com