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

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

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

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

הסבר על אירוע 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

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

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

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

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

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

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

אישור אירוע CrashLoopBackOff

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

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

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

המסוף

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

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

    כניסה לדף Workloads

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

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

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

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

kubectl

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

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

    kubectl get pods

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

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

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

    • ‫Ready: בודקים כמה קונטיינרים מוכנים. בדוגמה הזו, 0/1 מציין שאף אחד מתוך מאגר אחד צפוי נמצא במצב מוכן. הערך הזה הוא סימן ברור לבעיה.
    • ‫Status: מחפשים פודים עם הסטטוס 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 במסוף Google Cloud .

    מעבר אל 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)

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

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

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

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

    כניסה לדף 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. בדקו את התוצאה. אם הגורם לאירועי CrashLoopBackOff הוא כשל בבדיקת החיוּת, השאילתה מחזירה הודעות ביומן שדומות לאלה:

    Container probe failed liveness probe, will be restarted

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

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

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

  • אימות סוג הבדיקה: הגדרת הבדיקה צריכה להתאים לאופן שבו האפליקציה מדווחת על התקינות שלה. לדוגמה, אם לאפליקציה שלכם יש כתובת 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) בקונטיינר גורם לכשלים בבדיקה במהלך האתחול, אפשר להשתמש בהגברת המעבד (CPU) בזמן ההפעלה כדי להקצות באופן זמני יותר משאבי מעבד. מידע נוסף זמין במאמר האצת הפעלת האפליקציה באמצעות הגברת המעבד (CPU) בזמן ההפעלה.

  • מעקב אחרי קלט/פלט בדיסק: בדיקת מדדי הקלט/פלט בדיסק של הצומת. אתם יכולים להשתמש במדד 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"] יוצאת מיד כי אין לה סקריפט להרצה. כדי לפתור את הבעיה, ודאו שהתהליך הראשוני של הקונטיינר מתחיל תהליך שפועל באופן רציף.

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

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

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

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

    דוגמה נפוצה לבעיה הזו היא כשמגדירים אפליקציה לקרוא מקובץ שמוטמע באמצעות נפח ConfigMap. אם הקובץ ConfigMap לא מצורף, הוא ריק או שהמפתחות שלו לא נקראו בשם הנכון, אפליקציה שנועדה לצאת אם חסרה ההגדרה שלה עשויה להפסיק עם קוד יציאה של 0. במקרים כאלה, צריך לוודא שההגדרות הבאות נכונות: - השם ConfigMap בהגדרת עוצמת הקול של ה-Pod זהה לשם בפועל. - השם 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 (פרטי כניסה שגויים) או 403 Forbidden (הרשאות לא מספיקות), שבדרך כלל מצביעות על כך שלחשבון השירות של ה-Pod אין את תפקידי ה-IAM הנדרשים כדי לבצע קריאות לשירות Google Cloudחיצוני.

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

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

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

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

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

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