מידע על התאמה אוטומטית לעומס (autoscaling) באשכולות GKE

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

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

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

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

שיטה מומלצת:

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

למה כדאי להשתמש במידרוג אוטומטי של אשכולות

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

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

שיטה מומלצת:

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

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

איך פועל המידרוג האוטומטי של האשכול

התאמה לעומס (autoscaling) באשכול פועלת לכל מאגר צמתים. כשמגדירים מאגר צמתים עם Cluster Autoscaler, מציינים את הגודל המינימלי והמקסימלי של מאגר הצמתים.

המידרוג האוטומטי של האשכול מגדיל או מקטין את הגודל של מאגר הצמתים באופן אוטומטי על ידי הוספה או הסרה של מופעי מכונה וירטואליים (VM) בקבוצת מופעי מכונה מנוהלים (MIG) של Compute Engine שמשמשת כבסיס למאגר הצמתים. הכלי Cluster Autoscaler מקבל את ההחלטות האלה לגבי שינוי הגודל על סמך בקשות המשאבים (ולא על סמך ניצול המשאבים בפועל) של ה-Pods שפועלים בצמתים של מאגר הצמתים הזה. הוא בודק מעת לעת את הסטטוס של ה-Pods והצמתים, ופועל לפי הצורך:

  • אם לא ניתן לתזמן את הפודים באף אחד מהצמתים הנוכחיים, הכלי לשינוי גודל האשכול מוסיף צמתים, עד לגודל המקסימלי של מאגר הצמתים. מידע נוסף על המקרים שבהם המידרוג האוטומטי באשכול משנה את הגודל של אשכול זמין במאמר מתי המידרוג האוטומטי באשכול משנה את הגודל של אשכול?
  • אם GKE מחליט להוסיף צמתים חדשים למאגר הצמתים, הכלי להתאמה אוטומטית של גודל האשכול מוסיף כמה צמתים שצריך, עד למגבלות של כל מאגר צמתים או של כל אשכול.
  • המידרוג האוטומטי של האשכול לא מחכה עד שצומת אחד יופעל לפני שהוא יוצר את הצומת הבא. אחרי ש-GKE מחליט כמה צמתים ליצור, יצירת הצמתים מתבצעת במקביל. המטרה היא לצמצם את הזמן שנדרש כדי ש-Pods שלא ניתן לתזמן יהפכו ל-Active.
  • אם חלק מהצמתים לא נוצרו בגלל מיצוי המכסה, Cluster Autoscaler ימתין עד שניתן יהיה לתזמן את המשאבים בהצלחה.
  • אם הצמתים לא מנוצלים מספיק, ואפשר לתזמן את כל ה-Pods גם עם פחות צמתים במאגר הצמתים, Cluster Autoscaler מסיר צמתים, עד לגודל המינימלי של מאגר הצמתים.
  • אם יש פודים בצומת שלא ניתן להעביר לצמתים אחרים באשכול, המידרוג האוטומטי של האשכול לא ינסה להקטין את הצומת הזה.
  • אם אפשר להעביר את ה-Pods לצמתים אחרים, אבל אי אפשר לנקז את הצומת בצורה תקינה אחרי זמן קצוב לתפוגה, הצומת יופסק בכוח. תקופת הזמן הקצובה הזו היא שעה אחת בגרסאות GKE‏ ‎1.32.7-gke.1079000 ואילך, ו-10 דקות בגרסאות GKE מוקדמות יותר. אי אפשר להגדיר את תקופת החסד המקסימלית עבור אשכולות GKE. מידע נוסף על אופן הפעולה של הקטנת הקיבולת זמין במאמר איך הקטנת הקיבולת פועלת? בשאלות הנפוצות בנושא שינוי אוטומטי של גודל האשכול במסמכי התיעוד של קוד פתוח.

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

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

אל תפעילו התאמה אוטומטית לעומס של Compute Engine עבור קבוצות של מופעי מכונה מנוהלים בצמתי האשכול. המידרוג האוטומטי של אשכולות ב-GKE הוא נפרד מהמידרוג האוטומטי של Compute Engine. זה יכול לגרום לכך שמאגרי הצמתים לא יצליחו להתרחב או להתכווץ, כי שינוי הגודל האוטומטי של Compute Engine יתנגש עם שינוי הגודל האוטומטי של האשכול ב-GKE.

קריטריונים להפעלה

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

  • אפשר להפעיל מחדש את כל ה-Pods המשוכפלים בצומת אחר, מה שעלול לגרום לשיבוש קצר.
  • משתמשים או אדמינים לא מנהלים צמתים באופן ידני. המידרוג האוטומטי של האשכול יכול לבטל פעולות ידניות לניהול צמתים שאתם מבצעים.
  • לכל הצמתים במאגר צמתים יחיד יש את אותו סט של תוויות.
  • הכלי לשינוי גודל האשכול באופן אוטומטי מתחשב בעלות היחסית של סוגי המופעים במאגרי הצמתים השונים, ומנסה להרחיב את מאגר הצמתים הכי זול שאפשר. עם זאת, התנאים הבאים חלים על ההתנהגות הזו של שינוי הגודל האוטומטי של האשכול:
    • הכלי Cluster Autoscaler לשינוי גודל האשכול באופן אוטומטי לוקח בחשבון את העלות המופחתת של מאגרי צמתים שמכילים מכונות וירטואליות מסוג Spot, שאפשר להפסיק את השימוש בהן. עם זאת, הכלי לשינוי גודל האשכול באופן אוטומטי לוקח בחשבון גם את זמינות המשאבים בכל אזור, ויכול לבחור במשאב יקר יותר אבל זמין.
    • כשכמה מאגרי צמתים משתמשים במכונות וירטואליות מסוג Spot, הכלי Cluster Autoscaler לא בוחר אוטומטית באפשרות הכי זולה. כדי לייעל את השימוש במכונות Spot VM חסכוניות ולמנוע את התרחיש הזה, מומלץ להשתמש בסוגי מחשוב בהתאמה אישית.
  • הכלי לשינוי גודל האשכול מתחשב בבקשות של קונטיינר ההפעלה לפני תזמון הפודים. בקשות של קובצי init container יכולות להשתמש בכל המשאבים שלא הוקצו שזמינים בצמתים, מה שיכול למנוע תזמון של Pods. המידרוג האוטומטי של האשכול פועל לפי אותם כללי חישוב של בקשות שבהם משתמש Kubernetes. מידע נוסף זמין במאמר בנושא שימוש ב-init containers ב-Kubernetes.
  • תוויות שנוספו באופן ידני אחרי היצירה הראשונית של אשכול או מאגר צמתים לא נכללות במעקב. לצמתים שנוצרים על ידי התכונה לשינוי גודל האשכול באופן אוטומטי מוקצות תוויות שצוינו באמצעות --node-labels בזמן יצירת מאגר הצמתים.
  • ב-GKE בגרסה 1.21 או בגרסאות קודמות, המידרוג האוטומטי של האשכול מתייחס למידע על ההכתמה של הצמתים הקיימים ממאגר צמתים כאל ייצוג של מאגר הצמתים כולו. החל מגרסה 1.22 של GKE, הכלי לשינוי גודל האשכול משלב מידע מצמתים קיימים באשכול וממאגר הצמתים. הכלי Cluster Autoscaler מזהה גם את השינויים הידניים שאתם מבצעים בצומת ובמאגר הצמתים.
שיטה מומלצת:

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

איזון בין אזורים

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

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

מדיניות המיקומים

החל מגרסה 1.24.1-gke.800 של GKE, אפשר לשנות את מדיניות המיקום של הכלי להתאמה אוטומטית של גודל האשכול. אפשר לשלוט במדיניות ההפצה של התכונה 'שינוי גודל אוטומטי של אשכולות' על ידי ציון האפשרות location_policy עם אחד מהערכים הבאים:

  • ‫BALANCED: המדיניות הזו מנחה את הכלי לשינוי גודל האשכול לחלק את משאבי מאגר הצמתים בין האזורים שנבחרו בצורה שווה ככל האפשר, תוך התחשבות בדרישות של ה-Pod (כמו קרבה) ובזמינות המשאבים. המדיניות הזו היא מדיניות המיקום שמוגדרת כברירת מחדל למאגרי צמתים שמשתמשים בהזמנות או בצמתים על פי דרישה, אבל אפשר להשתמש בה גם במכונות וירטואליות מסוג Spot. אין תמיכה ב-BALANCED במאגרי צמתים במצב הקצאת משאבים עם התחלה גמישה.
  • ‫ANY: המדיניות הזו מורה למנגנון לשינוי גודל האשכול לחפש את הקיבולת הנדרשת בכל האזורים שצוינו. הכלי לשינוי גודל האשכול באופן אוטומטי נותן עדיפות לשימוש במשאבים ששוריינו ולא בשימוש ולאזורים עם מספיק קיבולת, מה שעלול להוביל לריכוז של משאבים במאגר הצמתים. זוהי מדיניות המיקום שמוגדרת כברירת מחדל למצב הקצאת משאבים עם התחלה גמישה ולמאגרי צמתים שמשתמשים במכונות וירטואליות מסוג Spot, אבל אפשר להשתמש בה גם למאגרי צמתים שמשתמשים בהזמנות או בצמתים על פי דרישה. כדי שהמדיניות הזו תפעל, צריך להפעיל את ההתאמה האוטומטית לעומס ולהגדיר את המספר ההתחלתי של הצמתים ל-0, כדי שהמידרוג האוטומטי יהיה אחראי להקצאת כל הצמתים.
שיטה מומלצת:

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

הזמנות

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

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

ערכי ברירת מחדל

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

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

גודל מינימלי ומקסימלי של מאגר צמתים

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

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

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

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

איך GKE מטפל במגבלות על גודל הגבול

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

בטבלה הבאה מוסבר איך GKE מטפל בתנאי הגבול האלה:

תנאי גבול מה המידרוג האוטומטי לא עושה מה עושה המידרוג האוטומטי תרחיש נפוץ להפעלת טריגר
הגודל הנוכחי נמוך מהמינימום (לדוגמה, current = 1, min = 3) לא מתרחב אוטומטית כדי להגיע למינימום. ההגדלה מתבצעת רק כשצריך משאבים עבור Pods שלא ניתן לתזמן (בהמתנה). הפעלת שינוי גודל אוטומטי כשערך השדה --min-nodes מוגדר כגבוה יותר מגודל מאגר הצמתים הנוכחי.
הגודל הנוכחי גדול מהגודל המקסימלי (לדוגמה, current = 10, max = 5) לא מסיימת באופן מיידי את הפעולה של הצמתים כדי לעמוד במגבלה המקסימלית. ההקטנה מתבצעת רק כשאין מספיק ניצול של הצמתים ואפשר לנקז אותם בבטחה. הפעלת שינוי גודל אוטומטי כשהערך של השדה --max-nodes מוגדר כנמוך יותר מגודל מאגר הצמתים הנוכחי.

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

מגבלות על התאמה אוטומטית לעומס

אפשר להגדיר את המספר המינימלי והמקסימלי של צמתים שבהם הכלי Cluster Autoscaler ישתמש כשמבצעים שינוי גודל של מאגר צמתים. משתמשים בדגלים --min-nodes ו---max-nodes כדי להגדיר את המספר המינימלי והמקסימלי של הצמתים בכל אזור.

החל מגרסה 1.24 של GKE, אפשר להשתמש בדגלים --total-min-nodes ו---total-max-nodes באשכולות חדשים. הדגלים האלה מגדירים את המספר המינימלי והמקסימלי של הצמתים במאגר הצמתים בכל האזורים.

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

דוגמה למינימום ולמקסימום של צמתים

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

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

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

דוגמה לחישוב סך כל הצמתים

הפקודה הבאה, שזמינה ב-GKE בגרסה 1.24 ואילך, יוצרת אשכול רב-אזורי עם שינוי גודל אוטומטי, עם שישה צמתים בשלושה אזורים בהתחלה, עם מינימום של שלושה צמתים ומקסימום של 12 צמתים במאגר הצמתים בכל האזורים:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

בדוגמה הזו, הגודל הכולל של האשכול יכול להיות בין שלושה ל-12 צמתים, ללא קשר לפיזור בין אזורים.

פרופילים של התאמה אוטומטית לעומס

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

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

  • ‫balanced: פרופיל ברירת המחדל שנותן עדיפות לשמירת יותר משאבים שזמינים בקלות לפודים נכנסים, וכך מקצר את הזמן שנדרש כדי שהם יהיו פעילים באשכולות רגילים. פרופיל balanced לא זמין לאשכולות של Autopilot.
  • ‫optimize-utilization: מתן עדיפות לאופטימיזציה של הניצול על פני שמירה של משאבים עודפים באשכול. כשמפעילים את הפרופיל הזה, הכלי לשינוי גודל האשכול מקטין את האשכול בצורה אגרסיבית יותר. ‫GKE יכול להסיר יותר צמתים, ולהסיר צמתים מהר יותר. מערכת GKE מעדיפה לתזמן Pods בצמתים שכבר יש בהם הקצאה גבוהה של מעבד, זיכרון או מעבדי GPU. עם זאת, יש גורמים אחרים שמשפיעים על התזמון, כמו פיזור של Pods ששייכים לאותו Deployment, ‏ StatefulSet או Service, בין הצמתים.

optimize-utilization פרופיל ההתאמה האוטומטית לעומס עוזר למידרוג האוטומטי של האשכול לזהות ולהסיר צמתים שלא נעשה בהם שימוש מספיק. כדי לבצע את האופטימיזציה הזו, GKE מגדיר את שם המתזמן במפרט של ה-Pod ל-gke.io/optimize-utilization-scheduler. אין השפעה על פודים שבהם מוגדר מתזמן בהתאמה אישית.

הפקודה הבאה מפעילה את פרופיל ההתאמה האוטומטית לעומס optimize-utilization באשכול קיים:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

שיקולים לגבי תזמון של Pod והפרעות

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

  • כללי הזיקה או האנטי-זיקה של ה-Pod מונעים תזמון מחדש.
  • ה-Pod לא מנוהל על ידי Controller כמו Deployment, ‏ StatefulSet, ‏ Job או ReplicaSet.
  • ל-Pod יש אחסון מקומי וגרסת מישור הבקרה של GKE נמוכה מ-1.22. באשכולות GKE עם מישור בקרה בגרסה 1.22 ואילך, פודים עם אחסון מקומי לא חוסמים יותר את הקטנת קנה המידה.
  • ל-Pod יש את ההערה "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • מחיקת הצומת תחרוג מPodDisruptionBudget שהוגדר.

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

סדר הוצאת ה-Pods במהלך הקטנת הקיבולת

במהלך פעולת הקטנת קנה מידה של צומת, המידרוג האוטומטי של האשכול מקבץ את ה-Pods לשתי רמות עדיפות על סמך הערך PriorityClass שלהם. מערכת GKE מפנה Pods בכל רמה במקביל, בסדר הבא:

  1. רמה בעדיפות נמוכה יותר (ערך נמוך מ-1000000000): הכלי לשינוי גודל האשכול מפנה את ה-Pods האלה קודם וממתין עד שעה להשלמת הפינוי.
  2. רמת עדיפות גבוהה יותר (ערך גדול מ- או שווה ל-1000000000): המערכת להתאמה אוטומטית של גודל האשכול מפנה את ה-Pods האלה רק אחרי שכל ה-Pods ברמת עדיפות נמוכה יותר מסתיימים, וממתינה עד 10 דקות עד שהפינוי מסתיים. ב-GKE, ‏ 1000000000 הוא הערך הכי גבוה שאפשר להקצות לPriorityClass בהתאמה אישית. ערכים שגדולים מ-1000000000 שמורים למחלקות עדיפות מובנות של המערכת.

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

עיכוב מחיקת צומת באמצעות הערות לצומת

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

כדי להשהות זמנית את מחיקת הצומת, מוסיפים לצומת הערה אחת או יותר עם הקידומת delay-deletion.cluster-autoscaler.kubernetes.io/. כשהמידרוג האוטומטי של האשכול מכוון לצומת לצורך הקטנת קנה המידה, המידרוג האוטומטי מסמן את הצומת ומתחיל את תהליך הניקוז. אם הכלי לשינוי גודל האוטומטי של האשכול מזהה הערה עם הקידומת delay-deletion.cluster-autoscaler.kubernetes.io/ בצומת, הכלי משעה את השלב הסופי של מחיקת מכונת ה-VM. המחיקה נשארת בהשהיה עד שתסירו מהצומת את כל ההערות עם הקידומת הזו.

לגישה הזו יש את הדרישות והמגבלות הבאות:

  • מפתח: מפתח ההערה חייב להתחיל בקידומת delay-deletion.cluster-autoscaler.kubernetes.io/. אפשר להוסיף מחרוזת כדי להגדיר מפתח ייחודי עם תיאור – לדוגמה, delay-deletion.cluster-autoscaler.kubernetes.io/ingress.
  • ערך: המידרוג האוטומטי של האשכול לא מעריך את ערך ההערה. עם זאת, בדרך כלל הערך מייצג את הגורם הספציפי (למשל, בקר) שהחיל את ההערה. הגישה הזו דומה לגישה של Kubernetes finalizers, שבה כמה גורמים עצמאיים יכולים להוסיף הערות, והכלי לאוטומציה של שינוי גודל האשכול ממתין להסרה של כולן.
  • זמן קצוב לתפוגה: כדי למנוע חסימות בלתי מוגבלות של התאמה לעומס, המידרוג האוטומטי של האשכול רק משהה את מחיקת הצמתים למשך זמן קצוב לתפוגה מקסימלי של 2 דקות (120 שניות). אי אפשר להגדיר את משך הזמן הזה.

התאמה אוטומטית לעומס (autoscaling) של מעבדי TPU ב-GKE

‫GKE תומך ביחידות לעיבוד טנסורים (TPU) כדי להאיץ עומסי עבודה של למידת מכונה. גם מאגר צמתים של פרוסת TPU במארח יחיד וגם מאגר צמתים של פרוסת TPU בכמה מארחים תומכים בהתאמה אוטומטית לעומס (autoscaling) ובהקצאת משאבים אוטומטית.

אם מגדירים את הדגל --enable-autoprovisioning באשכול GKE,‏ GKE יוצר או מוחק מאגרי צמתים של חלקי TPU עם מארח יחיד או עם כמה מארחים, עם גרסת TPU וטופולוגיה שעומדות בדרישות של עומסי עבודה בהמתנה.

כשמשתמשים ב---enable-autoscaling, מערכת GKE משנה את גודל מאגר הצמתים בהתאם לסוג שלו, באופן הבא:

  • מאגר צמתים של פרוסת TPU עם מארח יחיד: GKE מוסיף או מסיר צמתי TPU במאגר הצמתים הקיים. מאגר הצמתים יכול להכיל כל מספר של צמתי TPU בין אפס לבין הגודל המקסימלי של מאגר הצמתים, כפי שנקבע על ידי האפשרויות --max-nodes ו---total-max-nodes. כשמאפשרים שינוי גודל של מאגר הצמתים, לכל צומתי ה-TPU במאגר הצמתים יש את אותו סוג מכונה ואותה טופולוגיה. במאמר יצירת מאגר צמתים מוסבר איך ליצור מאגר צמתים של פרוסות TPU במארח יחיד.

  • מאגר צמתים של פרוסת TPU מרובת מארחים: מערכת GKE מבצעת הגדלה אטומית של מאגר הצמתים מאפס למספר הצמתים שנדרש כדי להתאים לטופולוגיית ה-TPU. לדוגמה, במאגר צמתים של TPU עם סוג מכונה ct5lp-hightpu-4t וטופולוגיה של 16x16, מאגר הצמתים מכיל 64 צמתים. התכונה לשינוי גודל אוטומטי ב-GKE עוזרת לוודא שבמאגר הצמתים הזה יש בדיוק 0 או 64 צמתים. כשמצמצמים את הקיבולת, GKE מוציא את כל הפודים המתוזמנים ומרוקן את כל מאגר הצמתים לאפס. במאמר יצירת מאגר צמתים מוסבר איך ליצור מאגר צמתים של פרוסת TPU עם כמה מארחים.

מכונות וירטואליות במודל Spot והתאמה אוטומטית של גודל האשכול

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

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

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

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

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

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  # Defines a prioritized list of machine types and configurations for node provisioning.
  priorities:
  - machineType: g2-standard-24
    # Specifically requests Spot VMs for this configuration. GKE will try to provision these VMs first.
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  # If GKE can't satisfy the preceding rule, request on-demand nodes with the same configuration
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  # Configures active migration behavior for workloads using this ComputeClass.
  activeMigration:
    optimizeRulePriority: true
    # Enables Cluster Autoscaler to attempt to migrate workloads to Spot VMs
    # if Spot capacity becomes available and the workload is currently
    # running on an on-demand VM (based on the priority rules in this example).

בדוגמה הקודמת, כלל העדיפות מגדיר העדפה ליצירת צמתים עם סוג המכונה g2-standard-24 ומכונות וירטואליות מסוג Spot. אם מכונות Spot VM לא זמינות, ‏ GKE משתמש במכונות VM לפי דרישה כאפשרות גיבוי. בנוסף, מחלקת המחשוב הזו מאפשרת activeMigration, ומאפשרת למידרוג האוטומטי של האשכול להעביר עומסי עבודה למכונות וירטואליות מסוג Spot כשהקיבולת הופכת לזמינה.

אם אי אפשר להשתמש במחלקות מחשוב בהתאמה אישית, צריך להוסיף זיקה לצומת, דחייה או טולרנטיות. לדוגמה, כלל ההתאמה הבא לצומת מציין העדפה לתזמון של Pod בצמתים שמגובים על ידי מכונות וירטואליות מסוג Spot (GKE מוסיף באופן אוטומטי את התווית cloud.google.com/gke-spot=true לסוגים האלה של צמתים):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        # set to "true". GKE automatically applies this label to Spot VMs.
        - key: cloud.google.com/gke-spot
          operator: Equal
          values:
          - true

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

ProvisioningRequest CRD

‫ProvisioningRequest הוא משאב מותאם אישית עם מרחב שמות שמאפשר למשתמשים לבקש קיבולת לקבוצה של Pods מ-Cluster Autoscaler. האפשרות הזו שימושית במיוחד לאפליקציות עם יחידות משנה מקושרות שצריך לתזמן יחד כיחידה אחת.

כיתות שהקצאת ההרשאות שלהן נתמכת

יש שלוש ProvisioningClasses נתמכות:

  • ‫queued-provisioning.gke.io: המחלקה הספציפית הזו ל-GKE משתלבת עם הכלי לתזמון עומסי עבודה דינמיים, ומאפשרת להוסיף בקשות לתור ולמלא אותן כשמשאבים הופכים לזמינים. האפשרות הזו מתאימה במיוחד למשימות באצווה או לעומסי עבודה (workloads) שמאפשרים השהיה. במאמר פריסת יחידות GPU לעומסי עבודה של עיבוד באצווה ו-AI באמצעות Dynamic Workload Scheduler מוסבר איך להשתמש בהקצאת משאבים בהמתנה ב-GKE. התמיכה זמינה מגרסה GKE 1.28.3-gke.1098000 באשכולות Standard ומגרסה GKE 1.30.3-gke.1451000 באשכולות Autopilot.

  • ‫check-capacity.autoscaling.x-k8s.io: המחלקה הזו של קוד פתוח מאמתת את הזמינות של משאבים לפני שהיא מנסה לתזמן Pods. התמיכה מתחילה מגרסה ‎1.30.2-gke.1468000 של GKE.

  • ‫best-effort-atomic.autoscaling.x-k8s.io: המחלקה הזו בקוד הפתוח מנסה להקצות משאבים לכל ה-Pods בבקשה יחד. אם אי אפשר להקצות מספיק משאבים לכל הפודים, לא יוקצו משאבים והבקשה כולה תיכשל. נתמך מגרסה 1.31.27 של GKE.

מידע נוסף על המחלקות CheckCapacity ו-BestEffortAtomicScaleUp זמין במסמכי הקוד הפתוח.

מגבלות על השימוש ב-ProvisioningRequest

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

שיטות מומלצות לשימוש ב-ProvisioningRequest

  • total-max-nodesבמקום להגביל את המספר המקסימלי של הצמתים (--max-nodes), משתמשים ב---total-max-nodes כדי להגביל את סך המשאבים שנצרכים על ידי האפליקציה.
  • שימוש ב-location-policy=ANY: ההגדרה הזו מאפשרת לתזמן את ה-Pods בכל מיקום זמין, מה שיכול לזרז את הקצאת המשאבים ולבצע אופטימיזציה של ניצול המשאבים.
  • (אופציונלי) שילוב עם Kueue: Kueue יכול לבצע אוטומציה של יצירת ProvisioningRequests, ולייעל את תהליך העבודה. מידע נוסף זמין במאמרי העזרה בנושא Kueue.

תקופות המתנה

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

מידע נוסף

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

מגבלות

יש כמה מגבלות למידרוג האוטומטי של האשכול:

  • הכלי לשינוי גודל אוטומטי של אשכולות לא תומך בLocal PersistentVolumes.
  • בגרסה של מישור הבקרה של GKE שקודמת ל-1.24.5-gke.600, כש-Pods מבקשים אחסון זמני, שינוי הגודל האוטומטי של האשכול לא תומך בהגדלת מאגר הצמתים עם אפס צמתים שמשתמש בכונני SSD מקומיים כאחסון זמני.
  • מגבלות על גודל האשכול: עד 15,000 צמתים. כשמריצים אשכולות בגודל הזה, צריך לקחת בחשבון מגבלות אחרות על אשכולות ושיטות מומלצות.
  • כשמצמצמים את מספר הצמתים, הכלי להתאמה אוטומטית של גודל האשכול מכבד תקופת סיום הדרגתית של שעה אחת לצורך תזמון מחדש של ה-Pods של הצומת בצומת אחר לפני סיום הצומת בכוח.
  • לפעמים, המידרוג האוטומטי של האשכול לא מצליח להקטין את האשכול באופן מלא, ונשאר צומת נוסף אחרי ההקטנה. המצב הזה יכול לקרות כשמתוזמנים פודים נדרשים של המערכת לצמתים שונים, כי אין טריגר להעברת הפודים האלה לצומת אחר. יש לי כמה צמתים עם ניצול נמוך, אבל הם לא מצטמצמים. למה? כדי לעקוף את ההגבלה הזו, אפשר להגדיר תקציב לשיבוש Pod.
  • תזמון מותאם אישית עם מסננים ששונו לא אפשרי.
  • הכלי Cluster Autoscaler לוקח בחשבון את התנהגות ברירת המחדל של kube-scheduler כשהוא מחליט להקצות צמתים חדשים ל-Pods בהמתנה. אין תמיכה בשימוש בתזמון מותאם אישית, והשימוש הזה עלול לגרום להתנהגות לא צפויה של שינוי הגודל.
  • הצמתים לא יגדלו אם הערך של PriorityClass ב-Pods נמוך מ--10. איך המידרוג האוטומטי של האשכול פועל עם תעדוף של Pod ועם דחיקה?
  • יכול להיות שלמידרוג האוטומטי באשכול אין מספיק מרחב של כתובות IP לא מוקצות לשימוש כדי להוסיף צמתים או Pod חדשים, ולכן המידרוג כלפי מעלה נכשל. הכשלים האלה מסומנים באירועים eventResult עם הסיבה scale.up.error.ip.space.exhausted. אפשר להוסיף עוד כתובות IP לצמתים על ידי הרחבת רשת המשנה הראשית, או להוסיף כתובות IP חדשות ל-Pods באמצעות CIDR של כמה Pods לא רציפים. מידע נוסף זמין במאמר אין מספיק מקום לכתובות IP חופשיות בשביל Pods.
  • המידרוג האוטומטי של אשכולות GKE שונה מהמידרוג האוטומטי של אשכולות בפרויקט הקוד הפתוח Kubernetes. הפרמטרים של שינוי הגודל האוטומטי של אשכול GKE תלויים בהגדרת האשכול ועשויים להשתנות. אם אתם צריכים יותר שליטה בהתנהגות של המידרוג האוטומטי, אתם יכולים להשבית את המידרוג האוטומטי של אשכול GKE ולהפעיל את המידרוג האוטומטי של אשכול Kubernetes בקוד פתוח. עם זאת, ל-Kubernetes בקוד פתוח אין תמיכה. Google Cloud
  • כשמוחקים מאגר צמתים ב-GKE שמופעל בו שינוי גודל אוטומטי, הצמתים מקבלים את ההגדרה NoSchedule, וכל ה-Pods בצמתים האלה מפונים באופן מיידי. כדי לצמצם את הירידה הפתאומית במשאבים הזמינים, יכול להיות שהמערכת לשינוי גודל אוטומטי של מאגר הצמתים תקצה צמתים חדשים באותו מאגר צמתים. הצמתים החדשים שנוצרו זמינים לתזמון, וה-Pods שפונו מתזמנים חזרה אליהם. בסופו של דבר, כל מאגר הצמתים – כולל הצמתים החדשים שהוקצו וה-Pods שלהם – נמחק, מה שעלול להוביל להפסקות בשירות. כפתרון עקיף, כדי למנוע את הקצאת המשאבים של הצמתים החדשים על ידי קנה המידה האוטומטי במהלך המחיקה, משביתים את קנה המידה האוטומטי במאגר הצמתים לפני שמתחילים את המחיקה.
  • הכלי Cluster Autoscaler צריך לחזות את כמות המשאבים הזמינים בצמתים חדשים כדי לקבל החלטות לגבי שינוי גודל. פודים של DaemonSet נכללים, ולכן המשאבים הזמינים קטנים יותר. התחזיות לא מדויקות ב-100%, וכמות המשאבים הזמינים יכולה להשתנות בין גרסאות GKE. לכן, לא מומלץ לשנות את הגודל של עומסי העבודה ולהגביל אותם כך שיתאימו לסוג מסוים של מכונה וירטואלית. במקום זאת, כדאי להשתמש בסוגי מחשוב בהתאמה אישית. אם עומס עבודה צריך לטרגט סוג מסוים של מכונה, צריך לוודא שהגודל שלו מאפשר להקצות משאבים בצמתים. במקרה כזה, צריך גם לוודא שכל ה-Pods הרלוונטיים של DaemonSet יכולים להיכנס לצמתים יחד עם ה-Pods של עומס העבודה.
  • המידרוג האוטומטי של האשכול לא תומך באילוצים מחמירים של פיזור טופולוגיית ה-Pod כשהשדה whenUnsatisfiable מוגדר לערך DoNotSchedule. כדי להקל על הדרישות לגבי פיזור ההמרות, אפשר להגדיר את הערך ScheduleAnyway בשדה whenUnsatisfiable.

בעיות מוכרות

  • בגרסה של מישור הבקרה של GKE שקודמת לגרסה 1.22,‏ GKE cluster autoscaler מפסיק את ההגדלה של כל מאגרי הצמתים באשכולות ריקים (אשכולות עם אפס צמתים). ההתנהגות הזו לא מתרחשת ב-GKE בגרסה 1.22 ואילך.

פתרון בעיות

הנחיות לפתרון בעיות זמינות בדפים הבאים:

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