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

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

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

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

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

שיטה מומלצת:

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הזמנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ואילך, יוצרת אשכול רב-אזורי עם התאמה אוטומטית לעומס, עם שישה צמתים בשלושה אזורים בהתחלה, עם מינימום של שלושה צמתים ומקסימום של שנים עשר צמתים במאגר הצמתים בכל האזורים:

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 בצמתים שכבר יש בהם הקצאה גבוהה של מעבדי CPU, זיכרון או מעבדי GPU. עם זאת, יש גורמים אחרים שמשפיעים על התזמון, כמו פיזור של Pods ששייכים לאותו Deployment, ‏ StatefulSet או Service, בין הצמתים.

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

הפקודה הבאה מפעילה את פרופיל ההתאמה האוטומטית לעומס (autoscaling) של 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 שהוגדר.

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

התאמה אוטומטית לעומס (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 ומידרוג אוטומטי של אשכולות

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

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

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

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

אם אי אפשר להשתמש במחלקות חישוב בהתאמה אישית, צריך להוסיף node affinity,‏ taint או toleration. לדוגמה, כלל ההעדפה הבא של צומת מצהיר על העדפה לתזמון של Pods בצמתים שמגובים על ידי מכונות וירטואליות מסוג 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 משתלבת עם Dynamic Workload Scheduler, ומאפשרת להוסיף בקשות לתור ולמלא אותן כשמשאבים הופכים לזמינים. האפשרות הזו מתאימה במיוחד למשימות באצווה או לעומסי עבודה (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 בבקשה יחד. אם אי אפשר להקצות מספיק משאבים לכל הפודים, לא יוקצו משאבים והבקשה כולה תיכשל. נתמך מגרסה GKE 1.31.27.

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

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

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

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

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

תקופות השהיה לפני ניסיון חוזר

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

מידע נוסף

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

מגבלות

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

  • הכלי לשינוי גודל אוטומטי של אשכולות לא תומך בLocal PersistentVolumes.
  • בגרסה של מישור הבקרה של GKE שקודמת לגרסה 1.24.5-gke.600, כש-Pods מבקשים אחסון זמני, קנה המידה האוטומטי של האשכול לא תומך בהגדלת קנה המידה של מאגר צמתים עם אפס צמתים שמשתמש בכונני SSD מקומיים כאחסון זמני.
  • מגבלות על גודל האשכול: עד 15,000 צמתים. כשמריצים אשכולות בגודל הזה, צריך לקחת בחשבון מגבלות אחרות על אשכולות וגם את השיטות המומלצות שלנו.
  • כשמצמצמים את מספר הצמתים, מידרוג אוטומטי של האשכול מכבד תקופת סיום הדרגתית של שעה אחת לצורך תזמון מחדש של ה-Pods של הצומת בצומת אחר לפני סיום הצומת בכפייה.
  • לפעמים, המידרוג האוטומטי של האשכול לא מצליח להקטין את האשכול באופן מלא, ונשאר צומת נוסף אחרי ההקטנה. המצב הזה יכול לקרות כשמתוזמנים פודים נדרשים של המערכת לצמתים שונים, כי אין טריגר להעברת אף אחד מהפודים האלה לצומת אחר. אפשר לעיין במאמר יש לי כמה צמתים עם ניצול נמוך, אבל הם לא מצטמצמים. למה? כדי לעקוף את ההגבלה הזו, אפשר להגדיר תקציב לשיבוש Pod.
  • אין תמיכה בתזמון מותאם אישית עם מסננים ששונו.
  • הכלי Cluster Autoscaler מתחשב בהתנהגות ברירת המחדל של kube-scheduler כשהוא מחליט להקצות צמתים חדשים ל-Pods בהמתנה. אין תמיכה בשימוש בכלי תזמון בהתאמה אישית, והשימוש בהם עלול לגרום להתנהגות לא צפויה של שינוי הגודל.
  • הצמתים לא יגדלו אם ל-Pods יש ערך PriorityClass מתחת ל--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. לכן, לא מומלץ להתאים את גודל עומסי העבודה ולהגביל אותם כך שיתאימו לסוג מסוים של מופע. אפשר להשתמש במקום זאת בסוגי מחשוב בהתאמה אישית. אם עומס עבודה צריך לטרגט סוג מסוים של מכונה, חשוב לוודא שהגודל שלו מאפשר להקצות משאבים בצמתים. במקרה כזה, צריך גם לוודא שכל רכיבי ה-Pod של DaemonSet הרלוונטיים יכולים להתאים לצמתים יחד עם רכיבי ה-Pod של עומס העבודה.
  • המידרוג האוטומטי של האשכול לא תומך באילוצי פיזור טופולוגי קפדניים של Pod כששדה whenUnsatisfiable מוגדר לערך DoNotSchedule. כדי להקל על הדרישות לגבי פיזור ההמרות, אפשר להגדיר את הערך ScheduleAnyway בשדה whenUnsatisfiable.

בעיות מוכרות

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

פתרון בעיות

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

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