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

Standard

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

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

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

מתי Cluster Autoscaler מצמצם את מספר הצמתים

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

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

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

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

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

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

• גורם ניצול ה-vCPU: ‎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. בדף Cluster details, לוחצים על הכרטיסייה Logs.

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

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

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

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

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

תרחיש:

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

בדיקה:

1. הבעיה התרחשה לפני יותר מ-72 שעות, ולכן צריך לחקור אותה באמצעות Cloud Logging במקום לבדוק את הודעות ההתראה.
2. ב-Cloud Logging אפשר למצוא את פרטי הרישום ביומן של אירועים של שינוי גודל אוטומטי של אשכול, כמו שמתואר במאמר בנושא הצגת שגיאות באירועים.
3. בשדה nodesToBeRemoved מחפשים scaleDown אירועים שמכילים את הצמתים ששייכים לאשכול שאתם בודקים. אפשר לסנן את הרשומות ביומן, כולל סינון לפי ערך מסוים של שדה 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 מצומת.	שם הצומת שנכשל.	בודקים את התקציב להפרעות ב-Pod ומוודאים שהכללים מאפשרים פינוי של רפליקות של האפליקציה כשזה מקובל. מידע נוסף זמין במאמר הגדרת תקציב שיבושים לאפליקציה במסמכי התיעוד של Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached"	אי אפשר להקטין את קנה המידה של האשכול כי לא ניתן למחוק צומת בגלל שהאשכול כבר בגודל המינימלי.	שם הצומת שנכשל.	בודקים את הערך המינימלי שהוגדר להתאמה אוטומטית לעומס של מאגר הצמתים, ומשנים את ההגדרות לפי הצורך. מידע נוסף זמין במאמר שגיאה: הצמתים באשכול הגיעו לגודל המינימלי.

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

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

הסיבות העיקריות ל-NoScaleDown

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

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

סיבות ברמת הצומת ל-NoScaleDown

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

הודעה על אירוע	פרטים	פרמטרים	צמצום הפגיעה
"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"	אי אפשר להקטין את מספר הצמתים באמצעות Cluster Autoscaler אם גודל קבוצת הצמתים חורג מהגודל המינימלי. הסיבה לכך היא שהסרת צמתים תגרום להפרה של מגבלות המשאבים המינימליות בכל האשכול שהוגדרו בהגדרות של הקצאת הצמתים באופן אוטומטי.	לא רלוונטי	בודקים את הערך המינימלי שהוגדר להתאמה אוטומטית לעומס של מאגר הצמתים. אם רוצים שהכלי לשינוי גודל האשכול ישנה את גודל הצומת הזה, צריך לשנות את הערך המינימלי.
"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 חוסם את ההקטנה כי אין לו גיבוי של בקר. באופן ספציפי, שינוי הגודל האוטומטי של האשכול לא יכול להקטין את הגודל של צומת שלא מנוצל מספיק בגלל 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, לא משוכפל, Pod ללא PodDisruptionBudget במרחב השמות kube-system.	השם של ה-Pod החוסם.	בגרסאות GKE קודמות ל-1.32.4-gke.1236000, התאמה אוטומטית של גודל האשכול לא מסירה Pods במרחב השמות kube-system. החל מגרסה 1.32.4-gke.1236000, המערכת לשינוי גודל האשכול באופן אוטומטי שוקלת להסיר את ה-Pods האלה אחרי שהם נוצרו למשך שעה אחת. כדי לפתור את הבעיה, אפשר להוסיף PodDisruptionBudget ל-Pods של kube-system או להשתמש בשילוב של taints ו-tolerations של מאגרי צמתים כדי להפריד בין ה-Pods של kube-system לבין ה-Pods של האפליקציה. מידע נוסף זמין במאמר בנושא שגיאה: לא ניתן להעביר את הפוד kube-system.
"no.scale.down.node.pod.not.enough.pdb"	ה-Pod חוסם את הקטנת קנה המידה כי אין לו מספיק PodDisruptionBudget.	שם ה-Pod שחוסם.	בודקים את PodDisruptionBudget של ה-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 נתמך רשמית.

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

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

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

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

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

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

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

התראה

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

אירוע

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

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

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

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

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

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

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

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

שגיאה: אין לאן להעביר את הפודים

השגיאות הבאות מתרחשות כשכלי לשינוי גודל האשכול מנסה להקטין את גודל הצומת, אבל לא מצליח כי אי אפשר להעביר את ה-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 בצמתים, ול-cluster autoscaler יהיה מקום לתזמן מחדש את ה-Pods ולצמצם את מספר הצמתים שלא נעשה בהם שימוש מלא. כשמגדירים את maxPodConstraint, חשוב לזכור שבכל צומת יש בערך 10 פודים של המערכת.
• ‫hostPort: אם מציינים hostPort ל-Pod, רק Pod אחד יכול לפעול בצומת הזה. במצב כזה, יכול להיות שיהיה קשה להקטין את מספר הצמתים באמצעות Cluster Autoscaler, כי יכול להיות שאי אפשר יהיה להעביר את ה-Pod לצומת אחר אם היציאה של הצומת הזה כבר בשימוש. זה תקין.
• אחסון זמני: פודים מסתמכים על אחסון זמני לנתונים זמניים. נפח אחסון זמני לא מספיק בצמתים עלול להפריע לתזמון של Pod ולמנוע את הקטנת מספר הצמתים שלא מנוצלים מספיק. דוגמה: אי אפשר לתזמן Pod שדורש 6GB של אחסון זמני בצמתים עם פחות מ-6GB של אחסון זמני פנוי, גם אם יש להם מספיק משאבי CPU וזיכרון. כדי לצמצם את ההשפעה של מגבלות האחסון הזמני, מגדילים את קיבולת האחסון הזמני שהוקצתה לצמתים. כך תוכלו להבטיח שיש מספיק קיבולת להעברה של Pod ולפעולות שינוי גודל.

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

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

התראה

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

אירוע

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

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

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

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

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

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

• כדי להפריד בין פודים של kube-system לבין פודים של האפליקציה, משתמשים ב-taints וב-tolerations של מאגר הצמתים (לדוגמה, workload=stateful:NoSchedule). אנחנו ממליצים על הגישה הזו לעומסי עבודה של קבוצות או לעומסי עבודה עם מצב (stateful), כדי למנוע את בעיית העיכוב המצטבר על ידי השבתת kube-systemתרמילי ה-Pod בצמתים האלה. הגישה הזו מאפשרת לצמצם את הצמתים בלי לחסום אותם. מידע נוסף זמין במאמר הקצאת צמתים אוטומטית ב-GKE.

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

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

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

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

   כניסה לדף Logs Explorer

2. לוחצים על הכלי ליצירת שאילתות.

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

   - 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

בדוגמה הזו, לא תתבצע העברה של אף Pod שתואם לסלקטור התוויות two_pdb על ידי שינוי הגודל האוטומטי של האשכול. ההגדרה maxUnavailable: 0 ב-PodDisruptionBudget הזה קובעת שכל הרפליקות חייבות להיות זמינות כל הזמן. בנוסף, disruptionsAllowed: 0 אוסרת על כל שיבוש של הפודים האלה. כתוצאה מכך, אי אפשר להקטין את קנה המידה של הצמתים שבהם פועלים ה-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 כדי לקבל תמיכה מהקהילה.
  • דיווח על בעיות או שליחת בקשות להוספת תכונות באמצעות הכלי הציבורי Issue Tracker.