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

בדף הזה מוסבר איך לפתור שגיאות בעומסי העבודה שנפרסו ב-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 מקצה Pods לצומת חדש לפני שאגנט kubelet דיווח על נוכחות של Pods סטטיים כמו רכיב kube-proxy, שדורשים קיבולת Pod משלהם.

רזולוציה

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

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

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

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

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

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

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

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

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

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

    מעבר למדריך

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

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

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

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

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

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

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

תסמינים

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

מטרה

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

האשכול שלכם מפעיל מאגרי מערכת במרחב השמות kube-system. גם הקונטיינרים האלה משתמשים במשאבי האשכול.

רזולוציה

אפשר לנסות את הפתרונות הבאים:

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

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

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

שגיאה: MatchNodeSelector

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

תסמינים

בסטטוס או באירועים של ה-Pod מוצגת שגיאה MatchNodeSelector.

מטרה

התוויות שצוינו בשדה nodeSelector במניפסט של ה-Pod לא קיימות באף צומת באשכול.

רזולוציה

כדי לפתור את השגיאה הזו, צריך לוודא שהתוויות שצוינו בשדה nodeSelector של ה-Pod תואמות לתוויות של לפחות צומת אחד באשכול:

  1. כדי לזהות את דרישות התווית שה-Pod מחפש, בודקים את השדה spec: nodeSelector שלו.

  2. כדי לבדוק אם יש תוויות שתואמות לדרישות של ה-Pod, צריך להציג את התוויות בפועל שהוקצו לצמתים באשכול:

    kubectl get nodes --show-labels

  3. אם רוצים שה-Pod יפעל בצומת מסוים, צריך לצרף את התווית הנדרשת:

    kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

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

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

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

שגיאה: PodToleratesNodeTaints

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

תסמינים

בסטטוס או באירועים של ה-Pod מוצגת שגיאה PodToleratesNodeTaints.

מטרה

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

רזולוציה

  1. בודקים את ה-taints בצומת:

    kubectl describe nodes NODE_NAME

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

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

    kubectl taint nodes NODE_NAME key:NoSchedule-

שגיאה: PodFitsHostPorts

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

תסמינים

הסטטוס של ה-Pod מציג שגיאה PodFitsHostPorts.

מטרה

‫Pod מבקש יציאת מארח שכבר נמצאת בשימוש על ידי Pod או תהליך אחר בצומת היעד.

רזולוציה

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

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

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

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

תסמינים

  • מופיעה השגיאה Does not have minimum availability.

  • הסטטוס של הצומת הוא SchedulingDisabled או Cordoned.

מטרה

הסטטוס 'מוקף בגדר' של הצומת מונע תזמון של Pods חדשים בו.

רזולוציה

כדי שהצומת יהיה זמין שוב לתזמון של Pods, צריך לבטל את ההגדרה שלו כ-cordon:

המסוף

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

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

    מעבר אל Google Kubernetes Engine

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

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

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

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

kubectl

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

kubectl get nodes

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

kubectl uncordon NODE_NAME

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

שגיאה Too many pods מציינת שלא ניתן לתזמן Pod כי הצומת של היעד הגיע לקיבולת המקסימלית של ה-Pod שהוגדרה.

תסמינים

  • ה-Pods תקועים במצב Unschedulable.
  • מופיעה הודעה שכוללת את הביטוי Too many pods.

מטרה

הגעתם למגבלה של Maximum Pods per node בכל הצמתים באשכול.

רזולוציה

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

  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 נשאר במצב Pending.

מטרה

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

רזולוציה

כדי להגדיל את הגודל המקסימלי של מאגר הצמתים, צריך לשנות את ההגדרה של Cluster Autoscaler.

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

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

תסמינים

מערכת GKE לא יכולה לתזמן את ה-Pod עם מאגר הצמתים.

מטרה

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

רזולוציה

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

שגיאה: Unbound PersistentVolumeClaims

שגיאה Unbound PersistentVolumeClaims מציינת שה-Pod מפנה ל-PersistentVolumeClaim שלא קשור.

תסמינים

בסטטוס או באירועים של ה-Pod מוצגת שגיאה Unbound PersistentVolumeClaims.

מטרה

השגיאה הזו יכולה להתרחש בגלל אחת מהסיבות הבאות:

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

רזולוציה

  1. כדי לבדוק אם הקצאת המשאבים נכשלה, מקבלים את האירועים של PersistentVolumeClaim:

    kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

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

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

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

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

אם GKE מנסה להגדיל את קנה המידה של האשכול כדי לתזמן Pod, אבל נתקל במגבלות של מכסת המשאבים, הגדלת קנה המידה נכשלת.

תסמינים

מופיעה הודעת השגיאה scale.up.error.quota.exceeded באירועים של ה-Pod.

מטרה

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

רזולוציה

מוודאים שלפרויקט יש מכסת Compute Engine מספיקה כדי ש-GKE יוכל להגדיל את גודל האשכול. למידע נוסף, ראו שגיאות ScaleUp.

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

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

תסמינים

פריסת עומסי העבודה נכשלת או שהם לא פועלים בגלל שימוש ב-API שהוצא משימוש.

מטרה

קבצי המניפסט משתמשים בממשקי API שהוצאו משימוש והוסרו בגרסה המשנית של האשכול.

רזולוציה

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

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

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

תסמינים

מופיעה שגיאה שדומה לזו:

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.

מטרה

כמה פודים באותו צומת מציינים את אותו ערך שמוגדר בשדה hostPort.

רזולוציה

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

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

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

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

תסמינים

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

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

  • בדיקות הפעילות או המוכנות נכשלות עם הודעת שגיאה שדומה להודעה הבאה:

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

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

מטרה

ב-Kubernetes בגרסה 1.30 ואילך נעשה שימוש בגרסאות Golang שמשביתות את סט אלגוריתמים להצפנה (cipher suite)‏ הבא של 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 ואילך.

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