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

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

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

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

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

שיטה מומלצת:

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

הזמנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ‫balanced: פרופיל ברירת המחדל שנותן עדיפות לשמירת יותר משאבים שזמינים בקלות לפודים נכנסים, וכך מקצר את הזמן שנדרש כדי להפעיל אותם באשכולות רגילים. פרופיל balanced לא זמין לאשכולות של Autopilot.
  • ‫optimize-utilization: עדיפות לאופטימיזציה של הניצול על פני שמירה של משאבים עודפים באשכול. כשמפעילים את הפרופיל הזה, הכלי לשינוי גודל האשכול משנה את גודל האשכול בצורה אגרסיבית יותר. ‫GKE יכול להסיר יותר צמתים, ולהסיר צמתים מהר יותר. מערכת GKE מעדיפה לתזמן Pods בצמתים שכבר יש בהם הקצאה גבוהה של מעבדי CPU, זיכרון או מעבדי GPU. עם זאת, יש גורמים אחרים שמשפיעים על התזמון, כמו פיזור של יחידות Pod ששייכות לאותו 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 שהוגדר.

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

התאמה אוטומטית לעומס (automatic scaling) של מעבדי 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 מפנה את כל הפודים המתוזמנים ומרוקן את כל מאגר הצמתים לאפס. איך יוצרים מאגר צמתים

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

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

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

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

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

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

  • במקום להגביל את המספר המקסימלי של הצמתים (--max-nodes), משתמשים ב---total-max-nodes כדי להגביל את סך המשאבים שנצרכים על ידי האפליקציה.total-max-nodes
  • שימוש ב-location-policy=ANY: ההגדרה הזו מאפשרת לתזמן את הפודים בכל מיקום זמין, מה שיכול לזרז את הקצאת המשאבים ולבצע אופטימיזציה של ניצול המשאבים.
  • (אופציונלי) שילוב עם 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 בהמתנה. אין תמיכה בשימוש בתזמון בהתאמה אישית, והוא עלול לגרום להתנהגות לא צפויה של שינוי הגודל.
  • הצמתים לא יגדלו אם ל-Pods יש ערך PriorityClass מתחת ל--10. איך Cluster Autoscaler עובד עם Pod Priority ו-Preemption?
  • יכול להיות שלכלי לשינוי גודל האשכול אין מספיק מקום לכתובות IP לא מוקצות כדי להוסיף צמתים או פודים חדשים, ולכן מתרחשות שגיאות בהגדלת הקיבולת. השגיאות האלה מסומנות על ידי אירועי 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 ואילך.

פתרון בעיות

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

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