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

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

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

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

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

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

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

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

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

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

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

    כניסה לדף Workloads

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

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

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

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

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

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

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

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

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

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

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

פתרון שגיאות בהרחבת הקיבולת

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

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

שגיאות ב-ScaleUp

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

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

הודעה פרטים פרמטרים צמצום הפגיעה
"scale.up.error.out.of.resources" שגיאות שקשורות למשאבים מתרחשות כשמנסים לבקש משאבים חדשים בתחום שאין בו מקום לבקשה, בגלל חוסר זמינות של משאב Compute Engine, כמו יחידות GPU או מעבדים. מזהי ה-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 מתרחש מדי פעם כשיש פודים שלא ניתן לתזמן באשכול, וכלי הגידול האוטומטי של האשכול לא יכול להגדיל את האשכול כדי לתזמן את הפודים. אירועי noScaleUp הם הפעולה שתביא לתוצאות הטובות ביותר, אבל הם לא כוללים את כל המקרים האפשריים.

הסיבות הנפוצות ביותר לירידה

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

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

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

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

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

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

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

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

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

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

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

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

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

הודעה פרטים פרמטרים צמצום הפגיעה
"no.scale.up.nap.pod.gpu.no.limit.defined" הקצאת הצמתים האוטומטית לא הצליחה להקצות אף קבוצת צמתים כי ל-Pod בהמתנה יש בקשה ל-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" הקצאת משאבים אוטומטית של צמתים לא הקצתה קבוצת צמתים ל-Pod באזור הזה, כי פעולה כזו תגרום להפרה של מגבלות המשאבים המקסימליות ברמת האשכול, לחריגה מהמשאבים הזמינים באזור או כי אין סוג מכונה שיכול להתאים לבקשה. שם האזור שנבדק. בודקים ומעדכנים את מגבלות המשאבים המקסימליות ברמת האשכול, את בקשות המשאבים של ה-Pod או את האזורים הזמינים להקצאת צמתים אוטומטית (NAP).
"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 בצומת רק אם יש צומת עם מספיק משאבים כמו GPUs, זיכרון ואחסון כדי לעמוד בדרישות של ה-Pod. כדי לבדוק אם זו הסיבה לכך שהמידרוג האוטומטי של האשכול לא התרחב, צריך להשוות בין בקשות המשאבים לבין המשאבים שסופקו.

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

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

    כניסה לדף Workloads

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

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

  4. בדף הפרטים של ה-Pod, עוברים לכרטיסייה אירועים.

  5. בכרטיסייה אירועים, עוברים לכרטיסייה YAML.

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

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

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

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

      מעבר אל Kubernetes clusters

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

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

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

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

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

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

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

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

אם זו הסיבה לכך שהמידרוג האוטומטי באשכול לא מתבצע, יש אירוע ב-ConfigMap של המידרוג האוטומטי באשכול עם הסוג Warning והסיבה ClusterUnhealthy.

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

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

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

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

אם ההתנהגות נגרמת בגלל נוכחות של ignore-taint.cluster-autoscaler.kubernetes.io/.* taint, מסירים אותו.

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