פתרון בעיות שקשורות לאירועי 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. המחזור בדרך כלל נראה כך:

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

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

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

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

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

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

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

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

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

אישור אירוע `CrashLoopBackOff`

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

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

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

המסוף

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

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

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

kubectl

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

כדי לראות את הסטטוס של כל ה-Pods שפועלים באשכול:
```
kubectl get pods
```
הפלט אמור להיראות כך:
```
NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d
```
בודקים את העמודות הבאות בפלט:
- ‫Ready: בודקים כמה קונטיינרים מוכנים. בדוגמה הזו, 0/1 מציין שאף אחד מתוך מאגר אחד צפוי נמצא במצב מוכן. הערך הזה הוא סימן ברור לבעיה.
- ‫Status: מחפשים Pods עם הסטטוס CrashLoopBackOff.
- ‫Restarts: ערך גבוה מציין שמערכת Kubernetes מנסה שוב ושוב להפעיל את הקונטיינר, אבל לא מצליחה.
אחרי שמזהים 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: פעולות שבוצעו על ידי האשכול עצמו. חפשו הודעות על הפעלת הקונטיינר, ואחריהן הודעות על כשלים בבדיקת מצב פעילות (liveness) או אזהרות על נסיגה כמו Back-off restarting failed container.
כדי להבין למה ה-Pod נכשל, אפשר לעיין ביומני האפליקציה שלו:
```
kubectl logs POD_NAME --previous
```
הדגל --previous מאחזר יומנים מהקונטיינר הקודם שהופסק, שבו אפשר למצוא את דוח הקריסות הספציפי או את הודעת השגיאה שחושפת את הסיבה לקריסה. יכול להיות שהמאגר הנוכחי חדש מדי ולא נרשמו בו יומנים.

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

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

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

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

כניסה לדף Crashlooping Pods
ברשימה Cluster, בוחרים את האשכול שרוצים לפתור בו בעיות. אם לא מוצאים את האשכול, מזינים את שם האשכול בשדה Filter (מסנן).
ברשימה Namespace, בוחרים את מרחב השמות שרוצים לפתור בו בעיות. אם אתם לא מוצאים את מרחב השמות, מזינים אותו בשדה Filter (מסנן).
כדי לעזור לכם לענות על השאלות הבאות, תוכלו לעבור על כל קטע:
1. זיהוי שגיאות באפליקציה: אילו קונטיינרים מופעלים מחדש?
2. בדיקה של בעיות שקשורות לחוסר זיכרון: האם יש הגדרה שגויה או שגיאה שקשורה לאפליקציה?
3. בדיקת שיבושים בצומת: האם שיבושים במשאב הצומת גורמים להפעלה מחדש של הקונטיינר?
4. בדיקת כשלים בבדיקות מצב פעילות (liveness): האם בדיקות מצב פעילות (liveness) מפסיקות את הקונטיינרים?
5. השוואה בין אירועי שינוי: מה קרה בסביבות הזמן שבהן הקונטיינרים התחילו לקרוס?
אופציונלי: כדי לקבל התראות על אירועים עתידיים של CrashLoopBackOff, בקטע טיפים למניעת בעיות בעתיד, בוחרים באפשרות יצירת התראה.

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

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

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

מיצוי משאבים (OOMKilled)
Liveness probe failure
אפליקציה שההגדרה שלה לא תקינה

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

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

Last State: Terminated
  Reason: OOMKilled

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

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

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

בדיקה אם בקשה לבדיקת תקינות מצב פעילות היא הגורם

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

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

כניסה לדף Logs Explorer
בחלונית השאילתות, מסננים את ההפעלה מחדש שקשורה לבדיקת הפעילות על ידי הזנת השאילתה הבאה:
```
resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"
```
מחליפים את CLUSTER_NAME בשם האשכול.
בודקים את הפלט. אם בדיקת החיות נכשלה וגרמה לאירועים מסוג CrashLoopBackOff, השאילתה תחזיר הודעות יומן שדומות להודעות הבאות:
```
Container probe failed liveness probe, will be restarted
```

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

בדיקת ההגדרה של בדיקת הפעילות
בדיקת ניצול המעבד (CPU) והקלט/פלט (I/O) בדיסק.
התמודדות עם פריסות גדולות.
שגיאות זמניות בכתובת.
צריכת משאבים של בדיקת כתובת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מתארים את ה-Pod:
```
kubectl describe pod POD_NAME -n NAMESPACE_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POD_NAME: השם של ה-Pod הבעייתי.
- ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.
בפלט, בודקים את השדה Exit Code שנמצא בקטע Last State של הקונטיינר הרלוונטי. אם קוד היציאה הוא 0, אפשר לעיין במאמר בנושא פתרון בעיות שקשורות ליציאות מוצלחות (קוד יציאה 0). אם קוד היציאה הוא מספר אחר מלבד 0, אפשר לעיין במאמר פתרון בעיות שקשורות לקריסות של אפליקציות (קוד יציאה שאינו אפס).

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

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

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

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

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

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

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

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

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

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

שגיאות בהגדרות: קוד יציאה שאינו אפס מצביע בדרך כלל על בעיות בהגדרות של האפליקציה או בסביבה שבה היא פועלת. כדאי לבדוק אם באפליקציה יש אחת מהבעיות הנפוצות הבאות:
- קובץ תצורה חסר: יכול להיות שהאפליקציה לא מצליחה לאתר קובץ תצורה נדרש או לגשת אליו.
- הגדרה לא תקינה: יכול להיות שקובץ ההגדרה מכיל שגיאות בתחביר, ערכים שגויים או הגדרות לא תואמות, ולכן האפליקציה קורסת.
- בעיות בהרשאות: יכול להיות שלאפליקציה אין את ההרשאות הנדרשות לקריאה או לכתיבה של קובץ התצורה.
- משתני סביבה: משתני סביבה שגויים או חסרים עלולים לגרום לתקלה באפליקציה או לכך שהיא לא תופעל.
- הערך entrypoint או command לא תקין: יכול להיות שהפקודה שצוינה בשדה entrypoint או command של הקונטיינר שגויה. הבעיה הזו יכולה לקרות עם קובצי אימג' של קונטיינר שזה עתה נפרסו, אם הנתיב לקובץ ההפעלה שגוי או אם הקובץ עצמו לא נמצא בקובץ אימג' של הקונטיינר. בדרך כלל, הגדרה שגויה כזו מובילה לקוד היציאה 128.
- עדכוני תמונות לא מבוקרים (תג :latest): אם התמונות של עומס העבודה משתמשות בתג :latest, יכול להיות ש-Pods חדשים ימשכו גרסה מעודכנת של התמונה שתציג שינויים שעלולים לשבור את התאימות.
  
  כדי להבטיח עקביות ושחזור, בסביבות ייצור צריך תמיד להשתמש בתגי תמונה ספציפיים וקבועים (לדוגמה, v1.2.3) או בסיכומי SHA (לדוגמה, sha256:45b23dee08...). השיטה הזו עוזרת לוודא שתוכן התמונה זהה בכל פעם.
בעיות בתלות: האפליקציה עלולה לקרוס אם היא לא מצליחה להתחבר לשירותים אחרים שהיא תלויה בהם, או אם היא לא מצליחה לבצע אימות או שאין לה הרשאות מספיקות לגשת אליהם.
- שירות חיצוני לא זמין: יכול להיות שהאפליקציה תלויה בשירותים חיצוניים (לדוגמה, מסדי נתונים או ממשקי API) שלא ניתן להגיע אליהם בגלל בעיות בקישוריות לרשת או הפסקות שירות. כדי לפתור את הבעיה, צריך להתחבר ל-Pod. מידע נוסף זמין במאמר בנושא ניפוי באגים בפודים פועלים במאמרי העזרה של Kubernetes.
  
  אחרי שמתחברים ל-Pod, אפשר להריץ פקודות כדי לבדוק את הגישה לקבצים ולמסדי נתונים, או כדי לבדוק את הרשת. לדוגמה, אפשר להשתמש בכלי כמו curl כדי לנסות להגיע לכתובת URL של שירות. הפעולה הזו עוזרת לכם לקבוע אם הבעיה נגרמת בגלל מדיניות הרשת, DNS או השירות עצמו.
- כשלים באימות: יכול להיות שהאפליקציה לא מצליחה לבצע אימות מול שירותים חיצוניים בגלל פרטי כניסה שגויים. בודקים את היומנים של הקונטיינר כדי לראות אם יש הודעות כמו 401 Unauthorized(bad credentials) או 403 Forbidden (insufficient permissions). הודעות כאלה לרוב מצביעות על כך שלחשבון השירות של ה-Pod חסרים תפקידי ה-IAM הנדרשים כדי לבצע קריאות לשירותים חיצוניים Google Cloud.
  
  אם אתם משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, ודאו שלמזהה העיקרי יש את ההרשאות הנדרשות למשימה. מידע נוסף על הקצאת תפקידי IAM לחשבונות משתמשים באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE זמין במאמר הגדרת הרשאות וחשבונות משתמשים. כדאי גם לוודא ששימוש המשאבים של שרת המטא-נתונים של GKE לא חרג מהמגבלות שלו.
- פסק זמן (timeout): יכול להיות שיווצר פסק זמן באפליקציה בזמן ההמתנה לתגובות משירותים חיצוניים, מה שיוביל לקריסות.
שגיאות ספציפיות לאפליקציה: אם נראה שההגדרה והתלות החיצונית תקינות, יכול להיות שהשגיאה היא בקוד של האפליקציה. בודקים ביומני האפליקציה אם יש שגיאות פנימיות נפוצות כמו:
- חריגים שלא טופלו: ייתכן שיופיעו ביומני האפליקציה עקבות מחסנית או הודעות שגיאה שמציינות חריגים שלא טופלו או באגים אחרים שקשורים לקוד.
- קיפאון או נעילה פעילה: יכול להיות שהאפליקציה נתקעה בקיפאון, שבו כמה תהליכים ממתינים זה לזה כדי להסתיים. בתרחיש הזה, יכול להיות שהאפליקציה לא תיסגר, אבל היא תפסיק להגיב לזמן בלתי מוגבל.
- התנגשויות בין יציאות: יכול להיות שהאפליקציה לא תופעל אם היא תנסה להתחבר ליציאה שכבר נמצאת בשימוש של תהליך אחר.
- ספריות לא תואמות: יכול להיות שהאפליקציה תלויה בספריות או בתלויות שחסרות או לא תואמות לסביבת זמן הריצה.
כדי למצוא את שורש הבעיה, בודקים את היומנים של מאגר התגים כדי למצוא הודעת שגיאה ספציפית או דוח קריסות. המידע הזה יעזור לכם להחליט אם לתקן את קוד האפליקציה, לשנות את מגבלות המשאבים או לתקן את הגדרות הסביבה. מידע נוסף על יומנים זמין במאמר מידע על יומנים של GKE.

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

אם לא מצאתם פתרון לבעיה שלכם במסמכים, תוכלו להיעזר בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
- פתיחת באגים או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.