פתרון בעיות שקשורות לאירועי CrashLoopBackOff

אם ה-Pods ב-Google Kubernetes Engine‏ (GKE) תקועים במצב CrashLoopBackOff, המשמעות היא שאחד או יותר מהקונטיינרים מופעלים שוב ושוב ואז יוצאים. סביר להניח שההתנהגות הזו גורמת לאפליקציות להיות לא יציבות או לא זמינות בכלל.

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

המידע הזה חשוב למפתחי אפליקציות שרוצים לזהות ולתקן בעיות ברמת האפליקציה, כמו שגיאות בתכנות, נקודות כניסה שגויות, בעיות בקובץ ההגדרות או בעיות בחיבור לתלות. אדמינים ומפעילים של פלטפורמות יכולים לזהות ולטפל בבעיות שקשורות לפלטפורמה, כמו מיצוי משאבים (OOMKilled), שיבושים בצמתים או בדיקות פעילות שהוגדרו בצורה שגויה. מידע נוסף על התפקידים הנפוצים ומשימות לדוגמה שאליהם אנחנו מתייחסים בתוכן זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE. Cloud de Confiance by S3NS

הסבר על אירוע CrashLoopBackOff

כש-Pod תקוע במצב CrashLoopBackOff, קונטיינר בתוכו מתחיל וקורס או יוצא שוב ושוב. השגיאה CrashLoop גורמת ל-Kubernetes לנסות להפעיל מחדש את הקונטיינר בהתאם ל-restartPolicy שלו. בכל הפעלה מחדש שנכשלה, העיכוב BackOff לפני הניסיון הבא גדל באופן מעריכי (לדוגמה, 10 שניות, 20 שניות, 40 שניות), עד למקסימום של חמש דקות.

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

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

  1. הקונטיינר מופעל.
  2. הקונטיינר יוצא.
  3. ה-kubelet עוקב אחרי הקונטיינר שהופסק ומפעיל אותו מחדש בהתאם ל-restartPolicy של ה-Pod.
  4. המחזור הזה חוזר על עצמו, והקונטיינר מופעל מחדש אחרי השהיה הולכת וגדלה של נסיגה אקספוננציאלית.

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

זיהוי תסמינים של אירוע CrashLoopBackOff

סטטוס CrashLoopBackOff של Pod הוא האינדיקציה העיקרית לאירוע CrashLoopBackOff.

עם זאת, יכול להיות שתיתקלו בתסמינים פחות ברורים של אירוע CrashLoopBackOff:

  • אפס רפליקות תקינות של עומס עבודה.
  • ירידה חדה במספר הרפליקות התקינות.
  • עומסי עבודה שמופעלת בהם התאמה אופקית של קבוצות Pod לעומס (HPA) מתרחבים לאט או שלא מצליחים להתרחב.

אם לעומס עבודה system (לדוגמה, סוכן רישום ביומן או סוכן מדדים) יש סטטוס CrashLoopBackOff, יכול להיות שתבחינו גם בתסמינים הבאים:

  • חלק מהמדדים של GKE לא מדווחים.
  • בחלק מהלוחות והתרשימים של GKE יש פערים.
  • בעיות בקישוריות ברשת ברמת ה-Pod.

אם מופיעים אחד מהתסמינים הפחות ברורים האלה, השלב הבא הוא לוודא אם התרחש אירוע CrashLoopBackOff.

אישור אירוע CrashLoopBackOff

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

  • אירועי Kubernetes מאשרים שקבוצת Pod קורסת.
  • בלוגים של האפליקציה של מאגר התגים אפשר לראות למה התהליך בתוך מאגר התגים נכשל.

כדי לראות את המידע הזה, בוחרים באחת מהאפשרויות הבאות:

המסוף

כדי לראות את האירועים של Kubernetes ואת יומני האפליקציה:

  1. נכנסים לדף Workloads במסוף Cloud de Confiance .

    כניסה לדף Workloads

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

  3. בקטע Managed Pods (פודים מנוהלים), לוחצים על שם הפוד הבעייתי.

  4. בדף פרטי הפוד, בודקים את הפרטים הבאים:

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

kubectl

כדי לראות את האירועים של Kubernetes ואת יומני האפליקציה:

  1. כדי לראות את הסטטוס של כל ה-Pods שפועלים באשכול:

    kubectl get pods

    הפלט אמור להיראות כך:

    NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

    בודקים את העמודות הבאות בפלט:

    • ‫Ready: בודקים כמה קונטיינרים מוכנים. בדוגמה הזו, 0/1 מציין שאף אחד מתוך מאגר אחד צפוי נמצא במצב מוכן. הערך הזה הוא סימן ברור לבעיה.
    • ‫Status: מחפשים Pods עם הסטטוס CrashLoopBackOff.
    • ‫Restarts: ערך גבוה מציין שמערכת Kubernetes מנסה שוב ושוב להפעיל את הקונטיינר, אבל לא מצליחה.

  2. אחרי שמזהים את ה-Pod שנכשל, מתארים אותו כדי לראות אירועים ברמת האשכול שקשורים למצב של ה-Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫POD_NAME: השם של ה-Pod שזיהיתם בפלט של הפקודה kubectl get.
    • ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.

    הפלט אמור להיראות כך:

    Containers:
container-name:
...
  State:          Waiting
    Reason:       CrashLoopBackOff
  Last State:     Terminated
    Reason:       StartError
    Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
    Exit Code:    128
    Started:      Thu, 01 Jan 1970 00:00:00 +0000
    Finished:     Fri, 27 Jun 2025 16:20:03 +0000
  Ready:          False
  Restart Count:  3459
...
Conditions:
Type                        Status
PodReadyToStartContainers   True
Initialized                 True
Ready                       False
ContainersReady             False
PodScheduled                True
...
Events:
Type     Reason   Age                     From     Message
----     ------   ----                    ----     -------
Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)

    בפלט, בודקים את השדות הבאים כדי לזהות סימנים לאירוע CrashLoopBackOff:

    • ‫State: סביר להניח שמצב הקונטיינר יהיה Waiting עם הסיבה CrashLoopBackOff.
    • ‫Last State: המצב של המאגר שהופסק קודם. מחפשים סטטוס Terminated ובודקים את קוד היציאה כדי לראות אם הייתה קריסה (קוד יציאה שאינו אפס) או יציאה מוצלחת לא צפויה (קוד יציאה אפס).
    • ‫Events: פעולות שבוצעו על ידי האשכול עצמו. מחפשים הודעות לגבי הפעלת הקונטיינר, ואחריהן הודעות על כשלים בבדיקת הפעילות או אזהרות על נסיגה כמו Back-off restarting failed container.

  3. כדי להבין למה ה-Pod נכשל, אפשר לעיין ביומני האפליקציה שלו:

    kubectl logs POD_NAME --previous

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

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

שימוש במדריך האינטראקטיבי בנושא Crashlooping Pods

אחרי שמאשרים אירוע של CrashLoopBackOff, מתחילים לפתור את הבעיה באמצעות מדריך הפעולות האינטראקטיבי:

  1. נכנסים לדף GKE Interactive Playbook - Crashlooping Pods במסוף Cloud de Confiance .

    מעבר אל Crashlooping Pods

  2. ברשימה Cluster, בוחרים את האשכול שרוצים לפתור בו בעיות. אם לא מוצאים את האשכול, מזינים את שם האשכול בשדה Filter (סינון).

  3. ברשימה Namespace, בוחרים את מרחב השמות שרוצים לפתור בו בעיות. אם לא מצאתם את מרחב השמות, מזינים אותו בשדה Filter (מסנן).

  4. כדי לעזור לכם לענות על השאלות הבאות, עברו על כל קטע:

    1. זיהוי שגיאות באפליקציה: אילו מאגרי תגים מופעלים מחדש?
    2. בודקים בעיות שקשורות לחוסר זיכרון: האם יש הגדרה שגויה או שגיאה שקשורה לאפליקציה?
    3. בדיקת שיבושים בצומת: האם שיבושים במשאב הצומת גורמים להפעלה מחדש של הקונטיינר?
    4. בדיקת כשלים בבדיקות הפעילות: האם בדיקות הפעילות מפסיקות את הקונטיינרים?
    5. הצלבת אירועי שינוי: מה קרה בסביבות הזמן שבהן הקונטיינרים התחילו לקרוס?

  5. אופציונלי: כדי לקבל התראות על אירועים עתידיים של CrashLoopBackOff, בקטע טיפים למניעת בעיות בעתיד, בוחרים באפשרות יצירת התראה.

אם הבעיה נמשכת אחרי השימוש במדריך, אפשר לקרוא את שאר המדריך כדי לקבל מידע נוסף על פתרון בעיות שקשורות לאירועים של CrashLoopBackOff.

פתרון אירוע מסוג CrashLoopBackOff

בסעיפים הבאים מוסבר איך לפתור את הבעיות הנפוצות ביותר שגורמות לאירועי CrashLoopBackOff:

פתרון בעיות שנובעות ממיצוי משאבים

אירוע CrashLoopBackOff נגרם לרוב בגלל בעיה של חוסר זיכרון (OOM). כדי לוודא שזו הסיבה, בודקים אם הפלט של kubectl describe כולל את הנתונים הבאים:

Last State: Terminated
  Reason: OOMKilled

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

פתרון בעיות שקשורות לבדיקת החיות

בדיקת תקינות (liveness probe) היא בדיקה תקופתית של תקינות המערכת שמבוצעת על ידי kubelet. אם הבדיקה נכשלת מספר פעמים מוגדר (מספר ברירת המחדל הוא שלוש), kubeletהקונטיינר מופעל מחדש ויכול להיות שייווצר אירוע CrashLoopBackOff אם הבדיקות ימשיכו להיכשל.

בדיקה אם בדיקת הפעילות היא הגורם

כדי לוודא אם כשלים בבדיקת הפעילות מפעילים את CrashLoopBackOff האירוע, צריך לשלוח שאילתה ליומנים של kubelet. היומנים האלה כוללים בדרך כלל הודעות מפורשות שמציינות כשלים בבדיקה והפעלה מחדש בעקבותיהם.

  1. נכנסים לדף Logs Explorer במסוף Cloud de Confiance .

    כניסה לדף Logs Explorer

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

    resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"

    מחליפים את CLUSTER_NAME בשם האשכול.

  3. בדקו את התוצאה. אם בדיקת הפעילות (liveness probe) נכשלה וגרמה לאירועי CrashLoopBackOff, השאילתה תחזיר הודעות יומן שדומות להודעות הבאות:

    Container probe failed liveness probe, will be restarted

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

בדיקת ההגדרה של בדיקת הפעילות

בדיקות לא מוגדרות הן סיבה נפוצה לאירועי CrashLoopBackOff. בודקים את ההגדרות הבאות במניפסט של הבדיקה:

  • אימות סוג הבדיקה: ההגדרה של הבקשה לבדיקת תקינות (probe) צריכה להתאים לאופן שבו האפליקציה מדווחת על תקינותה. לדוגמה, אם לאפליקציה יש כתובת URL לבדיקת תקינות (כמו /healthz), צריך להשתמש בסוג הבדיקה httpGet. אם תקינות המערכת נקבעת על ידי הפעלת פקודה, צריך להשתמש בסוג הבדיקה exec. לדוגמה, כדי לבדוק אם יציאת רשת פתוחה ומאזינה, משתמשים בסוג הבדיקה tcpSocket.
  • בדיקת הפרמטרים של הבדיקה:
    • נתיב (לסוג בדיקה httpGet): מוודאים שנתיב ה-HTTP נכון ושהאפליקציה מציגה בו בדיקות תקינות.
    • יציאה: מוודאים שהיציאה שהוגדרה בבדיקה אכן נמצאת בשימוש באפליקציה וחשופה לה.
    • פקודה (לסוג בדיקה exec): מוודאים שהפקודה קיימת במאגר, מחזירה קוד יציאה 0 אם הבדיקה הצליחה ומושלמת בתוך התקופה המוגדרת timeoutSeconds.
    • Timeout: מוודאים שהערך timeoutSeconds מספיק כדי שהאפליקציה תגיב, במיוחד במהלך ההפעלה או בעומס.
    • השהיה ראשונית (initialDelaySeconds): צריך לבדוק אם ההשהיה הראשונית מספיקה כדי שהאפליקציה תתחיל לפני שהבדיקות מתחילות.

מידע נוסף מופיע במאמר Configure Liveness, Readiness and Startup Probes (הגדרת בדיקות פעילות, מוכנות והפעלה) במסמכי התיעוד של Kubernetes.

בדיקת ניצול המעבד (CPU) והקלט/פלט (I/O) בדיסק

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

  • ניתוח השימוש ב-CPU: מעקב אחרי ניצול ה-CPU של הקונטיינר המושפע ושל הצומת שבו הוא פועל במהלך מרווחי הבדיקה. מדד מרכזי שכדאי לעקוב אחריו הוא kubernetes.io/container/cpu/core_usage_time. שימוש גבוה במעבד (CPU) בקונטיינר או בצומת יכול למנוע מהאפליקציה להגיב לבקשה לבדיקת תקינות (probe) בזמן.
  • מעקב אחרי קלט/פלט (I/O) בדיסק: בדיקת מדדי הקלט/פלט בדיסק של הצומת. אפשר להשתמש במדד compute.googleapis.com/guest/disk/operation_time כדי להעריך את משך הזמן שמוקדש לפעולות בדיסק, שמסווגות לפי קריאות וכתיבות. קלט/פלט גבוה בדיסק יכול להאט באופן משמעותי את הפעלת הקונטיינר, את האתחול של האפליקציה או את הביצועים הכוללים של האפליקציה, וכתוצאה מכך להוביל לפסק זמן של בדיקה.

טיפול בפריסות גדולות

בתרחישים שבהם מספר גדול של Pods נפרסים בו-זמנית (לדוגמה, על ידי כלי CI/CD כמו ArgoCD), עלייה פתאומית במספר ה-Pods החדשים עלולה להעמיס על משאבי האשכול, ולגרום למיצוי משאבי מישור הבקרה. המחסור במשאבים גורם לעיכוב בהפעלת האפליקציה, ויכול לגרום לבדיקות הפעילות להיכשל שוב ושוב לפני שהאפליקציות מוכנות.

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

  • הטמעה של פריסות מדורגות: הטמעה של אסטרטגיות לפריסת Pods בקבוצות או לאורך תקופה ארוכה יותר כדי למנוע עומס יתר על משאבי הצומת.
  • הגדרה מחדש או שינוי קנה מידה של הצמתים: אם פריסות מדורגות לא אפשריות, כדאי לשקול שדרוג של הצמתים באמצעות דיסקים מהירים או גדולים יותר, או באמצעות Persistent Volume Claims, כדי לטפל טוב יותר בביקוש מוגבר של קלט/פלט. מוודאים שההגדרה של שינוי הגודל האוטומטי של האשכול מתאימה.
  • ממתינים ומתבוננים: במקרים מסוימים, אם האשכול לא סובל ממחסור חמור במשאבים, יכול להיות שעומסי העבודה ייפרסו בסופו של דבר אחרי עיכוב משמעותי (לפעמים 30 דקות או יותר).

טיפול בשגיאות זמניות שקשורות לכתובת

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

צריכת משאבים של בדיקת כתובת

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

פתרון בעיות בהגדרות שגויות של אפליקציות

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

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

איך מוצאים את קוד היציאה

כדי למצוא את קוד היציאה של האפליקציה:

  1. מתארים את ה-Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫POD_NAME: השם של ה-Pod הבעייתי.
    • ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.

  2. בפלט, בודקים את השדה Exit Code שנמצא בקטע Last State של הקונטיינר הרלוונטי. אם קוד היציאה הוא 0, אפשר לעיין במאמר בנושא פתרון בעיות שקשורות ליציאות מוצלחות (קוד יציאה 0). אם קוד היציאה הוא מספר שונה מ-0, כדאי לעיין במאמר פתרון בעיות שקשורות לקריסת אפליקציות (קוד יציאה שאינו אפס).

פתרון בעיות שקשורות ליציאות מוצלחות (קוד יציאה 0)

קוד יציאה 0 בדרך כלל מציין שהתהליך של מאגר התגים הסתיים בהצלחה. למרות שזהו התוצאה הרצויה למשימה מבוססת-עבודה, היא יכולה להצביע על בעיה בבקר שפועל לטווח ארוך כמו Deployment,‏ StatefulSet או ReplicaSet.

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

הסיבות הנפוצות ביותר ליציאות מוצלחות לא צפויות הן:

  • פקודת הקונטיינר לא מפעילה תהליך מתמשך: קונטיינר ממשיך לפעול רק כל עוד התהליך הראשוני שלו (command או entrypoint) פועל. אם התהליך הזה לא מוגדר כשירות שפועל לאורך זמן, המכולה יוצאת ברגע שהפקודה מסתיימת. לדוגמה, פקודה כמו ["/bin/bash"] יוצאת מיד כי אין לה סקריפט להרצה. כדי לפתור את הבעיה, צריך לוודא שהתהליך הראשוני של מאגר התגים מתחיל תהליך שפועל באופן רציף.

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

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

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

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

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

פתרון בעיות של קריסת אפליקציות (קוד יציאה שאינו אפס)

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

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

  • שגיאות בהגדרות: קוד יציאה שאינו אפס מצביע בדרך כלל על בעיות בהגדרות של האפליקציה או בסביבה שבה היא פועלת. כדאי לבדוק את האפליקציה כדי לזהות את הבעיות הנפוצות הבאות:

    • קובץ תצורה חסר: יכול להיות שהאפליקציה לא מצליחה לאתר קובץ תצורה נדרש או לגשת אליו.
    • הגדרה לא תקינה: יכול להיות שקובץ ההגדרה מכיל שגיאות בתחביר, ערכים שגויים או הגדרות לא תואמות, ולכן האפליקציה קורסת.
    • בעיות בהרשאות: יכול להיות שלאפליקציה אין את ההרשאות הנדרשות לקריאה או לכתיבה של קובץ ההגדרות.
    • משתני סביבה: משתני סביבה שגויים או חסרים עלולים לגרום לתקלה באפליקציה או לכך שהיא לא תופעל.
    • הערך entrypoint או command לא תקין: יכול להיות שהפקודה שצוינה בשדה entrypoint או command של הקונטיינר שגויה. הבעיה הזו יכולה לקרות עם תמונות חדשות שפריסתן בוצעה לאחרונה, אם הנתיב לקובץ ההפעלה שגוי או שהקובץ עצמו לא נמצא בקובץ האימג' של הקונטיינר. בדרך כלל, הגדרה שגויה כזו מובילה לקוד היציאה 128.

    • עדכוני תמונות לא מבוקרים (תג :latest): אם התמונות של עומס העבודה משתמשות בתג :latest, יכול להיות ש-Pods חדשים ימשכו גרסה מעודכנת של התמונה שתציג שינויים שעלולים לשבור את התאימות.

      כדי להבטיח עקביות ויכולת שחזור, בסביבות ייצור צריך תמיד להשתמש בתגי תמונה ספציפיים וקבועים (לדוגמה, v1.2.3) או בסיכומי SHA (לדוגמה, sha256:45b23dee08...). השיטה הזו עוזרת לוודא שתוכן התמונה זהה בכל פעם.

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

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

      אחרי שמתחברים ל-Pod, אפשר להריץ פקודות כדי לבדוק את הגישה לקבצים, למסדי נתונים או לבדוק את הרשת. לדוגמה, אפשר להשתמש בכלי כמו curl כדי לנסות להגיע לכתובת URL של שירות. הפעולה הזו עוזרת לכם לקבוע אם הבעיה נגרמת בגלל מדיניות הרשת, DNS או השירות עצמו.

    • כשלים באימות: יכול להיות שהאפליקציה לא מצליחה לבצע אימות מול שירותים חיצוניים בגלל פרטי כניסה שגויים. בודקים את היומנים של הקונטיינר כדי לראות אם יש הודעות כמו 401 Unauthorized(bad credentials)403 Forbidden או 401 Unauthorized (insufficient permissions)403 Forbidden. הודעות כאלה לרוב מצביעות על כך שלחשבון השירות של ה-Pod חסרים תפקידי ה-IAM הנדרשים כדי לבצע קריאות לשירותים חיצוניים Cloud de Confiance by S3NS.

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

    • פסק זמן (timeout): יכול להיות שיוגדר פסק זמן לאפליקציה בזמן ההמתנה לתגובות משירותים חיצוניים, מה שיוביל לקריסות.

  • שגיאות ספציפיות לאפליקציה: אם נראה שההגדרה והתלות החיצונית תקינות, יכול להיות שהשגיאה היא בקוד של האפליקציה. בודקים ביומני האפליקציה אם יש שגיאות פנימיות נפוצות כמו:

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

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

המאמרים הבאים