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

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

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

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

מתי הכלי Cluster Autoscaler מגדיל את מספר הצמתים

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

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

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

בדיקה אם יש לכם Pods שלא ניתן לתזמן

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

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

    כניסה לדף Workloads

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

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

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

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

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

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

    כניסה לדף Logs Explorer

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

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

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

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

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

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

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

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

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

לרוב אפשר לאבחן את הסיבה לבעיות בהרחבת הקיבולת על ידי עיון בהודעות השגיאה:

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

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

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

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

    מעבר אל Kubernetes clusters

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

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

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

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

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

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

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

כדי לראות את היומנים של שינוי הגודל האוטומטי של האשכול במסוף Cloud de Confiance :

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

    מעבר אל Kubernetes clusters

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

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

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

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

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

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

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

תרחיש: בשעה האחרונה, Pod סומן כ-Pod שלא ניתן לתזמן. המידרוג האוטומטי של האשכול לא הקצה צמתים חדשים כדי לתזמן את ה-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, וכל ה-MIGs בשדה rejectedMigs כוללים את אותו מזהה של הודעת סיבה "no.scale.up.mig.failing.predicate" עם שני פרמטרים: "NodeAffinity" ו-"node(s) did not match node selector".

פתרון:

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

כדי לפתור את הבעיה, בודקים את המניפסט של ה-Pod ומגלים שיש בו בורר צמתים שלא תואם לאף MIG באשכול. מוחקים את הסלקטור מהמניפסט של ה-Pod ויוצרים מחדש את ה-Pod. הכלי Cluster Autoscaler מוסיף צומת חדש וה-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 שנכשלו. בודקים בכרטיסייה שגיאות של ה-MIG במסוף Cloud de Confiance כדי לראות איזו מכסה נחצתה. אחרי שמגלים איזו מכסה חורגת מהמגבלה, פועלים לפי ההוראות לבקשה להגדלת מכסה.
"scale.up.error.waiting.for.instances.timeout" הגדלת קבוצת המופעים המנוהלת נכשלה בגלל פסק זמן. מזהי ה-MIG שנכשלו. אם המופעים מופעלים אבל לא נרשמים במישור הבקרה, פועלים לפי השלבים לפתרון בעיות ברישום מופעים. ההודעה הזו אמורה להיות זמנית.
"scale.up.error.ip.space.exhausted" אי אפשר להגדיל את הקיבולת כי למכונות וירטואליות בחלק מקבוצות המכונות הווירטואליות המנוהלות אין יותר כתובות IP. המשמעות היא שאין מספיק מקום בטווח כתובות ה-IP שלא הוקצו באשכול כדי להוסיף צמתים או פודים חדשים. מזהי ה-MIG שנכשלו. פועלים לפי השלבים לפתרון בעיות במאמר בנושא אין מספיק מקום פנוי לכתובות IP עבור Pods.
"scale.up.error.service.account.deleted" אי אפשר להגדיל את הקיבולת כי חשבון השירות נמחק. מזהי ה-MIG שנכשלו. אפשר לנסות לבטל את המחיקה של חשבון השירות.

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

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

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

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

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

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

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

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

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

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

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

סיבות ברמת ה-MIG לביטול ההרחבה

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

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

סיבות ל-NoScaleUp בהקצאת צמתים אוטומטית ברמת קבוצת ה-Pod

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

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

לבדוק את העניין לעומק

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

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

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

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

    כניסה לדף 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 הוא כלי בקוד פתוח שנוצר בתמיכת מהנדסים טכניים של Cloud de Confiance by S3NS. הוא לא מוצר Cloud de Confiance by S3NS נתמך רשמית.

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

הסיבה:

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

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

פתרון:

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

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

    כניסה לדף Workloads

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

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

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

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

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

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

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

      מעבר אל Kubernetes clusters

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

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

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

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

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

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

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

תסמינים:

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

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

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

הסיבה:

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

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

פתרון:

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

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

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