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

רגילה

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

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

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

הודעות עם סיבות ברמת הצומת לאירועים מסוג 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 חוסם את ההקטנה כי הוא לא מגובה על ידי בקר. באופן ספציפי, כלי המידרוג האוטומטי של האשכול לא יכול לצמצם את הגודל של צומת לא מנוצל בגלל 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 ל-Pod‏ kube-system או להשתמש בשילוב של node pools,‏ taints ו-tolerations כדי להפריד בין ה-Pod‏ 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.

אירוע

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

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

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

   מעבר אל Kubernetes clusters

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

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

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

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

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

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

התראה

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

אירוע

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

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

• ‫NodeAffinity: בודקים את דרישות התזמון של ה-Pods בצומת שלא נעשה בו שימוש מספיק. כדי לבדוק את הדרישות האלה, צריך לבחון את מניפסט ה-Pod ולחפש כללים של NodeAffinity או NodeSelector. אם הוגדר nodeSelector ל-Pod ואין צמתים אחרים (ממאגרי צמתים אחרים) באשכול שתואמים לבחירה הזו, לא ניתן להעביר את ה-Pod לצומת אחר, ולכן לא ניתן להסיר צמתים שלא נעשה בהם שימוש מלא.
• ‫maxPodConstraint: אם maxPodConstraint מוגדר למספר אחר כלשהו, ולא למספר ברירת המחדל 110, צריך לאשר שמדובר בשינוי מכוון. הורדת הערך הזה מגדילה את הסיכוי לבעיות. המידרוג האוטומטי של האשכול לא יכול לתזמן מחדש את ה-Pods לצמתים אחרים, אם כל הצמתים האחרים באשכול כבר הגיעו לערך שמוגדר ב-maxPodConstraint, ולא נשאר מקום לתזמון של Pods חדשים. הגדלת הערך של maxPodConstraint מאפשרת לתזמן יותר Pods בצמתים, ומידרוג אוטומטי של האשכול יאפשר מקום לתזמן מחדש Pods ולהקטין את מספר הצמתים שלא נעשה בהם שימוש מלא. כשמגדירים את 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. מידע נוסף על הוספה ידנית של PodDisruptionBudget ל-Pods של kube-system זמין במאמר שאלות נפוצות בנושא מידרוג אוטומטי של אשכולות Kubernetes.

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

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