פתרון בעיות שקשורות למידרוג אוטומטי של אשכולות שלא מתרחב

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

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

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

הבנת מתי המידרוג האוטומטי של האשכול מרחיב אנכית את הצמתים שלך

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

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

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

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

כדי לקבוע אם צריך להגדיל את האשכול, בודקים אם יש Pods שלא תוכננו:

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

    כניסה לדף Workloads

  2. בשדה Filter, מזינים unschedulable ולוחצים על Enter.

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

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

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

אם אתם בודקים מה גרם לכישלון של המידרוג האוטומטי באשכול בעבר, בדקו אם יש Pods שלא ניתן לתזמן:

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

    כניסה לדף Logs Explorer

  2. מציינים טווח תאריכים לרשומות ביומן שרוצים להציג.

  3. בחלונית השאילתה, מזינים את השאילתה הבאה:

    logName="projects/PROJECT_ID/logs/events"
jsonPayload.source.component="default-scheduler"
jsonPayload.reason="FailedScheduling"

    מחליפים את PROJECT_ID במזהה הפרויקט.

  4. לוחצים על Run query.

    אם מופיעות תוצאות, סימן שהיו פודים שלא ניתן לתזמן בטווח הזמן שציינתם.

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

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

ניתוח מדדי Cloud Monitoring כדי לזהות בעיות בהגדלת קנה המידה

הכלי לשינוי קנה מידה של אשכולות ב-GKE חושף מדדים ל-Cloud Monitoring שמספקים תובנות לגבי ההחלטות שלו, במיוחד ביחס ל-ComputeClasses. המדדים האלה זמינים ב-GKE מגרסה 1.37 ואילך, והם כוללים את המדדים הבאים.

  • ‫Pending Pods: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc מציג Pods שה-autoscaler מנסה לתזמן.
  • Provisioning attempts: kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_cccמעקב אחרי התדירות שבה המידרוג האוטומטי מנסה להוסיף צמתים.
  • כשלים בהקצאה: kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc מציג ניסיונות כושלים ליצירת צומת ואת הסיבות לכך.

המדדים האלה משתמשים בסוג המשאב k8s_entity, שבו הערך של השדה resource.labels.entity_type הוא ComputeClass. הערך של השדה resource.labels.entity_name מציין את השם של ComputeClass. אם הערך בשדה entity_name הוא מחרוזת ריקה (""), המדד מתייחס להחלטות של מידרוג אוטומטי של אשכול שלא קשורות ל-ComputeClass.

אפשר להשתמש ב-Metrics Explorer כדי לסנן ולקבץ את התוצאות לפי השדה entity_name. לדוגמה, אפשר להשתמש במחרוזת resource.labels.entity_name = "" כדי לראות פעילויות שלא קשורות ל-ComputeClasses, ובתוויות של מדדים (כמו reason) כדי להבין אם בעיות בהגדלת הנפח קשורות ל-ComputeClass ספציפי.

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

לצפייה בשגיאות

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

הצגת שגיאות בהתראות

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

כדי לראות את ההתראות במסוף Google Cloud :

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

    כניסה לאשכולות של Kubernetes

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

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

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

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

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

הצגת שגיאות באירועים

אם הבעיה שזיהיתם קרתה לפני יותר מ-72 שעות, תוכלו לראות את האירועים ב-Cloud Logging. אם מתרחשת שגיאה, היא בדרך כלל מתועדת באירוע.

כדי להציג את יומני המידרוג האוטומטי של האשכול במסוף Google Cloud :

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

    כניסה לאשכולות של Kubernetes

  2. בוחרים את שם האשכול שרוצים לחקור כדי לפתוח את דף הפרטים שלו (Cluster details).

  3. בדף Cluster details, לוחצים על הכרטיסייה Logs.

  4. בכרטיסייה Logs, לוחצים על הכרטיסייה Autoscaler Logs כדי לראות את היומנים.

  5. אופציונלי: כדי להחיל מסננים מתקדמים יותר לצמצום התוצאות, לוחצים על הלחצן עם החץ בצד שמאל של הדף כדי להציג את היומנים ב-Logs Explorer.

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

דוגמה: פתרון בעיה שקיימת יותר מ-72 שעות

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

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

הפתרון:

  1. הבעיה התרחשה לפני יותר מ-72 שעות, ולכן אתם בודקים אותה באמצעות Cloud Logging במקום להסתכל על הודעות ההתראה.
  2. ב-Cloud Logging אפשר למצוא את פרטי הרישום ביומן של אירועי התאמה אוטומטית של קנה מידה באשכול, כמו שמתואר בקטע הצגת שגיאות באירועים.

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

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

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

    • ‫unhandledPodGroups: מכיל מידע על ה-Pod (או על הבקר של ה-Pod).
    • ‫reason: מספק סיבות גלובליות לכך שהגדלת קנה המידה עלולה להיחסם.
    • ‫skippedMigs: סיבות לכך שקבוצות MIG מסוימות לא נכללות.

  6. אתם מוצאים אירוע noScaleUp של ה-Pod, ולכל קבוצות ה-MIG בשדה rejectedMigs יש את אותו מזהה הודעה של סיבה "no.scale.up.mig.failing.predicate" עם שני פרמטרים: "NodeAffinity" ו-"node(s) did not match node selector".

פתרון:

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

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

פתרון שגיאות בהגדלת קנה המידה

אם אתם משתמשים ב-ComputeClasses בהתאמה אישית והבעיות בהרחבה קשורות להגדרות הספציפיות של הצמתים שהוגדרו ב-ComputeClass, קראו את המאמר פתרון בעיות ב-ComputeClass בהתאמה אישית.

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

שגיאות ב-ScaleUp

הודעות השגיאה של אירועי scaleUp מופיעות באירוע eventResult התואם, בשדה resultInfo.results[].errorMsg.

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

הודעה פרטים פרמטרים צמצום הפגיעה
"scale.up.error.out.of.resources" שגיאות במשאבים מתרחשות כשמנסים לבקש משאבים חדשים באזור שלא יכול למלא את הבקשה, כי משאב של Compute Engine, כמו מעבדי GPU או מעבדי CPU, לא זמין כרגע. מזהי ה-MIG שנכשלו. פועלים לפי השלבים לפתרון בעיות שקשורות לזמינות המשאבים במאמרי העזרה של Compute Engine.
"scale.up.error.quota.exceeded" אירוע ה-scaleUp נכשל כי לא ניתן היה להגדיל חלק מקבוצות ה-MIG, בגלל חריגה מהמכסה של Compute Engine. מזהי ה-MIG שנכשלו. בודקים בכרטיסייה Errors של קבוצת ה-MIG במסוף Google Cloud כדי לראות איזו מכסה חורגת. אחרי שאתם יודעים איזו מכסה חורגת, פועלים לפי ההוראות כדי לבקש הגדלת מכסה.
"scale.up.error.waiting.for.instances.timeout" הגדלה של קבוצת מופעי מכונה מנוהלים נכשלה כי הזמן הקצוב לתפוגה חלף. מזהי ה-MIG שנכשלו. אם המכונות מופעלות אבל לא נרשמות במישור הבקרה, פועלים לפי השלבים שמפורטים בקטע איתור מכונה שנכשלה ברישום הצומת. לסיבות אחרות, ראו מכונות MIG לא הופיעו בזמן. השגיאה הזו היא בדרך כלל זמנית. אם השגיאה נמשכת, פנו ל-Cloud Customer Care כדי לבדוק את הבעיה.
"scale.up.error.ip.space.exhausted" אי אפשר להגדיל את קבוצת המכונות כי נגמרו כתובות ה-IP במופעים של חלק מקבוצות המכונות המנוהלות. המשמעות היא שאין באשכול מספיק כתובות IP פנויות להקצאה כדי להוסיף צמתים או Pods חדשים. מזהי ה-MIG שנכשלו. פועלים לפי השלבים לפתרון בעיות שמפורטים בקטע אין מספיק מקום פנוי בכתובת ה-IP לפודים.
"scale.up.error.service.account.deleted" אי אפשר להגדיל את המכסה כי חשבון השירות נמחק. מזהי ה-MIG שנכשלו. נסו לבטל מחיקה של חשבון השירות. אם התהליך לא מצליח, פנו ל-Cloud Customer Care כדי לבדוק את הבעיה.

הסיבות לאירוע noScaleUp

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

סיבות ברמה העליונה ל-NoScaleUp

הודעות הסיבה ברמה העליונה לאירועי noScaleUp מופיעות בשדה noDecisionStatus.noScaleUp.reason. ההודעה מכילה סיבה ברמה העליונה לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את האשכול.

הודעה פרטים צמצום הפגיעה
"no.scale.up.in.backoff" אין הגדלה כי ההגדלה נמצאת בתקופת השהיה (חסומה באופן זמני). ההודעה הזו יכולה להופיע במהלך אירועי הגדלה עם מספר גדול של Pods. ההודעה הזו אמורה להיות זמנית. בדקו את השגיאה הזו אחרי כמה דקות. אם ההודעה הזו ממשיכה להופיע, פנו ל-Cloud Customer Care כדי לבדוק את הבעיה.

סיבות ברמה העליונה לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) להגדלת הנפח (NoScaleUp)

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

הודעה פרטים צמצום הפגיעה
"no.scale.up.nap.disabled"

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

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

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

סיבות ברמת ה-MIG ל-NoScaleUp

הודעות הסיבה ברמת ה-MIG לאירועי noScaleUp מופיעות בשדות noDecisionStatus.noScaleUp.skippedMigs[].reason ו-noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. ההודעה מכילה את הסיבה לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את קבוצת ה-MIG הספציפית.

הודעה פרטים פרמטרים צמצום הפגיעה
"no.scale.up.mig.skipped" אי אפשר להגדיל את קבוצת המכונות המנוהלת כי המערכת דילגה עליה במהלך הסימולציה. הסיבות לכך שהמערכת דילגה על ה-MIG (לדוגמה, חסרה דרישה של Pod). בודקים את הפרמטרים שכלולים בהודעת השגיאה ומטפלים בסיבה שבגללה המערכת דילגה על קבוצת ה-MIG.
"no.scale.up.mig.failing.predicate" אי אפשר להגדיל את מאגר הצמתים כי הפרדיקט של התזמון נכשל בפודים בהמתנה. שם הפרדיקט שנכשל והסיבות לכישלון. בודקים את הדרישות של Pod, כמו כללי אפיניות, taints או tolerations ודרישות משאבים.

סיבות לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) ברמת קבוצת הפודים NoScaleUp

הודעות הסיבה להקצאת צמתים אוטומטית ברמת קבוצת הפודים לאירועי noScaleUp מופיעות בשדה noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. ההודעה מכילה את הסיבה לכך שהמידרוג האוטומטי של האשכול לא יכול להקצות מאגר צמתים חדש כדי לתזמן קבוצת Pod מסוימת.

הודעה פרטים פרמטרים צמצום הפגיעה
"no.scale.up.nap.pod.gpu.no.limit.defined" הקצאת צמתים אוטומטית (NAP) לא הצליחה להקצות קבוצת צמתים כי לפוד בהמתנה יש בקשת GPU, אבל מגבלות המשאבים של ה-GPU לא מוגדרות ברמת האשכול. סוג ה-GPU המבוקש. בודקים את בקשת ה-GPU של ה-Pod בהמתנה, ומעדכנים את ההגדרות של מגבלות ה-GPU להקצאת צמתים אוטומטית ברמת האשכול.
"no.scale.up.nap.pod.gpu.type.not.supported" הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים ל-Pod כי יש לו בקשות לסוג GPU לא ידוע. סוג ה-GPU המבוקש. בודקים את ההגדרות של ה-Pod בהמתנה לסוג ה-GPU כדי לוודא שהן תואמות לסוג GPU נתמך.
"no.scale.up.nap.pod.zonal.resources.exceeded" הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים לפוד באזור הזה, כי פעולה כזו הייתה מפרה את מגבלות המשאבים המקסימליות ברמת האשכול, חורגת מהמשאבים הזמינים באזור או שאין סוג מכונה שמתאים לבקשה. שם האזור הרלוונטי. בודקים ומעדכנים את מגבלות המשאבים המקסימליות ברמת האשכול, את בקשות המשאבים של Pod או את האזורים הזמינים להקצאת צמתים אוטומטית.
"no.scale.up.nap.pod.zonal.failing.predicates" הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים ל-Pod באזור הזה בגלל פרדיקטים שנכשלו. שם האזור שנבדק והסיבות לכך שהפרדיקטים נכשלו. בודקים את הדרישות של ה-Pod בהמתנה, כמו כללי אפיניות, טיינטים, טולרציות או דרישות למשאבים.

ביצוע בדיקה נוספת

בקטעים הבאים מוסבר איך להשתמש ב-Logs Explorer וב-gcpdiag כדי לקבל תובנות נוספות לגבי השגיאות.

בדיקת שגיאות ב-Logs Explorer

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

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

    כניסה לדף Logs Explorer

  2. בחלונית השאילתה, מזינים את השאילתה הבאה:

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    מחליפים את ERROR_MESSAGE בהודעה שרוצים לבדוק. לדוגמה, scale.up.error.out.of.resources.

  3. לוחצים על Run query.

ניפוי באגים של שגיאות מסוימות באמצעות gcpdiag

‫gcpdiag הוא כלי בקוד פתוח שנוצר בתמיכת מהנדסים טכניים של Google Cloud. זה לא מוצר של Google Cloud שנתמך באופן רשמי.

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

  • scale.up.error.out.of.resources
  • scale.up.error.quota.exceeded
  • scale.up.error.waiting.for.instances.timeout
  • scale.up.error.ip.space.exhausted
  • scale.up.error.service.account.deleted

רשימה ותיאור של כל הדגלים של הכלי gcpdiag מופיעים בהוראות השימוש ב-gcpdiag.

פתרון שגיאות מורכבות בהגדלת נפח הפעילות

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

ה-Pod לא מתאים לצומת

תסמינים:

ה-Pods נשארים במצב Pending עם הודעת השגיאה PodUnschedulable, או שבאשכול מוצגת הודעת השגיאה Pods unschedulable, והמידרוג האוטומטי של האשכול לא מגדיל את קנה המידה כדי להוסיף צמתים.

הסיבה:

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

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

פתרון:

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

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

    כניסה לדף Workloads

  2. לוחצים על הודעת השגיאה PodUnschedulable.

  3. בחלונית Details, לוחצים על שם ה-Pod. אם יש כמה Pods, מתחילים עם ה-Pod הראשון וחוזרים על התהליך הבא לכל Pod.

  4. בדף Pod details, לוחצים על הכרטיסייה YAML.

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

    resources:
  limits:
    cpu: "3"
  requests:
    cpu: "2"

  6. מציגים את פרטי מאגר הצמתים מהאשכול עם ה-Pod שלא תזומן:

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

      כניסה לאשכולות של Kubernetes

    2. לוחצים על שם האשכול שבו מופיעה הודעת השגיאה Pods unschedulable.

    3. בדף Cluster details, לוחצים על הכרטיסייה Nodes.

    4. בקטע מאגרי צמתים, שימו לב לערך בעמודה סוג מכונה, לדוגמה n1-standard-1.

  7. משווים בין בקשת המשאבים לבין יחידות ה-vCPU שסוג המכונה מספק. לדוגמה, אם Pod מבקש 2 יחידות vCPU, אבל הצמתים הזמינים משתמשים בסוג המכונה n1-standard-1, לצמתים יש רק יחידת vCPU אחת. בהגדרה כזו, המידרוג האוטומטי של האשכול לא מפעיל הגדלה כי ה-Pod עדיין לא מתאים לצומת חדש. למידע נוסף על סוגי המכונות הזמינים, קראו את המדריך להשוואה בין משפחות של מכונות ומשאבים במאמרי העזרה של Compute Engine.

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

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

מופעי MIG לא הופיעו בזמן

תסמינים:

מופיעה אחת מהודעות השגיאה הבאות:

  • במסוף Google Cloud , ההתראה הבאה מוצגת באשכול:

    Can't scale up because instances in managed instance groups hosting node pools failed to appear in time

  • ב-Logging, האירוע eventResult של הגדלת הנפח מכיל את הודעת השגיאה הבאה:

    scale.up.error.waiting.for.instances.timeout

הסיבה:

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

  • רישום הצומת נכשל: Compute Engine יוצר את הצמתים, אבל הם לא נרשמים במישור הבקרה בגלל אחד או יותר מכללי חומת האש, שינוי שבוצע לאחרונה בגישה לשירותים פרטיים או בקישור VPC לרשתות שכנות (Peering), או בגלל שחסר חשבון שירות של ניהול זהויות והרשאות גישה (IAM).
  • חריגה ממכסות הפרויקט: מכונות חדשות ב-MIG לא מופיעות כי הפרויקט חורג מהמכסה של מעבדים, כתובות IP או משאב אחר.
  • כתובות IP לא זמינות: אין מספיק כתובות IP פנויות ברשת המשנה כדי ליצור צמתים חדשים.
  • תבנית לא תקינה של הגדרות מכונה: קבוצת המכונות המנוהלות משתמשת בתבנית לא תקינה של הגדרות מכונה, כמו תבנית עם תמונה חסרה, שמונעת את הגדלת ההתאמה לעומס.
  • אין מספיק משאבים: באזור אין מספיק משאבי Compute Engine, כמו מעבדי GPU או מעבדי CPU, כדי ליצור צומת חדש.
  • ממשקי API לא נגישים: אין גישה לממשק API נדרש, כמו compute.googleapis.com, בגלל כלל של חומת אש או גבול גישה של VPC Service Controls.
  • זמן האחזור של הרשת: זמן אחזור משמעותי ברשת מעכב את היצירה או את השימוש בצומת חדש.

פתרון:

  1. כדי לזהות את הגורם לזמן הקצוב לתפוגה, מציגים את השגיאות של המכונה ב-MIG ובודקים את התוצאה:

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

    • קבוצת ה-MIG מציגה שגיאות מהזמן שבו אירע הכשל: ‫Compute Engine לא הצליח ליצור את הצמתים. משתמשים בקוד השגיאה ובהודעת השגיאה כדי למצוא את הסיבה בשלב הבא. קודי שגיאה נפוצים:

      • ‫QUOTA_EXCEEDED: חריגה ממכסות הפרויקט
      • ‫IP_SPACE_EXHAUSTED: כתובות IP לא זמינות
      • ‫ZONE_RESOURCE_POOL_EXHAUSTED: אין מספיק משאבים

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

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

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

      • כללי חומת אש: כדי לבדוק אם כלל חומת אש נוצר, עודכן או נמחק לאחרונה, מריצים את השאילתה הבאה ב-Logs Explorer:

        resource.type="gce_firewall_rule"
log_id("cloudaudit.googleapis.com/activity")

        אם שינוי חוסם את התנועה בין הצמתים למישור הבקרה או ל-Google APIs, צריך לעדכן או להחליף את כלל חומת האש. למידע נוסף על הקישוריות הנדרשת, קראו את המאמר דרישות מוקדמות לרישום צומת.

      • חשבון שירות ב-IAM: אם חסר חשבון שירות, עיינו בשורה scale.up.error.service.account.deleted בטבלה שגיאות ב-ScaleUp.

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

      • קישור בין רשתות VPC שכנות (peering): כדי לבדוק אם לאחרונה נוסף, עודכן או הוסר קישור בין רשתות שכנות, מריצים את השאילתה הבאה ב-Logs Explorer לכל פרויקט עם קישור בין רשתות שכנות:

        log_id("cloudaudit.googleapis.com/activity")
resource.type="gce_network"
protoPayload.methodName:("compute.networks.addPeering" OR
"compute.networks.updatePeering" OR
"compute.networks.removePeering")

        אם שינוי בקישור בין רשתות שכנות (peering) שיבש את הקישוריות למישור הבקרה, עדכנו את החיבור בין הרשתות השכנות. אם החיבור נמחק, קראו את המאמר מחיקה בטעות של חיבור VPC Network Peering.

    • חריגה ממכסות הפרויקט: ראו את השורה scale.up.error.quota.exceeded בטבלה שגיאות ב-ScaleUp.

    • כתובות IP לא זמינות: ראו את השורה scale.up.error.ip.space.exhausted בטבלה שגיאות ScaleUp.

    • תבנית לא תקינה של הגדרות מכונה: ראו תבנית הגדרות המכונה לא תקינה במסמכי התיעוד של Compute Engine.

    • אין מספיק משאבים: ראו את השורה scale.up.error.out.of.resources בטבלה שגיאות בהגדלת קנה מידה.

    • ממשקי API לא נגישים: ב-Logs Explorer, מריצים שאילתה כדי לבדוק אם יש פעילות שקשורה לכללים של חומת האש או להיקפים של VPC Service Controls:

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

        resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.disposition="DENIED"

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

      • אם אתם משתמשים ב-VPC Service Controls, בחרו את הארגון שלכם במסוף Google Cloud והריצו את השאילתה הבאה ב-Logs Explorer כדי לבדוק אם לאחרונה נוסף או שונה היקף:

        logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="accesscontextmanager.googleapis.com"

        מחליפים את ORGANIZATION_ID במזהה הארגון.

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

        severity=NOTICE
protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")

        אם גבולות גזרה חדשים או ששונו חוסמים את הגישה לממשקי Google API הנדרשים, אחזרו את השגיאות של VPC Service Controls מיומני הביקורת כדי לזהות את השירות החסום ועדכנו את גבולות הגזרה לשירות כדי לאפשר גישה. למידע נוסף על השימוש ב-Cluster Autoscaler בהיקף, קראו את המאמר Autoscaler not working in perimeters with accessible services and restricted services enabled.

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

אשכולות לא תקינים מונעים סילומיות אנכית (scale up)

תסמינים:

המידרוג האוטומטי של האשכול מפסיק את כל פעולות ההתאמה לעומס, וה-ConfigMap של cluster-autoscaler-status מכיל אירוע מסוג Warning, כשהסיבה שרשומה היא ClusterUnhealthy.

כדי להציג את ה-ConfigMap של cluster-autoscaler-status, מריצים את הפקודה הבאה:

kubectl describe configmap cluster-autoscaler-status -n kube-system

הסיבה:

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

המידרוג האוטומטי של האשכול מתייחס לצומת מוכן כ-NotReady גם כשיש לצומת טאנט עם הקידומת ignore-taint.cluster-autoscaler.kubernetes.io/. המידרוג האוטומטי של האשכול מתייחס לצומת כ-NotReady כל עוד ה-taint הזה קיים.

פתרון:

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

  • בודקים ומתקנים צמתים לא תקינים או צמתים מסוג NotReady, כך שפחות מ-45% מהצמתים באשכול יהיו לא תקינים.
  • אם לצמתים מוכנים יש taint עם הקידומת ignore-taint.cluster-autoscaler.kubernetes.io/, מסירים את ה-taint.

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