בדיקות חיים בקוברנטס עלולות להיות מסוכנות

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

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

עמיתי סנדור שיתף לאחרונה בטוויטר את השגיאות הנפוצות ביותר בהן הוא נתקל, כולל אלה הקשורות לשימוש בבדיקות מוכנות/חיות:

מוגדר בצורה שגויה livenessProbe יכול להחמיר מצבי עומס גבוה (כיבוי כדור שלג + זמן הפעלה ארוך פוטנציאלי של מיכל/אפליקציה) ולהוביל להשלכות שליליות אחרות כגון ירידת תלות (ראה גם המאמר האחרון שלי לגבי הגבלת מספר הבקשות בשילוב K3s+ACME). זה אפילו יותר גרוע כאשר בדיקת החיים משולבת עם בדיקת בריאות, שהיא מסד נתונים חיצוני: כשל יחיד ב-DB יפעיל מחדש את כל הקונטיינרים שלך!

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

הערה: רוב הבדיקה שלהלן נכללה במקור בתיעוד המפתחים הפנימי של Zalando.

בדיקות מוכנות וחיות

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

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

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

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

דוגמה

הנה דוגמה לבדיקת מוכנות הבודקת נתיב /health באמצעות HTTP עם הגדרות ברירת מחדל (הפסקה: 10 שניות, פסק זמן: שנייה אחת, סף הצלחה: 1, סף כשל: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

המלצות

1. עבור שירותי מיקרו עם נקודת קצה HTTP (REST וכו') תמיד הגדירו בדיקת מוכנות, שבודק אם האפליקציה (פוד) מוכנה לקבל תעבורה.
2. ודא את בדיקת המוכנות מכסה את הזמינות של יציאת שרת האינטרנט בפועל:
   • שימוש ביציאות למטרות ניהול, הנקראות "אדמין" או "ניהול" (לדוגמה, 9090), עבור readinessProbe, ודא שנקודת הקצה מחזירה אישור רק אם יציאת ה-HTTP הראשית (כמו 8080) מוכנה לקבל תעבורה*;

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

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

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

4. השתמש httpGet לבדיקות מוכנות דרך נקודות קצה טיפוסיות לבדיקת בריאות (לדוגמה, /health).
5. הבן את פרמטרי המחדל המוגדרים כברירת מחדל (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • אפשרויות ברירת המחדל אומרות שהפוד יהפוך לא מוכן לאחר כ-30 שניות (3 בדיקות שפיות כושלות).
6. השתמש ביציאה נפרדת עבור "admin" או "ניהול" אם מחסנית הטכנולוגיה (למשל Java/Spring) מאפשרת זאת, כדי להפריד בין ניהול בריאות ומדדים לתעבורה רגילה:
   • אבל אל תשכח את נקודה 2.
7. במידת הצורך, ניתן להשתמש בבדיקת המוכנות לחימום/טעינת המטמון ולהחזיר קוד סטטוס 503 עד שהמיכל יתחמם:
   • אני גם ממליץ לך לקרוא את הצ'ק החדש startupProbe, הופיע בגרסה 1.16 (כתבנו על זה ברוסית כאן - משוער. תרגום).

אזהרות

1. אל תסתמך על תלות חיצונית (כגון מחסני נתונים) בעת הפעלת מבחני מוכנות/חיוניות - זה יכול להוביל לכשלים מדורגים:
   • כדוגמה, ניקח שירות REST stateful עם 10 פודים בהתאם למסד נתונים אחד של Postgres: כאשר הבדיקה תלויה בחיבור עובד ל-DB, כל 10 הפודים עלולים להיכשל אם יש השהייה בצד הרשת/DB - בדרך כלל זה הכל מסתיים יותר גרוע ממה שהיה יכול;
   • שים לב ש-Spring Data בודק את חיבור מסד הנתונים כברירת מחדל*;

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

   • "חיצוני" במובן זה יכול להתכוון גם לתרמילים אחרים של אותו יישום, כלומר, באופן אידיאלי הבדיקה לא צריכה להיות תלויה במצב של תרמילים אחרים מאותו אשכול כדי למנוע קריסות מדורגות:
     • התוצאות עשויות להשתנות עבור יישומים עם מצב מבוזר (לדוגמה, שמירה במטמון בזיכרון בתרמילים).
2. אל תשתמש בבדיקה חיה עבור תרמילים (יוצאים מן הכלל הם מקרים שבהם הם באמת נחוצים ואתה מודע לחלוטין לפרטים וההשלכות של השימוש בהם):
   • בדיקה חיה יכולה לעזור לשחזר מכולות תלויות, אבל מכיוון שיש לך שליטה מלאה על היישום שלך, דברים כמו תהליכים תלויים ומבוי סתום לא אמורים לקרות באופן אידיאלי: האלטרנטיבה הטובה ביותר היא לקרוס בכוונה את היישום ולהחזיר אותו למצב יציב קודם;
   • בדיקת חיים כושלת תגרום למכולה להפעיל מחדש, ובכך עלולה להחמיר את ההשלכות של שגיאות הקשורות לטעינה: הפעלה מחדש של המיכל תגרום להשבתה (לפחות למשך ההפעלה של האפליקציה, למשל 30 שניות מוזרות), ויגרום לשגיאות חדשות , הגדלת העומס על מכולות אחרות והגדלת הסבירות לכשל שלהן וכו';
   • בדיקות חיים בשילוב עם תלות חיצונית הם השילוב הגרוע ביותר האפשרי, המאיימים בכשלים מדורגים: עיכוב קל בצד מסד הנתונים יוביל להפעלה מחדש של כל הקונטיינרים שלך!
3. פרמטרים של בדיקות חיוניות ומוכנות חייב להיות שונה:
   • אתה יכול להשתמש בבדיקה חיה עם אותה בדיקת בריאות, אבל סף תגובה גבוה יותר (failureThreshold), לדוגמה, הקצה את הסטטוס לא מוכן לאחר 3 ניסיונות וקחו בחשבון שבדיקת החיים נכשלה לאחר 10 ניסיונות;
4. אל תשתמש בבדיקות Exec, מכיוון שהם קשורים לבעיות ידועות המובילות להופעת תהליכי זומבים:
   • פרטים: ראה מצגת על ידי מומחי Datadog.

תקציר

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

חומרים נוספים בנושא

• Kubernetes docs: הגדר בדיקות חיוניות ומוכנות;
• בדיקות חיוניות ומוכנות של Kubernetes שנבדקו מחדש: כיצד להימנע מלירות לעצמך ברגל השנייה;
• הפסקת NRE Labs לאחר המוות (הוא גם מדבר על livenessProbe).

עדכון מס' 1 מ-2019-09-29

אודות מיכלי init להעברת מסד נתונים: נוספה הערת שוליים.

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

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

עדכון מס' 2 מ-2019-09-29

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

נ.ב מהמתרגם

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

• «Kubernetes: Pod Life";
• «7 שיטות עבודה מומלצות לשימוש בקונטיינרים לפי גוגל";
• «7 עקרונות לעיצוב יישומים מבוססי מיכל".

מקור: www.habr.com