פתרון בעיות בעומסי עבודה שנפרסו

בדף הזה מוסבר איך לפתור שגיאות בעומסי עבודה שפרסתם ב-Google Kubernetes Engine ‏ (GKE).

עצות כלליות נוספות לפתרון בעיות באפליקציות זמינות במאמר פתרון בעיות באפליקציות בתיעוד של Kubernetes.

כל השגיאות: בדיקת הסטטוס של ה-Pod

אם יש בעיות ב-Pods של עומס עבודה, מערכת Kubernetes מעדכנת את סטטוס ה-Pod בהודעת שגיאה. כדי לראות את השגיאות האלה, בודקים את הסטטוס של Pod באמצעות מסוף Google Cloud או כלי שורת הפקודה kubectl.

המסוף

כך עושים את זה:

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

    כניסה לדף Workloads

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

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

kubectl

כדי לראות את כל ה-Pods שפועלים באשכול, מריצים את הפקודה הבאה:

kubectl get pods

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

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

שגיאות פוטנציאליות מפורטות בעמודה Status.

כדי לקבל מידע מפורט יותר על Pod ספציפי, מריצים את הפקודה הבאה:

kubectl describe pod POD_NAME

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

בשדה Events בפלט מוצג מידע נוסף על השגיאות.

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

kubectl logs POD_NAME

היומנים האלה יכולים לעזור לכם לזהות אם פקודה או קוד במאגר גרמו לקריסת ה-Pod.

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

שגיאה: CrashLoopBackOff

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

מידע נוסף זמין במאמר בנושא פתרון בעיות שקשורות לאירועים מסוג CrashLoopBackOff.

שגיאות: ImagePullBackOff ו-ErrImagePull

סטטוס ImagePullBackOff או ErrImagePull מציין שלא ניתן לטעון את התמונה שנעשה בה שימוש במאגר תמונות של קונטיינר.

הוראות לפתרון בעיות שקשורות לסטטוסים האלה מופיעות במאמר פתרון בעיות בשליפת תמונות.

שגיאה: OutOfPods

סטטוס OutOfPods מציין שלא ניתן להפעיל Pod בצומת כי הצומת הגיע לקיבולת המקסימלית של ה-Pod.

תסמינים:

יכול להיות שתראו באירועים של ה-Pod הודעה שדומה להודעה הבאה:

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

הסיבה:

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

הפתרון:

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

  • הגדלת מספר ה-Pods המקסימלי לכל צומת. אם הצמתים מגיעים באופן עקבי למגבלת ה-Pod, צריך להגדיל את ההגדרה --max-pods-per-node של מאגרי הצמתים. יכול להיות שיהיה צורך להגדיל את הצמתים כדי לעמוד בדרישות המשאבים המוגברות.

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

  • שינוי פרופיל ההתאמה האוטומטית לעומס. אם כבר משתמשים ב-cluster autoscaler, כדאי לנסות לשנות את פרופיל ההתאמה האוטומטית לעומס ל-balanced במקום ל-optimize-utilization. optimize-utilization הפרופיל יכול להגדיל את הסיכוי לשגיאות OutOfPods כי הוא מנסה למקם את ה-Pods בצמתים שהשימוש בהם הכי גבוה.

שגיאה: אי אפשר לתזמן את הפוד

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

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

שימוש במדריך האינטראקטיבי בנושא פודים שלא ניתן לתזמן

אתם יכולים לפתור בעיות שקשורות ל-PodUnschedulable באמצעות מדריך אינטראקטיבי במסוף Google Cloud :

  1. כדאי לעיין במדריך האינטראקטיבי בנושא פודים שלא ניתן לתזמן:

    למדריך

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

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

  4. כדי לעזור לכם לזהות את הסיבה, כדאי לעבור על כל הקטעים במדריך:

    1. בדיקת המעבד (CPU) והזיכרון
    2. בדיקת מספר ה-Pods המקסימלי לכל צומת
    3. בדיקת ההתנהגות של Autoscaler
    4. בדיקת מצבי כשל אחרים
    5. השוואה בין אירועי שינוי

  5. אופציונלי: כדי לקבל התראות על שגיאות עתידיות של PodUnschedulable, בקטע Future Mitigation Tips (טיפים למניעת שגיאות בעתיד), בוחרים באפשרות Create an Alert (יצירת התראה).

שגיאה: אין מספיק משאבים

יכול להיות שתיתקלו בשגיאה שמציינת שאין מספיק מעבד, זיכרון או משאב אחר. לדוגמה: No nodes are available that match all of the predicates: Insufficient cpu (2) שמציין שבשני צמתים אין מספיק CPU זמין כדי למלא את הבקשות של Pod.

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

אפשר גם להפעיל הקצאת צמתים אוטומטית (NAP) כדי ש-GKE יוכל ליצור באופן אוטומטי מאגרי צמתים עם צמתים שבהם אפשר להריץ את ה-Pods שלא נכללו בתזמון.

בקשת ברירת המחדל של המעבד היא 100m או 10% מהמעבד (או ליבה אחת). אם רוצים לבקש יותר או פחות משאבים, מציינים את הערך במפרט של ה-Pod בקטע spec: containers: resources: requests.

שגיאה: MatchNodeSelector

‫MatchNodeSelector מציין שאין צמתים שתואמים לבורר התוויות של ה-Pod.

כדי לוודא זאת, בודקים את התוויות שצוינו בשדה nodeSelector במפרט של ה-Pod, בקטע spec: nodeSelector.

כדי לראות את התוויות של הצמתים באשכול, מריצים את הפקודה הבאה:

kubectl get nodes --show-labels

כדי לצרף תווית לצומת, מריצים את הפקודה הבאה:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

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

  • ‫NODE_NAME: הצומת שרוצים להוסיף לו תווית.
  • ‫LABEL_KEY: המפתח של התווית.
  • ‫LABEL_VALUE: הערך של התווית.

מידע נוסף זמין במאמר הקצאת פודים לצמתים במאמרי העזרה של Kubernetes.

שגיאה: PodToleratesNodeTaints

‫PodToleratesNodeTaints מציין שלא ניתן לתזמן את ה-Pod לאף צומת כי ל-Pod אין סבילות שמתאימות לכתמי הצומת הקיימים.

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

kubectl describe nodes NODE_NAME

בפלט, בודקים את השדה Taints שבו מפורטים צמדי מפתח-ערך וההשפעות של התזמון.

אם האפקט שמופיע הוא NoSchedule, אי אפשר לתזמן אף Pod בצומת הזה, אלא אם יש לו סבילות תואמת.

אחת הדרכים לפתור את הבעיה היא להסיר את הכתם. לדוגמה, כדי להסיר את ה-taint‏ NoSchedule, מריצים את הפקודה הבאה:

kubectl taint nodes NODE_NAME key:NoSchedule-

שגיאה: PodFitsHostPorts

השגיאה PodFitsHostPorts מציינת שצומת מנסה להשתמש ביציאה שכבר תפוסה.

כדי לפתור את הבעיה, כדאי לפעול לפי השיטות המומלצות ל-Kubernetes ולהשתמש ב-NodePort במקום ב-hostPort.

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

שגיאה: אין זמינות מינימלית

אם לצומת יש מספיק משאבים אבל עדיין מוצגת ההודעה Does not have minimum availability, צריך לבדוק את הסטטוס של ה-Pod. אם הסטטוס הוא SchedulingDisabled או Cordoned, הצומת לא יכול לתזמן Pod חדש. אפשר לבדוק את הסטטוס של צומת באמצעות מסוף Google Cloud או כלי שורת הפקודה kubectl.

המסוף

כך עושים את זה:

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

    מעבר אל Google Kubernetes Engine

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

כדי להפעיל את התזמון בצומת:

  1. ברשימה, לוחצים על הצומת שרוצים לבדוק.

  2. בקטע פרטי הצומת, לוחצים על ביטול ההסרה.

kubectl

כדי לקבל את הסטטוסים של הצמתים, מריצים את הפקודה הבאה:

kubectl get nodes

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

kubectl uncordon NODE_NAME

שגיאה: הגעת למגבלה המקסימלית של Pods לכל צומת

אם כל הצמתים באשכול מגיעים למגבלה של Maximum Pods per node, הפודים נתקעים במצב Unschedulable. בכרטיסייה אירועים של הפוד, מוצגת הודעה שכוללת את הביטוי Too many pods.

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

  1. בודקים את ההגדרה של Maximum pods per node בכרטיסייה Nodes (צמתים) בפרטי אשכול GKE במסוף Google Cloud .

  2. כדי לקבל רשימה של צמתים:

    kubectl get nodes

  3. לכל צומת, בודקים את מספר ה-Pods שפועלים בצומת:

    kubectl get pods -o wide | grep NODE_NAME | wc -l

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

בעיה: הגעתם לגודל המקסימלי של מאגר הצמתים כשהתכונה Cluster Autoscaler מופעלת

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

בעיה: הגעתם לגודל המקסימלי של מאגר הצמתים כשמידרוג אוטומטי של אשכולות מושבת

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

שגיאה: Unbound PersistentVolumeClaims

‫Unbound PersistentVolumeClaims מציין שה-Pod מפנה ל-PersistentVolumeClaim שלא קשור. השגיאה הזו עשויה להתרחש אם הקצאת המקום ב-PersistentVolume נכשלה. כדי לוודא שההקצאה נכשלה, אפשר לקבל את האירועים של PersistentVolumeClaim ולבדוק אם יש בהם כשלים.

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

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

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

  • ‫STATEFULSET_NAME: השם של אובייקט StatefulSet.
  • ‫PVC_NAME: השם של אובייקט PersistentVolumeClaim.

מצב כזה יכול לקרות גם אם הייתה שגיאת הגדרה במהלך הקצאה מראש ידנית של PersistentVolume והקישור שלו ל-PersistentVolumeClaim.

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

שגיאה: המכסה לא מספיקה

מוודאים שלפרויקט יש מכסת Compute Engine מספיקה כדי ש-GKE יוכל להגדיל את גודל האשכול. אם GKE מנסה להוסיף צומת לאשכול כדי לתזמן את ה-Pod, והגדלת הקיבולת תחרוג מהמכסה הזמינה של הפרויקט, תוצג הודעת השגיאה scale.up.error.quota.exceeded.

מידע נוסף זמין במאמר בנושא שגיאות ב-ScaleUp.

בעיה: ממשקי API שהוצאו משימוש

מוודאים שלא משתמשים בממשקי API שהוצאו משימוש והוסרו בגרסה המשנית של האשכול. מידע נוסף זמין במאמר הוצאה משימוש של תכונות וממשקי API.

שגיאה: לא היו יציאות פנויות ליציאות של ה-Pod המבוקש

אם מופיעה שגיאה דומה לזו שבהמשך, כנראה שיש לכם כמה פודים באותו צומת עם אותו ערך שמוגדר בשדה hostPort:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

כשמבצעים שיוך של Pod ל-hostPort, המערכת מגבילה את המקומות שבהם GKE יכול לתזמן את ה-Pod, כי כל שילוב של hostIP, hostPort ו-protocol חייב להיות ייחודי.

כדי לפתור את הבעיה, כדאי לפעול לפי השיטות המומלצות לשימוש ב-Kubernetes ולהשתמש ב-NodePort במקום ב-hostPort.

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

בעיה: כשלים באפליקציה ובבדיקה בקבוצות Pod

הבעיה הבאה מתרחשת כשמפעילים אפליקציות שמשתמשות ב-HTTPS כדי לתקשר עם שרת. שגיאות באפליקציות האלה דומות לשגיאות הבאות:

  • הפודים לא מופעלים והקונטיינרים קורסים עם קוד יציאה 137.

  • בדיקות מצב הפעילות (liveness) או המוכנות נכשלות ומוצגת הודעת שגיאה שדומה להודעה הבאה:

    probeResult="failure" output="Get "https://example.com/healthy": EOF"

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

הבעיות האלה עשויות להתרחש כי בגרסאות 1.30 ואילך של Kubernetes נעשה שימוש בגרסאות Golang שמשביתות את חבילות ההצפנה הבאות של TLS:

  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

כדי לפתור את הבעיה, צריך להשתמש בסטים נתמכים של אלגוריתמים להצפנה מ-TLS 1.2 ואילך.

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