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

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

שלוש שאלות שונות

Readiness בודקת האם מתאים להעביר ל־Pod תעבורה דרך השירות. Liveness מיועדת לזהות מצב שבו יש הצדקה להפעלה מחדש. Startup נותנת לתהליך את זמן העלייה שהוא צריך לפני שהבדיקות האחרות מתחילות להשפיע. אלה תפקידים שונים, כפי שמפורט בתיעוד Kubernetes.

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

מתי לבדוק תלות חיצונית

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

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

הפרמטרים הם תקציב זמן

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  periodSeconds: 5
  failureThreshold: 24
readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

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

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

מוכנות היא גם חלק מהכיבוי

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

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

תרגיל כשל לפני הפריסה

הריצו עלייה איטית, נתקו את ה־DB והעמיסו CPU. בכל מצב בדקו אילו probes נכשלים, האם הייתה הפעלה מחדש ומה המשתמש חווה. אם האוטומציה עושה משהו שלא רציתם, שנו את הגדרת המצב ולא רק את ה־timeout.

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