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

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

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

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

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

שיטה מומלצת:

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

למה כדאי להשתמש ב-Cluster Autoscaler

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הזמנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ProvisioningRequest CRD

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

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

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

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

  • מדד של כשלים בהקצאת צמתים: המדד kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc זמין ב-GKE מגרסה 1.37 ואילך. המדד הזה עוקב אחרי ניסיונות כושלים להוסיף צמתים, ומסווג אותם לפי סיבות ספציפיות. המדד הזה יכול לעזור לכם להבין למה קבוצת שרתים לא מתרחבת כמו שציפיתם. מידע נוסף זמין במאמר בנושא מעקב אחרי כשלים בהקצאת צמתים.

  • מדד ניסיונות הקצאת צמתים: המדד kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc זמין ב-GKE מגרסה 1.37 ואילך, ומספק ספירה של כל פעם שהמידרוג האוטומטי מפעיל הגדלה. המדד הזה עוזר לוודא שהמידרוג האוטומטי מגיב לביקוש. מידע נוסף זמין במאמר מעקב אחרי ניסיונות הקצאת צמתים.

מגבלות

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

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

בעיות מוכרות

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

פתרון בעיות

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

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