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

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

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

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

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

שיטה מומלצת:

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המדיניות בנושא מיקום

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

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

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

הזמנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות על התאמה אוטומטית לעומס (Automatic scaling)

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

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

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

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

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

אתם יכולים לציין באיזה פרופיל התאמה אוטומטית לעומס (automatic scaling) להשתמש כשמקבלים החלטות כאלה. הפרופילים הזמינים הם:

  • ‫balanced: פרופיל ברירת המחדל שמתעדף שמירה של יותר משאבים זמינים לפודים נכנסים, וכך מקצר את הזמן שנדרש כדי להפעיל אותם באשכולות Standard. פרופיל balanced לא זמין לאשכולות של Autopilot.
  • ‫optimize-utilization: נותן עדיפות לאופטימיזציה של הניצול על פני שמירת משאבים פנויים באשכול. כשמפעילים את הפרופיל הזה, מידרוג אוטומטי של האשכול מקטין את האשכול בצורה אגרסיבית יותר. ‫GKE יכול להסיר יותר צמתים, ולהסיר צמתים מהר יותר. ב-GKE, המערכת מעדיפה לתזמן Pods בצמתים שכבר יש בהם הקצאה גבוהה של מעבדי CPU, זיכרון או מעבדי 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 ואילך, פודים עם אחסון מקומי לא חוסמים יותר את ההתאמה לעומס (scaling down).
  • ל-Pod יש את ההערה "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • מחיקת הצומת תחרוג מהערך שהוגדר ל-PodDisruptionBudget.

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

סדר פינוי הפודים במהלך צמצום אנכי בהתאם לעומס (scale down)

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

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

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

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

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

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

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

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

VM במודל Spot ומידרוג אוטומטי באשכול

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

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

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

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

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

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

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

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

ProvisioningRequest CRD

‫ProvisioningRequest הוא משאב בהתאמה אישית עם מרחב שמות, שמאפשר למשתמשים לבקש קיבולת לקבוצה של Pods מהכלי להתאמה לעומס (autoscaler) של האשכול. האפשרות הזו שימושית במיוחד לאפליקציות עם Pods מקושרים שצריך לתזמן יחד כיחידה אחת.

סוגי הקצאות נתמכים

יש שלושה סוגים נתמכים של ProvisioningClasses:

  • queued-provisioning.gke.io: המחלקה הספציפית הזו ל-GKE משתלבת עם מתזמן משימות לפריסת workload דינמית (DWS), ומאפשרת להוסיף בקשות לתור ולמלא אותן כשמשאבים הופכים לזמינים. האפשרות הזו אידיאלית למשימות באצווה או לעומסי עבודה (workloads) שסובלים עיכובים. במאמר פריסת GPUs לעומסי עבודה באצווה ולעומסי עבודה של AI באמצעות מתזמן משימות לפריסת workload דינמית (DWS) מוסבר איך משתמשים בהקצאת משאבים בהמתנה ב-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 בבקשה יחד. אם אי אפשר להקצות מספיק משאבים לכל ה-Pods, לא יוקצו משאבים והבקשה כולה תיכשל. נתמך מגרסה 1.31.27 של GKE.

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

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

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

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

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

תקופות המתנה (backoff)

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

מידע נוסף

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

מעקב אחרי המידרוג האוטומטי של האשכול

כדי להבין את ההתנהגות וההחלטות של המידרוג האוטומטי של האשכול, GKE מספק כמה כלי ניראות (observability):

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

  • אירועי Kubernetes: המידרוג האוטומטי של האשכול יוצר אירועי Kubernetes סטנדרטיים בפודים (כמו TriggeredScaleUp או NotTriggeredScaleUp) ובצמתים (כמו ScaleDown). המידרוג האוטומטי של האשכול יוצר גם עדכוני סטטוס ב-ConfigMap של cluster-autoscaler-status במרחב השמות kube-system. אפשר להציג את האירועים האלה באמצעות הפקודה kubectl get events -n kube-system או על ידי בדיקת משאבים ספציפיים.

  • המדד Pending Pods: זמין ב-GKE בגרסה 1.37 ואילך. המדד kubernetes.io/autoscaler/cluster_pending_pods_per_ccc ב-Cloud Monitoring מציג בזמן אמת את מספר ה-Pods שהמידרוג האוטומטי של האשכול מעבד. המדד הזה עוזר לכם להעריך את הביקוש להרחבה ולזהות בעיות. באופן ספציפי, המדד הזה משויך למשאב k8s_entity ואפשר לפרק אותו לפי ComputeClass, הסיבה לכך שה-Pod נמצא בהמתנה מנקודת המבט של המידרוג האוטומטי של האשכול, וסוג ה-Pod. התווית resource.labels.entity_name מציינת את השם של ComputeClass. מחרוזת ריקה ("") מציינת שלא משויך ComputeClass ספציפי. למידע נוסף, קראו את המאמר מעקב אחרי סטטוס Pod בהמתנה באמצעות Cloud Monitoring.

מגבלות

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

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

בעיות מוכרות

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

פתרון בעיות

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

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