נקודות קצה של Health check: היכן כשל שובר את כל השירות
כשל של צומת אחד לעיתים רחוקות נשאר מקומי. מאזן העומסים ממשיך לשלוח תעבורה למופע שכבר אינו יכול לשרת בקשות — החיבורים מצטברים, מאגר התהליכים מתרוקן, ותוך מספר דקות כל השירות קורס.
זהו כשל מדורג קלאסי: נקודות קצה של health check либо חסרות, либо מחזירות "בסדר" ללא תלות במצב האמיתי של האפליקציה.
הקצה ההפוך אינו טוב יותר. אם בדיקת liveness בודקת תלות חיצונית — מסד נתונים, תור, API של צד שלישי — אזי בעת אי-זמינות זמנית של מסד הנתונים הפלטפורמה תתחיל להפעיל מחדש מופעים בריאים.
אנו מקבלים הפעלות מחדש שגויות: השירות מאבד חיבורים, מחמם את המטמון מחדש, והסיבה לתקלה לא נעלמה לשום מקום. הפרדת הבדיקות מסירה את הבלבול הזה: liveness אחראית רק ל"התהליך חי ולא קפא", readiness — ל"מוכן לקבל תעבורה ממש עכשיו".
בדיקת readiness היא הנקודה שבה התעבורה נחתכת לפני שהמשתמש רואה שגיאה. כל עוד המופע מחמם את המטמון, ממתין למיגרציה או מאבד קשר עם מסד הנתונים, הוא מדווח בכנות "לא מוכן" — מאזן העומסים מוציא אותו מהרוטציה, והבקשות עוברות לצמתים פעילים. ללא מנגנון זה, דעיכה של פוד אחד הופכת להשבתה של השירות עבור כולם.
מחיר הטעות ניתן למדידה: עם בדיקות תקינות זמן ההתאוששות לאחר כשל של צומת — שניות, בלעדיהן — דקות, עד שהתורן יוציא את המופע ידנית. בהמשך נבחן כיצד זה נסגר ברמת התצורה.
מה נותן health check מוגדר נכון
זמן ההתאוששות יורד מעשרות דקות לשניות
בדיקת liveness מפסיקה להיות פורמליות: היא בודקת לא "האם התהליך חי", אלא את היכולת של השירות להגיב לבקשה אמיתית — זמינות מאגר החיבורים למסד הנתונים, מצב התורים הפנימיים, מוכנות המטמון.
כאשר הקונטיינר נתקע במצב מנוון, האורקסטרטור מקבל אות אמיתי ומפעיל אותו מחדש מיד, ולא כעבור חצי שעה לפי התראה מהתורן. בפועל זה ההבדל בין התאוששות תוך 20-40 שניות לבין טיפול ידני של 15-30 דקות.
הפעלות מחדש שגויות נעלמות מלוח התורנויות
בדיקת readiness עם ספים נכונים (השהיית התחלה, מספר כשלים מותרים, תקופת הסקר) מפרידה בין "השירות עוד עולה" לבין "השירות שבור".
בלעדיה אופיינית התמונה הבאה: האפליקציה עולה יותר מהזמן הקצוב, האורקסטרטור הורג אותה באמצע האתחול, המחזור חוזר על עצמו — והשירות לא נכנס לפעולה כלל. תצורה נכונה מסירה את סוג התקלות הזה לחלוטין, ואיתה — הפעלות מחדש בלילה והתראות שווא של הניטור.
ניתוב התעבורה מפסיק לשלוח בקשות לפודים מתים
כל עוד readiness לא אושרה, מאזן העומסים לא מפנה תעבורה למופע — ולהפך, בעת כשל בבדיקה הוא מוציא אותו מהרוטציה עד להפעלה מחדש. זה סוגר כשלים שאחרת נראים כשגיאות אקראיות אצל חלק מהמשתמשים: בקשות מגיעות לקונטיינר שכבר לא משרת חיבורים. זמינות השירות מפסיקה להיות תלויה בשאלה אם מישהו הספיק להסיר את הצומת ידנית.
הפרדת הבדיקות נותנת נסיגה מבוקרת
כאשר liveness, readiness ובדיקת ההתחלה מוגדרות בנפרד, הפעלה מחדש מפסיקה להיות התגובה היחידה לכל תקלה. אובדן זמני של מסד הנתונים מפיל את readiness, אך לא הורג את הקונטיינר — השירות ממתין שהתקלה תחלוף וחוזר לרוטציה בעצמו. זה מפחית את העומס על התשתית ושומר על מצב שהיה הולך לאיבוד בהפעלה מחדש קשיחה.
גישות לבדיקת מצב: השוואת מצבים
בדיקות מתחלקות לשני רבדים: בדיקות פנימיות של האורקסטרטור, אשר מחליטות האם להפעיל מחדש את הקונטיינר והאם להעביר אליו תעבורה, וניטור חיצוני, אשר בוחן את השירות בעיני המשתמש.
אין לערבב ביניהם: בדיקה אשר מפעילה את מסד הנתונים או API חיצוני, בעת כשל של תלות תפיל פוד בריא, וניטור אשר דופק רק בשורש האתר, לא יראה שהיישום מחזיר שגיאות במחצית מהתרחישים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בדיקת Liveness | התהליך עלול להיתקע: דדלוק, לולאה אינסופית, מיצוי מאגר התהליכים | עונה רק "האם התהליך חי". לא בודקת תלויות — אחרת הפעלה מחדש מדורגת של כל השירות בעת כשל במסד הנתונים |
| בדיקת Readiness | יש צורך להסיר את הפוד מאיזון העומס בזמן התחממות, מיגרציות או עומס יתר | לא מפעילה מחדש את הקונטיינר. בעת שגיאה בלוגיקה קל לקבל פוד שתלוי לנצח מחוץ לתעבורה |
| בדיקת Startup | התחלה ארוכה: חימום מטמון, טעינת מודלים, החלת מיגרציות | פועלת פעם אחת בחיי הקונטיינר. אם ההתחלה אינה יציבה בזמן — יהיה צורך להעלות את הסף עם מרווח |
| ניטור חיצוני | בדיקת תרחיש מקצה לקצה: כניסה, תשלום, מסירת נתונים מהאחסון | לא מנהל את האורקסטרטור. התראות שווא בעת קפיצות רשת, נדרש מרווח בתדירות הסקר |
בפועל משלבים בין המצבים: startup מכסה הפעלה ארוכה, readiness מווסתת תעבורה, liveness תופסת תקיעות, וניטור חיצוני מאשר שהשירות עובד עבור הלקוח. הפרדת נקודות קצה היא תנאי הכרחי: /healthz עבור התהליך ו-/ready עבור מוכנות לקבל בקשות לא צריכים לפנות לאותן תלויות.
המגבלה העיקרית של כל מצב — מחיר ההתראה השווא. בדיקת liveness קפדנית מדי הופכת ירידה קצרת טווח לסערת הפעלות מחדש, רפויה מדי — משאירה פוד לא תקין ברוטציה. לכן ספים, השהיות ומספר החזרות נבחרים בהתאם לפרופיל העומס האמיתי, ולא לפי ברירת מחדל.
שלבי הטמעת נקודות קצה לבדיקת תקינות
הטמעת נקודות קצה לבדיקת תקינות מתחילה בביקורת של מה שכבר קיים: אילו בדיקות עונות לבקשות, מה בדיוק הן בודקות וכיצד מאזן העומס מגיב אליהן.
לעיתים קרובות מתברר שנקודת הקצה מחזירה "תקין" תמיד — גם כאשר מסד הנתונים אינו זמין או התור עמוס מדי, היא עדיין מחזירה תגובה מוצלחת, והתעבורה ממשיכה לזרום למופע השבור.
בשלב זה אנו מתעדים את התלויות של השירות ומסכמים איזו מהן, כאשר היא נכשלת, צריכה להוציא את המופע מהסבב, ואיזו רק צריכה לאותת.
- ביקורת הבדיקות הנוכחיות. אוספים רשימה של נקודות קצה, בוחנים מה הן בודקות, כיצד מוגדרים המרווחים והספים בצד התזמור, ואילו כשלים כבר גרמו להשבתות.
- תכנון סכמת הבדיקות. מפרידים בין liveness ל-readiness: הראשונה עונה על השאלה "האם התהליך חי", השנייה — "האם הוא מוכן לקבל תעבורה". בנפרד מתכננים בדיקת אתחול עבור שירותים עם אתחול ארוך, כדי שהבדיקה לא תהרוג את המופע לפני הזמן.
- הגדרת הבדיקות. מגדירים מרווחים, פסקי זמן, מספר ניסיונות חוזרים עד למעבר למצב כשל וספים שבהם המופע מו�וצא מהסבב. את הבדיקות עושים זולות — בלי שאילתות כבדות למסד הנתונים, כדי שהבדיקה עצמה לא תיצור עומס.
- בדיקת תרחישי כשל. מפילים בכוונה תלות, ממלאים את התור, מבטלים גישה לאחסון — ובוחנים כיצד המערכת מתנהגת: האם התעבורה עוזבת את המופע הבעייתי, האם הוא מתאושש לאחר חזרת התלות, והאם אין התראות שווא בעת כשלים קצרים.
- תיעוד. מעבירים את סכמת הבדיקות, ערכי הפרמטרים והלוגיקה של התגובה לכשל — כדי שהמהנדס התורן יבין מדוע המופע יצא מהסבב, ויוכל להבחין בין תקלה אמיתית להתראת שווא.
לאחר ההטמעה, כשל של מופע בודד מפסיק להיות מורגש למשתמש: התעבורה עוברת לצמתים בריאים, וההתאוששות מתרחשת ללא התערבות ידנית. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
ארטיפקטים ותצורות שאתם מקבלים
בסיום העבודה אתם מקבלים לא "ניטור מוגדר", אלא סט ארטיפקטים ניתן לשחזור: תצורות, תרשימים, מדיניות ותקנות שלפיהם המערכת פועלת ומועברת לצוות שלכם ללא הסברים בעל פה. להלן מה שנשאר בפועל במאגר ובמסמכי התיעוד.
- תצורת בדיקות — מניפסטים עם בדיקות liveness, readiness ו-startup: נתיב נקודת הקצה, מרווחים, ספי כשל, השהיית ההפעלה הראשונה. בנפרד לכל שירות, עם הערות מדוע נבחרו ערכים אלה.
- תרשים תלויות — מפה של איזה שירות תלוי במי וכיצד הדבר בא לידי ביטוי ב-readiness: בדיקת מסד נתונים, תור, ממשקי API חיצוניים. ניתן לראות מה בדיוק חוסם קבלת תעבורה בעת תקלה.
- מדיניות גישה — כללים מי ומאיפה יכול לפנות לנקודות הקצה: רשת פנימית, מתזמר, מערכות ניטור. גישה ציבורית סגורה, הבדיקות אינן חושפות את מצב השירות כלפי חוץ.
- תקנות תגובה — מה משמעות כל סטטוס בדיקה, באיזה תרחיש מתבצע אתחול מחדש, ובאיזה — הסרה מאיזון העומס, למי נשלחת התראה ובאיזה פרק זמן.
- הוראות תפעול — כיצד להוסיף בדיקה חדשה, לשנות סף, לבצע rollback לתצורה. עם דוגמאות לתיקונים והתוצאה הצפויה.
- סט תרחישי בדיקה — כיצד לשחזר תקלה: לכבות תלות, להאט תגובה, להפיל תהליך. בדיקה שהבדיקות מגיבות כפי שתוכנן.
- דוח הטמעה — אילו שירותים מכוסים, אילו ספים הוגדרו, מה נותר מחוץ למסגרת ומדוע.
התצורות נמצאות במערכת בקרת גרסאות לצד קוד השירותים — שינויים עוברים סקירה ונכנסים להיסטוריה. התרשימים והתקנות — בתיעוד הפרויקט, בפורמט שנקרא ללא גישה לתשתית. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית, אילו ארטיפקטים נדרשים בדיוק לכם.
מקרה בוחן: כיצד נקודות קצה של health check צמצמו השבתות
הפרויקט — שירות בעומס גבוה עם תור משימות רקע: מספר אינסטנסים מאחורי מאזן עומסים, פריסה מספר פעמים בשבוע.
לפני הטמעת הבדיקות, הקונטיינרים הופעלו מחדש לפי סימן חיצוני "התהליך חי", למרות שהיישום כבר לא הגיב: מאגר החיבורים לבסיס הנתונים מוצה, מעבדי הרקע נעצרו, אך התהליך לא קרס. מאזן העומסים המשיך לשלוח תעבורה לאינסטנס לא תקין, הלקוחות קיבלו שגיאות, והתורן נודע על התקלה מפניות. כל אירוע כזה נמשך עשרות דקות של אבחון ידני.
מה שינו
הפרידו בין שני סוגי בדיקות לפי משמעות. Liveness עונה רק על השאלה "האם התהליך קפא לחלוטין" — אם כן, הפלטפורמה מפעילה מחדש את הקונטיינר. Readiness מתאר מוכנות לקבל תעבורה: זמינות בסיס הנתונים, מילוי מאגר החיבורים, מצב מעבדי הרקע.
כל עוד readiness לא עובר, האינסטנס מוצא מאיזון העומסים, אך לא נהרג — זה עקרוני, אחרת הפעלה מחדש בזמן חימום יוצרת מפולת.
בנפרד הגדירו בדיקת התחלה עם חלון מוגדל: היישום מחמם מטמונים ומקים חיבורים לזמן ארוך יותר מהאינטרוול הרגיל, ובלעדי זה הפלטפורמה הרגה את הקונטיינר לפני המוכנות. הספים נבחרו כך שכשל בודד של תלות לא מוציא את האינסטנס מכלל פעולה, בעוד שהידרדרות מתמשכת — כן.
מה היה בסוף
Kubernetes הפסיק להפעיל מחדש קונטיינרים בריאים והחל להוציא מאיזון העומסים רק כאלה שבאמת לא מוכנים. שיעור הבקשות שהגיעו לאינסטנס לא תקין ירד מ-4–5% לשברי אחוז. זמן ההתאוששות הממוצע לאחר כשל תלות התקצר מעשרות דקות ל-1–2: האינסטנס חוזר בעצמו לפעולה ברגע ש-readiness עובר שוב.
מספר ההפעלות מחדש של קונטיינרים בשבוע ירד בערך פי חמישה — נעלמו ההפעלות השווא בזמן חימום ובעומס שיא.
היציבות הפסיקה להיות תלויה בשאלה אם התורן הבחין בבעיה. הבדיקות מזהות הידרדרות לפני שהלקוחות מרגישים בה, והמטריקות לפי נקודות קצה מספקות תמונה מוכנה לניתוח.
במה שונה liveness מ-readiness?
Liveness עונה על השאלה "האם התהליך חי", readiness — "האם הוא מוכן לקבל תעבורה".
אלו שאלות שונות, ובלבול ביניהן יקר: בדיקה שבודקת את מה שלא צריך, או מפילה קונטיינר בריא שנמצא בחשד ללופ של הפעלות מחדש, או מחזיקה באיזון עומסים מופע שעדיין לא הקים חיבורים עם מסד הנתונים.
בדיקת Liveness מסתכלת רק על מצבו של התהליך עצמו: האם הוא לא נחסם, האם לא נכנס ל-deadlock, האם תהליך הבקרה מגיב. אם הבדיקה נכשלת, הפלטפורמה הורגת את הקונטיינר ומעלה חדש — זה מנוף חירום, לא כלי לכוונון עדין.
הטעות הקלאסית — לתלות בבדיקת liveness בדיקה של תלות חיצונית: מסד הנתונים מהבהב לעשר שניות, וכל צי הקונטיינרים יוצא להפעלה מחדש בו-זמנית, למרות שהאפליקציה הייתה כשירה לחלוטין.
בדיקת Readiness, להיפך, מנהלת את הניתוב. כל עוד היא לא עוברת, המופע מוחרג מאיזון העומסים, אך ממשיך לחיות: טוען את המטמון, ממתין לחימום מאגר החיבורים, מיישם מיגרציות.
Readiness שנפלה לא מפעילה מחדש את הקונטיינר — היא רק מסירה אותו מההגשה, וכאשר התלות חוזרת, המופע באותה חלקות חוזר לשירות.
מכאן הכלל המעשי: ב-liveness — מינימום לוגיקה, רק "התהליך מגיב"; ב-readiness — כל מה שבלעדיו הבקשה לא תטופל כראוי.
גם פסקי הזמן נבדלים: את readiness אפשר לבדוק לעתים קרובות ועם סף קצר, את liveness — לעתים רחוקות יותר ועם מרווח, כדי לא להרוג את הקונטיינר בעומס שיא, כאשר התגובות מאטות באופן טבעי.
ספקות טכניים נפוצות
בדיקות מוטמעות בשירות שכבר פועל ללא שכתוב הלוגיקה העסקית: מוסיפים נקודת קצה נפרדת, שבודקת תלויות ומחזירה סטטוס. אם האפליקציה כבר פרוסה באשכול, תחילה מתעדים את ההתנהגות הנוכחית — כיצד היא מגיבה כאשר מסד הנתונים אינו זמין, כאשר מאגר החיבורים עמוס, כאשר שירות חיצוני איטי. לפי תמונה זו מכוונים את הספים, ולא לפי ברירת המחדל.
לבדיקות יש מגבלות, וחשוב להבהיר אותן לפני ההטמעה. Liveness לא צריך לפנות למסד הנתונים או לשירות חיצוני: אם תלות מהבהבת, הפעלה מחדש של הקונטיינר לא תרפא אותה, והשירות יאבד עיבוד בקשות.
Readiness, לעומת זאת, מחויב להתחשב במוכנות התלויות — אחרת התעבורה תעבור למופע שעדיין אינו יכול להגיב. ההפרדה בין התפקידים הללו היא עיקר העבודה.
כיצד להימנע מהתראות שווא בעת תקלות קצרות טווח?
סף ההפעלה נקבע לא לפי בקשה אחת, אלא לפי סדרה: לדוגמה, שלוש בדיקות כושלות ברצף עם מרווח ותקופת המתנה. בנוסף, פסק זמן נפרד לנקודת הקצה עצמה — היא צריכה להגיב מהר יותר ממה שפג תוקפה של הבדיקה. כך השהיה קצרת טווח של מסד הנתונים אינה מובילה להפעלה מחדש, ואילו הידרדרות מתמשכת — כן.
מה יקרה לפתרון שכבר מוגדר אם נגיע?
מנתחים את הבדיקות הנוכחיות ובוחנים מה הן באמת בודקות. לעתים קרובות liveness ו-readiness מצביעים על אותה נקודת קצה — זה הדבר הראשון שמפרידים. את התצורה מעבירים למניפסטים, כך שהספים ופסקי הזמן יהיו מגורסנים, ולא מוגדרים ידנית בפאנל. החזרה לאחור — שחזור המניפסט הקודם, ללא בנייה מחדש של האימג'.
האם יש לשנות את קוד האפליקציה עבור הבדיקות?
ברוב המקרים — לא. נקודת הקצה מתווספת כמטפל נפרד, הלוגיקה העסקית אינה נפגעת. אם השירות אינו יודע להחזיר סטטוס של תלויות, מוסיפים בדיקה קלה: זמינות החיבור וזמן התגובה. זה מספיק כדי שהבדיקה תשקף מוכנות אמיתית, ולא את עצם הפעלת התהליך.
נדון במשימה שלך להגדרת health check
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה על הסביבה שלך. תאר את המשימה: אילו שירותים מתוחזקים, איך בנוי כעת הדיפלוי, האם יש אורקסטרטור ואיך הפרובים מוגדרים היום. זה מספיק כדי להבין את ההיקף ולהציע סכימה קונקרטית.
מה שמועיל לצרף לתיאור:
- רשימת השירותים והתפקידים שלהם — אילו מקבלים תעבורה, אילו פועלים ברקע;
- מניפסטים או קונפיגורציות דיפלוי נוכחיים, אם קיימים;
- איך נבדקת כעת הזמינות: ניטור חיצוני, בדיקות ידניות או כלום;
- דרישות לזמן ההתאוששות — כמה זמן השבתה מותר במקרה של כשל pod;
- מגבלות על גישות וסביבות: כמה סביבות יש, מי הבעלים של הקלאסטר;
- בעיות ידועות: הפעלות מחדש שגויות, pods תקועים, התחממות ארוכה לאחר עלייה;
- איש קשר מצד התשתית לבירורים במהלך העבודה.
לפי סט זה אנחנו מעריכים את עלות העבודה, מפרטים שלבים וסדר פריסה. לאחר מכן נתאם תוכנית עבודה: סימון פרובים לפי שירותים, הגדרת ספים וטיימאאוטים, בדיקה ב-staging והוצאה הדרגתית לפרודקשן. תחילת הפרויקט — לאחר שנקבע את הגבולות ונקודות החזרה.
תאר את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית עבודה.
