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

רגילה

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

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

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

הסבר על המקרים שבהם Cluster Autoscaler מצמצם את מספר הצמתים

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

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

כל 10 שניות, המידרוג האוטומטי באשכול בודק את מקדם הניצול של הצמתים כדי לראות אם הוא מתחת לסף הנדרש. אם אתם משתמשים בbalanced פרופיל של התאמה אוטומטית לעומס, סף מקדם הניצול הוא 0.5. אם אתם משתמשים בפרופיל optimize-utilization, מקדם הניצול משתנה. אם מקדם הניצול נמוך מהסף הנדרש גם ל-vCPU וגם לזיכרון, Cluster Autoscaler מחשיב את הצומת כצומת שלא מנוצל מספיק.

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

דוגמה: חישוב של מקדם הניצול

יש לכם אשכול שמופעל בו Cluster Autoscaler ואתם משתמשים בפרופיל balanced autoscaling. צומת באשכול הזה מוקצה עם סוג המכונה e2-standard-4, שמציע 4 יחידות vCPU ו-16GB של זיכרון. ‫Pod בצומת הזה מבקש 0.5 vCPU ו-10GB זיכרון, ולכן המידרוג האוטומטי של האשכול מחשב את גורמי הניצול הבאים:

• ‫vCPU utilization factor: ‏0.5 vCPU / 4 vCPUs = 0.125
• גורם ניצול הזיכרון: 10GB / 16GB = 0.625

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

האם הבעיה נובעת ממגבלה?

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

הצגת השגיאות

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

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

• אם עדיין לא קיבלתם הודעה, אפשר להשתמש באחת מהאפשרויות הבאות:

  • בעיות שנוצרו לפני פחות מ-72 שעות: אפשר לראות את ההתראות על השגיאות ב Google Cloud מסוף.
  • בעיות שנוצרו לפני יותר מ-72 שעות: הצגת שגיאות באירועים ב-Cloud Logging.

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

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

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

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

   מעבר אל Kubernetes clusters

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

   • Can't scale down nodes
   • Scale down blocked by pod

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

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

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

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

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

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

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

   מעבר אל Kubernetes clusters

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

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

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

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

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

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

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

תרחיש:

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

חקירה:

1. מכיוון שהבעיה התרחשה לפני יותר מ-72 שעות, אתם חוקרים את הבעיה באמצעות Cloud Logging במקום לבדוק את הודעות ההתראה.
2. ב-Cloud Logging, אפשר למצוא את פרטי הרישום ביומן של אירועים שקשורים למידרוג אוטומטי של אשכולות, כמו שמתואר במאמר בנושא הצגת שגיאות באירועים.
3. מחפשים scaleDown אירועים שכוללים את הצמתים ששייכים לאשכול שאתם בודקים בשדה nodesToBeRemoved. אפשר לסנן את הרשומות ביומן, כולל סינון לפי ערך של שדה JSON מסוים. מידע נוסף זמין במאמר שאילתות מתקדמות ביומנים.
4. לא נמצאו אירועים מסוג scaleDown. עם זאת, אם מצאתם אירוע scaleDown, תוכלו לחפש אירוע eventResult שמכיל את eventId המשויך. אחר כך תוכלו לחפש שגיאה בשדה errorMsg.

5. אתם מחליטים להמשיך בחקירה על ידי חיפוש אירועים עם הצומת שאתם חוקרים בשדה הצמתים.noScaleDown

   אתם מוצאים אירוע noScaleDown שמכיל את הסיבה לכך שהצומת לא הצטמצם. מזהה ההודעה הוא "no.scale.down.node.pod.not.backed.by.controller" ויש פרמטר אחד: "test-single-pod".

פתרון:

אתם מעיינים בטבלה של הודעות שגיאה ומגלים שההודעה הזו מציינת ש-Pod חוסם את הפחתת הקיבולת כי הוא לא מגובה על ידי בקר. הבנת שפתרון אחד הוא להוסיף הערה "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ל-Pod. בדקת את test-single-pod וראית שעמית הוסיף את ההערה, ואחרי החלת ההערה, הכלי לשינוי גודל האשכול באופן אוטומטי הקטין את גודל האשכול בצורה נכונה. כדי למנוע את הבעיה בעתיד, החלטתם להוסיף את ההערה לכל שאר ה-Pods שבהם אפשר לעשות זאת בבטחה.

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

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

שגיאות ScaleDown

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

הודעה על אירוע	פרטים	פרמטר	צמצום הפגיעה
"scale.down.error.failed.to.mark.to.be.deleted"	לא ניתן היה לסמן צומת למחיקה.	שם הצומת שנכשל.	ההודעה הזו צריכה להיות זמנית. אם הבעיה נמשכת, אפשר לפנות ל-Cloud Customer Care כדי לבדוק את הבעיה.
"scale.down.error.failed.to.evict.pods"	הכלי לשינוי גודל אוטומטי של אשכולות לא יכול להקטין את גודל האשכול כי לא הייתה אפשרות להוציא חלק מה-Pods מצומת.	שם הצומת שנכשל.	בודקים את PodDisruptionBudget של ה-Pod ומוודאים שהכללים מאפשרים את הוצאת העותקים של האפליקציה כשזה מקובל. מידע נוסף זמין במאמר Specifying a Disruption Budget for your Application (הגדרת תקציב הפרעות לאפליקציה) במסמכי התיעוד של Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached"	אי אפשר להקטין את קנה המידה של Cluster Autoscaler כי לא ניתן למחוק צומת כי גודל האשכול כבר מינימלי.	שם הצומת שנכשל.	בודקים את הערך המינימלי שהוגדר עבור שינוי הגודל האוטומטי של מאגר הצמתים ומשנים את ההגדרות לפי הצורך. מידע נוסף זמין במאמר בנושא שגיאה: הצמתים באשכול הגיעו לגודל המינימלי.

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

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

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

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

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

NoScaleDown node-level reasons

הודעות עם סיבות ברמת הצומת לאירועים מסוג noScaleDown מופיעות ב-noDecisionStatus.noScaleDown.nodes[].reason field. ההודעה מכילה סיבה לכך ש-cluster autoscaler לא יכול להסיר צומת מסוים.

הודעה על אירוע	פרטים	פרמטרים	צמצום הפגיעה
"no.scale.down.node.scale.down.disabled.annotation"	‫Cluster autoscaler לא יכול להסיר צומת ממאגר הצמתים כי הצומת מסומן בהערה עם הערך cluster-autoscaler.kubernetes.io/scale-down-disabled: true.	לא רלוונטי	הכלי Cluster Autoscaler מדלג על צמתים עם ההערה הזו בלי להתחשב בשימוש שלהם, וההודעה הזו נרשמת ביומן בלי קשר לגורם הניצול של הצומת. אם רוצים שהכלי לשינוי גודל אוטומטי של אשכולות יקטין את גודל הצמתים האלה, צריך להסיר את ההערה.
"no.scale.down.node.node.group.min.size.reached"	המידרוג האוטומטי של האשכול לא יכול לצמצם את מספר הצמתים כשהגודל של קבוצת הצמתים חורג מהגודל המינימלי המותר. הסיבה לכך היא שהסרת צמתים תגרום להפרה של מגבלות המינימום על משאבים ברמת האשכול שהוגדרו בהגדרות של הקצאת הצמתים האוטומטית.	לא רלוונטי	בודקים את הערך המינימלי שהוגדר עבור שינוי גודל אוטומטי של מאגר הצמתים. אם רוצים שמנגנון שינוי הגודל האוטומטי של האשכול יקטין את הגודל של הצומת הזה, צריך לשנות את הערך המינימלי.
"no.scale.down.node.minimal.resource.limits.exceeded"	המידרוג האוטומטי של האשכול לא יכול לצמצם את מספר הצמתים כי זה יגרום להפרה של מגבלות המשאבים המינימליות בכל האשכול. אלה מגבלות המשאבים שהוגדרו להקצאת צמתים אוטומטית (NAP).	לא רלוונטי	בודקים את המגבלות של הזיכרון וה-vCPU, ואם רוצים שהמידרוג האוטומטי של האשכול יקטין את הגודל של הצומת הזה, צריך להקטין את המגבלות.
"no.scale.down.node.no.place.to.move.pods"	המידרוג האוטומטי של האשכול לא יכול להקטין את מספר הצמתים כי אין מקום להעביר את ה-Pods.	לא רלוונטי	אם אתם מצפים שה-Pod יתוזמן מחדש, כדאי לבדוק את דרישות התזמון של ה-Pods בצומת שלא נעשה בו שימוש מספיק כדי לקבוע אם אפשר להעביר אותם לצומת אחר באשכול. מידע נוסף זמין במאמר שגיאה: אין מקום להעברת ה-Pods.
"no.scale.down.node.pod.not.backed.by.controller"	ה-Pod חוסם את ההקטנה כי הוא לא מגובה על ידי בקר. באופן ספציפי, כלי ה-Autoscaler של האשכול לא יכול לצמצם את קנה המידה של צומת שלא מנוצל מספיק בגלל Pod שחסר לו בקר מוכר. הבקרה יכולה להתבצע באמצעות ReplicationController,‏ DaemonSet,‏ Job,‏ StatefulSet או ReplicaSet.	השם של ה-Pod שחוסם.	מגדירים את ההערה "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ל-Pod או מגדירים בקר מקובל.
"no.scale.down.node.pod.not.safe.to.evict.annotation"	ל-Pod בצומת יש את ההערה safe-to-evict=false.	השם של ה-Pod שחוסם.	אם אפשר להוציא את ה-Pod בבטחה, עורכים את המניפסט של ה-Pod ומעדכנים את ההערה ל-"cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable"	ה-Pod חוסם את ההקטנה כי הוא לא DaemonSet, לא משוכפל ואין לו PodDisruptionBudget במרחב השמות kube-system.	השם של ה-Pod שחוסם.	בגרסאות GKE קודמות ל-1.32.4-gke.1236000, התאמה אוטומטית של גודל האשכול לא מסירה Pods במרחב השמות kube-system. החל מגרסה 1.32.4-gke.1236000, שינוי הגודל האוטומטי של האשכול לוקח בחשבון את ה-Pods האלה לצורך הסרה אחרי שהם נוצרו למשך שעה אחת. כדי לפתור את הבעיה, צריך להוסיף PodDisruptionBudget ל-Pods של kube-system או להשתמש בשילוב של node pools,‏ taints ו-tolerations כדי להפריד בין ה-Pods של kube-system לבין ה-Pods של האפליקציה. מידע נוסף זמין במאמר בנושא שגיאה: לא ניתן להעביר את הפוד kube-system.
"no.scale.down.node.pod.not.enough.pdb"	ה-Pod חוסם את ההקטנה כי אין לו מספיק PodDisruptionBudget.	השם של ה-Pod שחוסם.	כדאי לבדוק את התקציב להפרעות ב-Pod ולשקול להגדיר אותו בצורה פחות מגבילה. מידע נוסף זמין במאמר בנושא שגיאה: אין מספיק PodDisruptionBudget.
"no.scale.down.node.pod.controller.not.found"	ה-Pod חוסם את ההקטנה כי לא ניתן למצוא את בקר ה-Pod (לדוגמה, Deployment או ReplicaSet).	לא רלוונטי	כדי לגלות אילו פעולות בוצעו והשאירו את ה-Pod פועל אחרי שהוסר הבקר שלו, צריך לעיין ביומנים. כדי לפתור את הבעיה, צריך למחוק את ה-Pod באופן ידני.
"no.scale.down.node.pod.unexpected.error"	ה-Pod חוסם את ההקטנה בגלל שגיאה לא צפויה.	לא רלוונטי	הגורם הבסיסי לשגיאה הזו לא ידוע. פונים ל-Cloud Customer Care להמשך בדיקה.

עריכת בדיקה נוספת

בקטעים הבאים מוסבר איך להשתמש ב-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.down.error.failed.to.delete.node.min.size.reached.

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

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

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

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

• scale.down.error.failed.to.evict.pods
• no.scale.down.node.node.group.min.size.reached

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

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

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

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

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

התראה

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

אירוע

"scale.down.error.failed.to.delete.node.min.size.reached"

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על שם האשכול שזוהה בהתראה או ב-Cloud Logging.

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

4. בודקים את הערך בעמודה מספר הצמתים ומשווים אותו למספר המינימלי של הצמתים שמופיע בעמודה שינוי גודל אוטומטי. לדוגמה, אם בעמודה Autoscaling מופיעים 4 עד 6 צמתים, ומספר הצמתים במאגר הצמתים הוא 4, מספר מאגרי הצמתים כבר שווה לגודל המינימלי, ולכן Cluster Autoscaler לא יכול להקטין את הצמתים יותר.

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

שגיאה: אין מקום להעברת ה-Pods

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

התראה

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

אירוע

"no.scale.down.node.no.place.to.move.pods"

אם לא רוצים לתזמן מחדש את הפוד הזה, ההודעה הזו צפויה ולא צריך לבצע שינויים. אם רוצים לתזמן מחדש את ה-Pod, צריך לבדוק את ההגדרות הבאות ב-pod.spec block במניפסט של ה-Pod:

• ‫NodeAffinity: בודקים את דרישות התזמון של ה-Pods בצומת שלא נעשה בו שימוש מספיק. כדי לבדוק את הדרישות האלה, צריך לבחון את מניפסט ה-Pod ולחפש כללים של NodeAffinity או NodeSelector. אם ה-Pod מוגדר עם nodeSelector ואין צמתים אחרים (ממאגרי צמתים אחרים) באשכול שתואמים לבחירה הזו, לא ניתן להעביר את ה-Pod לצומת אחר, ולכן לא ניתן להסיר צמתים שלא נעשה בהם שימוש מספיק.
• ‫maxPodConstraint: אם maxPodConstraint מוגדר למספר אחר כלשהו, ולא למספר ברירת המחדל 110, צריך לאשר שמדובר בשינוי מכוון. הורדת הערך הזה מגדילה את הסיכוי לבעיות. הכלי לשינוי גודל האשכול לא יכול לתזמן מחדש את ה-Pods לצמתים אחרים, אם כל הצמתים האחרים באשכול כבר הגיעו לערך שמוגדר ב-maxPodConstraint, ולא נשאר מקום לתזמון של Pods חדשים. הגדלת הערך של maxPodConstraint מאפשרת לתזמן יותר Pods בצמתים, ולשנות את התזמון של Pods ולהקטין את מספר הצמתים שלא נעשה בהם שימוש מלא באמצעות Cluster Autoscaler. כשמגדירים את maxPodConstraint, חשוב לזכור שבכל צומת יש בערך 10 פודים של המערכת.
• ‫hostPort: אם מציינים hostPort עבור ה-Pod, רק Pod אחד יכול לפעול בצומת הזה. במצב כזה, יכול להיות שיהיה קשה ל-Cluster Autoscaler להקטין את מספר הצמתים, כי יכול להיות שה-Pod לא יוכל לעבור לצומת אחר אם היציאה של הצומת הזה כבר בשימוש. זה תקין.
• שטח אחסון זמני: פודים מסתמכים על שטח אחסון זמני לנתונים זמניים. אם אין מספיק נפח אחסון זמני בצמתים, יכול להיות שאי אפשר יהיה לתזמן את ה-Pods, ולא תהיה אפשרות להקטין את מספר הצמתים שלא מנוצלים מספיק. דוגמה: אי אפשר לתזמן הפעלה של Pod שדורש 6GB של אחסון זמני בצמתים עם פחות מ-6GB של אחסון זמני פנוי, גם אם יש להם מספיק משאבי CPU וזיכרון. כדי לצמצם את ההשפעה של מגבלות האחסון הזמני, מגדילים את קיבולת האחסון הזמני שהוקצתה לצמתים. כך תוכלו להבטיח שיש מספיק קיבולת להעברה של Pod ולפעולות שינוי גודל.

שגיאה: אי אפשר להעביר את ה-Pod של kube-system

השגיאות הבאות מתרחשות כש-Pod של המערכת מונע את הפחתת הקיבולת:

התראה

ה-Pod חוסם את ההקטנה כי הוא לא DaemonSet, לא משוכפל ו-Pod ללא PodDisruptionBudget במרחב השמות kube-system.

אירוע

"no.scale.down.node.pod.kube.system.unmovable"

‫Pods במרחב השמות kube-system נחשבים ל-Pods של המערכת. ב-GKE בגרסה 1.32.4-gke.1236000 ואילך, הכלי Cluster Autoscaler יכול להקטין את מספר הצמתים על ידי הוצאת Pods של המערכת שפועלים לפחות שעה אחת. בגרסאות קודמות של GKE, התכונה 'שינוי גודל אוטומטי של אשכולות' לא מסירה Pods במרחב השמות kube-system, מה שיכול למנוע הקטנה של האשכול ללא הגבלת זמן.

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

• הוספת PodDisruptionBudget ל-kube-system Pods. מידע נוסף על הוספה ידנית של PodDisruptionBudget ל-Pods של kube-system זמין במאמר שאלות נפוצות בנושא מידרוג אוטומטי של אשכולות Kubernetes.

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

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

הערה: פודים במרחב השמות kube-system חיוניים ל-GKE, ולכן אין לערוך אותם ולא מחויבים עליהם.

אימות שלצמתים יש kube-system Pods

אם אתם לא בטוחים שהצמתים שלכם מריצים kube-system Pods, ואתם רוצים לאמת זאת, אתם צריכים לבצע את השלבים הבאים:

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

   כניסה לדף Logs Explorer

2. לוחצים על Query builder (כלי ליצירת שאילתות).

3. כדי למצוא את כל הרשומות ביומן של מדיניות הרשת, משתמשים בשאילתה הבאה:

   - resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
   jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"
   

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

   • ‫CLUSTER_LOCATION: האזור שבו נמצא האשכול.
   • ‫CLUSTER_NAME: השם של האשכול.
   • ‫PROJECT_ID: מזהה הפרויקט שאליו שייך האשכול.
   • NODE_POOL_NAME: השם של מאגר הצמתים.

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

   "no.scale.down.node.pod.kube.system.unmovable"
   

שגיאה: אין מספיק PodDisruptionBudget

השגיאות הבאות מתרחשות כשה-PodDisruptionBudget מונע את הקטנת הקיבולת:

התראה

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

אירוע

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

כדי לבדוק אם PodDisruptionBudget מגביל מדי, צריך לעיין בהגדרות שלו:

kubectl get pdb --all-namespaces

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

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

בדוגמה הזו, כל ה-Pods שתואמים לבורר התוויות two_pdb לא יסולקו על ידי הכלי לשינוי גודל האשכול. ההגדרה maxUnavailable: 0 בPodDisruptionBudget קובעת שכל העותקים צריכים להיות זמינים בכל רגע. בנוסף, disruptionsAllowed: 0 אוסר על שיבושים ב-Pods האלה. לכן, אי אפשר להקטין את קנה המידה של הצמתים שבהם פועלים ה-Pods האלה, כי פעולה כזו תגרום להפרעה ותפר את PodDisruptionBudget.

אם PodDisruptionBudget פועל כמו שאתם רוצים, אתם לא צריכים לבצע פעולות נוספות. כדי לשנות את PodDisruptionBudget כך שאפשר יהיה להעביר את ה-Pods בצומת שלא נעשה בו שימוש מלא, צריך לערוך את המניפסט של PodDisruptionBudget. לדוגמה, אם הגדרתם את maxUnavailable ל-0, תוכלו לשנות אותו ל-1 כדי שהמידרוג האוטומטי באשכול יוכל לצמצם את מספר הצמתים.

בעיה: הצומת נשאר בסטטוס 'הוסגר' ולא מוסר

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

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

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

כדי לפתור את הבעיה הזו, צריך לבדוק אם לחשבון השירות שמוגדר כברירת מחדל ([e-mail]) יש את התפקיד 'עריכה' (roles/editor) בפרויקט. אם לחשבון השירות אין את התפקיד הזה, צריך להוסיף אותו. ‫GKE משתמש בחשבון השירות הזה כדי לנהל את המשאבים של הפרויקט. למידע נוסף, ראו איך נותנים או מבטלים תפקידים בודדים במסמכי ה-IAM.

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

• כדאי לעיין בשאלות הבאות בשאלות הנפוצות בנושא מידרוג אוטומטי של אשכולות Kubernetes:

  • איך מצמצמים את מספר המכונות?
  • האם המידרוג האוטומטי של האשכול פועל עם PodDisruptionBudget בהקטנת מספר הרפליקות?
  • אילו סוגים של Pods יכולים למנוע מ-Cluster Autoscaler להסיר צומת?

• כאן אפשר לצפות בסרטון ב-YouTube על פתרון בעיות שקשורות לשינוי גודל.

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

  • פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
  • קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
  • פתיחת דיווחים על בעיות או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.