מידע על ComputeClasses בהתאמה אישית

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

סקירה כללית על ComputeClasses

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

אפשר להשתמש ב-ComputeClasses במצב Autopilot ובמצב Standard של GKE בגרסה 1.30.3-gke.1451000 ואילך, והם מציעים גישה הצהרתית להגדרת מאפייני צמתים וסדרי עדיפויות להתאמה לעומס. כברירת מחדל, אפשר להגדיר את ComputeClasses ולהשתמש בהם בכל אשכולות GKE שעומדים בדרישות.

היתרונות של ComputeClasses בהתאמה אישית

היתרונות של ComputeClasses בהתאמה אישית:

  • עדיפויות חלופיות של משאבי מחשוב: הגדרת היררכיה של הגדרות צמתים בכל ComputeClass, כדי ש-GKE יתעדף אותן. אם ההגדרה המועדפת ביותר לא זמינה, GKE בוחר באופן אוטומטי את ההגדרה הבאה בהיררכיה. מודל הגיבוי הזה עוזר להבטיח שגם כשמשאבי המחשוב לא זמינים, עומסי העבודה עדיין פועלים בחומרה אופטימלית עם עיכובים מינימליים בתזמון.
  • שליטה מפורטת בהתאמה לעומס (autoscaling): הגדרת הצמתים שהכי מתאימים לעומסי עבודה ספציפיים. ב-GKE, ההגדרות האלה מקבלות עדיפות כשיוצרים צמתים במהלך שינוי קנה המידה.
  • הגדרת תשתית דקלרטיבית: גישה דקלרטיבית לניהול התשתית, שבה GKE יוצר באופן אוטומטי צמתים שמתאימים לדרישות הספציפיות של עומס העבודה.
  • העברה פעילה: אם משאבי המחשוב של הגדרת המכונה המועדפת יותר יהיו זמינים במיקום שלכם, GKE יעביר באופן אוטומטי את עומסי העבודה לצמתים חדשים שמשתמשים בהגדרה המועדפת.
  • אופטימיזציה של עלויות: כדי להוזיל את עלויות האשכול, כדאי לתת עדיפות לסוגי צמתים חסכוניים כמו VM במודל Spot.
  • הגדרת ComputeClasses בהתאמה אישית כברירת מחדל: אפשר להגדיר ComputeClass בהתאמה אישית כברירת מחדל לאשכול שלם או למרחבי שמות ספציפיים ב-Kubernetes, כדי שעומסי העבודה יפעלו בחומרה שעברה אופטימיזציה גם אם הם לא מבקשים ComputeClass ספציפי.
  • ספי איחוד מותאמים אישית של צמתים: הגדרת ספים מותאמים אישית לשימוש במשאבים של צמתים. אם השימוש במשאבים של צומת מסוים יורד מתחת לסף, GKE מנסה לאחד את עומסי העבודה לצומת דומה וזמין, ומצמצם אנכית בהתאם לעומס (scale down) את הצומת שלא מנוצל מספיק.
  • קיבולת מינימלית מוצהרת: שמירה על מספר מינימלי של צמתים של ComputeClass באשכול באופן יזום, כדי להבטיח שיש קיבולת זמינה לעומסי עבודה קריטיים.

תרחישים לדוגמה לשימוש ב-ComputeClasses בהתאמה אישית

כדאי להשתמש ב-ComputeClasses בהתאמה אישית בתרחישים כמו:

  • אתם רוצים להריץ את עומסי העבודה של AI/ML בהגדרות ספציפיות של GPU או TPU.
  • אתם רוצים להגדיר הגדרות חומרה כברירת מחדל לעומסי העבודה שצוותים ספציפיים מריצים, כדי להוריד את התקורה ממפעילי האפליקציות.
  • אתם מריצים עומסי עבודה שפועלים בצורה אופטימלית בסדרות מכונות או בהגדרות חומרה ספציפיות של Compute Engine.
  • אתם רוצים להצהיר על הגדרות חומרה שעומדות בדרישות עסקיות ספציפיות, כמו ביצועים גבוהים, אופטימיזציה של עלויות או זמינות גבוהה.
  • אתם רוצים ש-GKE יחזור באופן היררכי להשתמש בהגדרות חומרה ספציפיות כשמשאבי המחשוב לא זמינים, כדי שעומסי העבודה תמיד יפעלו במכונות שמתאימות לדרישות שלהם.
  • אתם רוצים לקבוע באופן מרכזי את ההגדרות האישיות האופטימליות לכל הצי של הארגון, כדי שהעלויות יהיו צפויות יותר ועומסי העבודה יפעלו בצורה אמינה יותר.
  • אתם רוצים לציין באופן מרוכז באילו מההזמנות של קיבולת Compute Engine, ‏GKE צריך להשתמש כדי להקצות צמתים חדשים לעומסי עבודה ספציפיים.
  • אתם רוצים לציין מדיניות למיקום קומפקטי לשימוש עם GKE Autopilot. לפרטים נוספים, ראו מיקום קומפקטי.

איך פועלים ComputeClasses בהתאמה אישית

‫ComputeClasses בהתאמה אישית הם משאבים בהתאמה אישית של Kubernetes שמקצים תשתית שלGoogle Cloud . מגדירים אובייקט ComputeClass באשכול, ואז מבקשים את ה-ComputeClass הזה בעומסי עבודה או מגדירים אותו כברירת המחדל למרחב שמות ב-Kubernetes. כשעומס עבודה תואם דורש תשתית חדשה, GKE מקצה צמתים חדשים בהתאם לעדיפויות שהגדרתם ב-ComputeClass.

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

‫ComputeClasses בהתאמה אישית משפיעים על החלטות לגבי התאמה אוטומטית לעומס (automatic scaling), אבל kube-scheduler לא מתחשב בהם. במהלך תזמון Pod, יכול להיות שהמתזמן לא יתעדף צמתים עם עדיפויות גבוהות יותר של ComputeClass בהתאמה אישית, גם אם יש צמתים קיימים בעדיפויות שונות.

כדי לוודא שה-ComputeClasses בהתאמה אישית מותאמים לצי שלכם, כדאי לפעול לפי ההנחיות הבאות:

  • להבין את דרישות המחשוב של ה-fleet, כולל דרישות חומרה ספציפיות לאפליקציה.
  • בוחרים נושא שינחה את העיצוב של כל ComputeClass. לדוגמה, ל-ComputeClass עם אופטימיזציה לביצועים יכולה להיות אסטרטגיית חלופית שמשתמשת רק במכונות מרובות ליבות (high-CPU).
  • בוחרים את משפחת המכונות ואת סדרת המכונות של Compute Engine שהכי מתאימות לעומסי העבודה שלכם. למידע נוסף, קראו את המדריך להשוואה בין משפחות של מכונות ומשאבים.
  • תכננו אסטרטגיית גיבוי בכל ComputeClass כדי שעומסי העבודה תמיד יפעלו בצמתים שמשתמשים בהגדרות מכונה דומות. לדוגמה, אם סדרת המכונות N4 לא זמינה, אפשר לחזור למכונות C3.

הצגת ההגדרה המלאה של המשאב בהתאמה אישית

כדי לראות את הגדרת המשאב בהתאמה אישית (CRD) העדכנית של המשאב בהתאמה אישית ComputeClass, כולל כל השדות והקשרים ביניהם, עיינו במאמרי העזרה של ComputeClass.

אפשר גם להציג את ה-CRD באשכול על ידי הרצת הפקודה הבאה:

kubectl describe crd computeclasses.cloud.google.com

תכנון של ComputeClass בהתאמה אישית

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

  1. בחירת עדיפויות חלופיות למשאבי המחשוב: מגדירים סדרה של כללים שקובעים את המאפיינים של הצמתים ש-GKE יוצר ל-ComputeClass.
  2. הגדרת מאגרי צמתים ו-ComputeClasses ב-GKE Standard: באשכולות במצב Standard, מבצעים את שלבי ההגדרה הנדרשים כדי להשתמש ב-ComputeClass עם מאגרי הצמתים.
  3. הגדרת התנהגות ההתאמה לעומס כשלא חלים כללי עדיפות: אפשר להגדיר ל-GKE מה לעשות אם אי אפשר להקצות צמתים שעומדים בכללי העדיפות.
  4. הגדרת פרמטרים להתאמה לעומס (autoscaling) לצורך איחוד צמתים: מגדירים ל-GKE מתי לאחד עומסי עבודה ולהסיר צמתים שלא מנוצלים מספיק.
  5. הגדרת העברה פעילה לצמתים בעדיפות גבוהה יותר: אפשר להורות ל-GKE להעביר עומסי עבודה לצמתים מועדפים יותר כשהחומרה הופכת לזמינה.
  6. שימוש במקומות שמורים ב-Compute Engine: אפשר להגדיר ל-GKE להשתמש במקומות שמורים קיימים של תחום מוגדר ב-Compute Engine כשיוצרים צמתים חדשים.
  7. הקצאת מספר מינימלי של צמתים: אפשר להגדיר ל-GKE לשמור על מספר מינימלי של צמתים באשכול.

בחירת העדיפויות החלופיות של המחשוב

היתרון העיקרי של שימוש ב-ComputeClass בהתאמה אישית הוא היכולת לשלוט באסטרטגיית הגיבוי כשהצמתים המועדפים לא זמינים בגלל גורמים כמו מיצוי המשאבים של התחום המוגדר (למשל, כשמופיעות ההודעות ZONE_RESOURCE_POOL_EXHAUSTED או GCE out of resources במהלך אירועי FailedScaleUp) ומגבלות המכסות. אם תגדירו רשימה של סדרות מכונות חלופיות או מודלים של הקצאה לפי סדר עדיפויות, האשכול יוכל להקצות באופן אוטומטי את הקיבולת הזמינה במקום להשאיר את ה-Pods במצב Pending. למידע נוסף על פתרון בעיות שקשורות לקיבולת מחשוב לא מספיקה, קראו את המאמרים יצירת מאגר צמתים נכשלה בגלל מחסור במשאבים והגדלת הצומת נכשלה: אין מספיק משאבים ב-Compute Engine.

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

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

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

כברירת מחדל, כשצריך ליצור צומת חדש לפוד נכנס שבוחר ComputeClass, ‏ GKE מנסה ליצור צמתים לפי הסדר שבו כללי העדיפות מופיעים במניפסט של ComputeClass. בגרסה 1.35.2-gke.1842000 ואילך של GKE, אפשר גם להגדיר במפורש ניקוד לכל כלל עדיפות ב-ComputeClass באמצעות השדה priorityScore. במקרה כזה, GKE מעבד את הכללים לפי הסדר, מהניקוד הגבוה ביותר לניקוד הנמוך ביותר. אם כל כללי העדיפות ב-ComputeClass מוצו, GKE יוצר צמתים על סמך ההתנהגות שמתוארת בקטע הגדרת התנהגות של התאמה לעומס כשלא חלים כללי עדיפות.

ציונים של כללי עדיפות

נדרשת גרסת GKE‏ 1.35.2-gke.1842000 ואילך.

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

לשדה priorityScore יש את המאפיינים הבאים:

  • השדה מקבל ערך של מספר שלם, עם ערך מינימלי של 1 וערך מקסימלי של 1000.
  • צריך להשתמש בשדה priorityScore בכל כללי העדיפות או לא להשתמש בו באף אחד מהם.

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

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

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

בדוגמה הבאה מוצג ComputeClass שמגדיר את הניקוד של כללי העדיפות:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

במהלך אירוע של הגדלת נפח ב-ComputeClass שבדוגמה, GKE מבצע את הפעולות הבאות:

  1. ‫GKE מנסה ליצור מכונות E2.
  2. אם מכונות E2 לא זמינות, GKE יוצר מכונות N2 או T2D, בהתאם לתוצאה של המידרוג האוטומטי של האשכול.
  3. אם מכונות N2 ו-T2D לא זמינות, GKE מנסה ליצור מכונות N1.
  4. אם מכונות N1 לא זמינות, GKE חוזר לסדרת המכונות שמוגדרת כברירת המחדל לאשכול.

מאפייני צומת ברמה העליונה לכללי עדיפות

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

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

  • machineFamily: סדרת מכונות של Compute Engine, כמו n4.
  • ‫machineType: סוג מכונה ספציפי של Compute Engine, כמו n4-standard-32.
  • ‫gpu: הגדרת GPU, שיכולה לכלול סוג GPU, מספר ספציפי של מעבדי GPU והגדרת מנהל התקן.
  • ‫tpu: הגדרה של Cloud TPU, שיכולה לכלול גרסת TPU, טופולוגיה ומספר שבבים.

בהגדרות של מאיצים לא צריך לציין במפורש את השדה machineType או machineFamily, אלא אם משתמשים בהם בשילוב עם הזמנות.

כל דור של סדרת מכונות ב-Compute Engine תומך בסוגי דיסקים ספציפיים. לדוגמה, סדרת המכונות N4 תומכת בסוגי הדיסקים של Hyperdisk ML, אבל סדרת המכונות N2 לא תומכת בהם. ב-ComputeClasses שכוללים כמה דורות, יכול להיות שעומסי עבודה עם שמירת מצב (stateful) שמבקשים סוג דיסק ספציפי לא יוכלו לגשת לנתונים קבועים אם סוג המכונה לא תומך בסוג הדיסק הזה. בהתאם לאופן שבו אתם יוצרים דיסקים ומשתמשים בהם בעומסי העבודה, אתם יכולים להשתמש בכל אחת מהשיטות הבאות כדי לצמצם את הסיכון לנתונים קבועים שאי אפשר לגשת אליהם:

  • הקצאת נפח דינמית: בגרסה 1.35.3-gke.1290000 של GKE ואילך, משתמשים ב-StorageClass שמגדיר בחירה אוטומטית של סוג הדיסק. ‫GKE יוצר סוג דיסק שתואם לסוג המכונה של הצומת שמריץ את עומס העבודה. בגרסאות קודמות של GKE, צריך לוודא שכל סדרות המכונות ב-ComputeClass תומכות בסוג הדיסק שמוקצה על ידי ה-StorageClasses.

  • דיסקים קבועים קיימים: מוודאים שכל סדרות המכונות ב-ComputeClass תומכות בסוגי הדיסקים של הדיסקים הקבועים הקיימים.

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

הגדרות של machineFamily

בשדה machineFamily אפשר להזין כל סדרת מכונות של Compute Engine שנתמכת ב-GKE, כמו n2 או c3. אם לא מציינים ערך, ברירת המחדל היא e2. כשמשתמשים בשדה machineFamily, ‏GKE מקצה צמתים מהסדרה הזו עם סוג מכונה שגדול מספיק כדי להריץ את ה-Pods. האלגוריתם של ההתאמה האוטומטית לעומס קובע את הגודל המתאים ביותר על סמך בקשות המשאבים המצטברות של כל ה-Pods בהמתנה. כדי לקבל שליטה רבה יותר על גודל המכונה המדויק, השתמשו בשדה machineType.

בקשה של משפחת מכונות רחבה יותר לא מקצה סוגי מכונות Bare Metal. לדוגמה, בקשה של c3 או c4a לא מקצה סוגי מכונות כמו c3-standard-192-metal או c4a-standard-72-metal, בהתאמה. בסוגי צמתים של Bare Metal צריך לבקש סוג מכונה מדויק, ולכן אי אפשר להשתמש גם ב-ComputeClass Performance המוגדר מראש של Autopilot.

כדי להקצות סוגי מכונות Bare Metal, יוצרים ComputeClass בהתאמה אישית ומציינים את סוג המכונה המדויק בשדה machineType. אלה דרישות הגרסה של סוגי מכונות Bare Metal:

  • כדי להשתמש במכונות ללא מערכת הפעלה מסוג c3 ו-c4a עם ComputeClasses, יצירה אוטומטית של מאגרי צמתים או מצב Autopilot, צריך להשתמש ב-GKE בגרסה 1.35.3-gke.1389000 ואילך.
  • כדי להשתמש במכונות פיזיות מסוג c4d עם ComputeClasses, יצירה אוטומטית של מאגרי צמתים או מצב Autopilot, צריך להשתמש ב-GKE בגרסה 1.37.0-gke.4713000 ואילך. במאגרי צמתים במצב Standard שמשתמשים במכונות ללא מערכת הפעלה (bare metal) מסוג c4d, נדרשת גרסת GKE‏ 1.36 ואילך. בגרסאות שקודמות ל-1.37.0-gke.4713000, צריך ליצור ולהתאים את הגודל של מאגרי הצמתים הרגילים באופן ידני.

אתם יכולים להשתמש בשדות אחרים של spec.priorities לצד השדה machineFamily כדי להגדיר באופן הצהרתי את דרישות המחשוב שלכם. לדוגמה:

  • ‫spot: מכונות וירטואליות במודל Spot. ערך ברירת המחדל הוא false.
  • ‫minCores: מספר מינימלי של מעבדי vCPU לכל צומת. ערך ברירת המחדל הוא 0. השדה הזה שימושי למניעת יצירה של צמתים קטנים מדי לצרכים שלכם.
  • ‫minMemoryGb: זיכרון מינימלי לכל צומת. ערך ברירת המחדל הוא 0.
  • ‫storage.bootDiskType: סוג דיסק האתחול. באשכולות Autopilot, יש תמיכה רק בסוג pd-balanced של bootDiskType. נדרשת גרסת GKE‏ 1.34.1-gke.1431000 ואילך.
  • ‫storage.bootDiskSize: הגודל ב-GB של דיסק האתחול של הצומת. נדרשת גרסת GKE‏ 1.34.1-gke.1431000 ואילך.
  • ‫storage.bootDiskKMSKey: הנתיב למפתח של Cloud Key Management Service שמשמש להצפנה של דיסק האתחול.
  • ‫storage.secondaryBootDisks: דיסקים לאחסון מתמיד שמשמשים לטעינה מראש של נתונים בצומתי GKE, כמו מודל למידת מכונה (ML) או קובץ אימג' של קונטיינר. נדרשת גרסת GKE‏ 1.31.2-gke.1105000 ואילך. כדי להגדיר דיסק אתחול משני לשימוש באשכול, קראו את המאמר הגדרת דיסקי אתחול משניים.
    • ‫storage.secondaryBootDisks.diskImageName: השם של קובץ האימג' של הדיסק שרוצים לטעון מראש.
    • ‫storage.secondaryBootDisks.project: שם הפרויקט שאליו שייך קובץ האימג' של הדיסק. אם לא מציינים ערך, ברירת המחדל היא הפרויקט של האשכול.
    • ‫storage.secondaryBootDisks.mode: המצב שבו צריך להשתמש בדיסק האתחול המשני. אם הערך הזה מוגדר כ-CONTAINER_IMAGE_CACHE, דיסק האתחול המשני משמש כמטמון של קובץ האימג' של הקונטיינר. הערך חייב להיות שווה ל-CONTAINER_IMAGE_CACHE או ל-MODE_UNSPECIFIED. אם לא מציינים ערך, ברירת המחדל היא MODE_UNSPECIFIED.
  • ‫placement: פרטי המיקום של המכונה:
  • ‫enableNestedVirtualization: אם להפעיל וירטואליזציה בתצורה מקוננת בצמתים. ערך ברירת המחדל הוא false.

בדוגמה הבאה מוצג כלל עדיפות שמשתמש ב-machineFamily:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset

הגדרות machineType

בשדה machineType אפשר להזין סוג מכונה עם קונפיגורציה מוגדרת (predefined) של Compute Engine, כמו n4-standard-32, או מחרוזת של סוג מכונה בהתאמה אישית, כמו n4-custom-8-20480. כדי להשתמש בסוגי מכונות בהתאמה אישית, צריך להשתמש בגרסה 1.33.2-gke.1111000 או בגרסה חדשה יותר של GKE. אפשר לציין סוגי מכונות מכל סדרת מכונות שנתמכת ב-GKE.

אתם יכולים לציין שדות spec.priorities אחרים לצד השדה machineType כדי להגדיר באופן הצהרתי את דרישות המחשוב שלכם, לדוגמה:

  • ‫spot: שימוש ב-VM במודל Spot. ברירת המחדל היא false.
  • ‫storage: הגדרת האחסון של הצומת.
    • ‫storage.bootDiskType: סוג דיסק האתחול. ב-Autopilot, יש תמיכה רק בסוג pd-balanced של bootDiskType.
    • ‫storage.bootDiskKMSKey: הנתיב למפתח Cloud KMS שמשמש להצפנת דיסק האתחול.
    • ‫storage.bootDiskSize: הגודל ב-GB של דיסק האתחול של הצומת.
    • ‫storage.localSSDCount: מספר כונני ה-SSD המקומיים שצריך לצרף לצומת. אם מציינים ערך, הוא צריך להיות לפחות 1.
  • ‫enableNestedVirtualization: אם להפעיל וירטואליזציה בתצורה מקוננת בצמתים. ערך ברירת המחדל הוא false.

בדוגמה הבאה מוצג כלל עדיפות שמשתמש ב-machineType כדי להקצות סוגי מכונות מסוג n4-standard-32:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

הגדרת GPU

כדי לבחור מעבדי GPU בכללי העדיפות, מציינים את הסוג, הכמות וגרסת מנהל ההתקן (אופציונלי) של ה-GPU בשדה gpu של כלל העדיפות. אפשר להשתמש בשדות הבאים:

  • ‫gpu.type: סוג ה-GPU, כמו nvidia-l4. למידע נוסף, קראו את המאמר בחירת תמיכה ב-GPU באמצעות Autopilot או Standard.
  • ‫gpu.count: מספר יחידות ה-GPU שרוצים לצרף. במאמר כמויות נתמכות של GPUs מפורטות הכמויות הנתמכות לפי סוג GPU.
  • ‫gpu.driverVersion: גרסת הדרייבר של NVIDIA שרוצים להתקין. התו חייב להיות default או latest. נדרשת גרסת GKE‏ 1.31.1-gke.1858000 ואילך.
  • ‫acceleratorNetworkProfile: פרופיל הרשת של מאיץ החומרה ל-GPU, למשל auto. נדרשת גרסת GKE‏ 1.35.2-gke.1842000 ואילך.

אפשר גם לציין שדות אחרים של spec.priorities, כמו VM במודל Spot, אפשרויות אחסון ומקום שמור, בשילוב עם השדות של gpu.

בדוגמה הבאה מוצג כלל ל-GPU:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true

הגדרת TPU

נדרשת גרסת GKE‏ 1.31.2-gke.1518000 ואילך

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

  • ‫tpu.type: סוג ה-TPU, למשל tpu-v5p-slice. פרטים נוספים זמינים במאמר זמינות TPU ב-GKE Autopilot.
  • ‫tpu.count: מספר יחידות ה-TPU שרוצים לצרף.
  • ‫tpu.topology: הטופולוגיה של ה-TPU שבה רוצים להשתמש, למשל "2x2x1". למידע נוסף, קראו את המאמר בחירת טופולוגיה ל-Autopilot.

אתם יכולים גם לציין שדות אחרים של spec.priorities לצד השדה tpu בכלל העדיפות, לדוגמה:

  • ‫spot: שימוש ב-VM במודל Spot. ברירת המחדל היא false.
  • ‫storage: הגדרת האחסון של הצומת.
    • ‫storage.bootDiskType: סוג דיסק האתחול.
    • ‫storage.bootDiskKMSKey: הנתיב למפתח Cloud KMS שמשמש להצפנת דיסק האתחול.
    • ‫storage.bootDiskSize: הגודל ב-GB של דיסק האתחול של הצומת.
  • ‫reservations: שימוש במקום שמור ב-Compute Engine. לפרטים, ראו את הקטע שימוש בהזמנות של Compute Engine.
  • location:
    • ‫zones: רשימה של Google Cloud אזורים שבהם GKE יכול להקצות צמתים. אם לא מציינים אזורים, GKE מקצה צמתים באזורים שמוגדרים בהגדרות של הקצאת צמתים אוטומטית באשכול. אם לא הוגדרו אזורים להקצאת צמתים אוטומטית, GKE מקצה צמתים בכל אחד מהאזורים הרגילים שבהם מישור הבקרה משתמש.

      אופציונלי: אפשר להשתמש באזור AI, כמו us-central1-ai1a. אזורי AI הם מיקומים ייעודיים שמותאמים לעומסי עבודה של AI/ML בתוך Google Cloud אזורים.

    • ‫zoneTypes: רשימה של סוגי אזורים שמציינת קבוצה של אזורים ב- Google Cloudשבהם GKE יכול להקצות צמתים. הערכים הנתמכים הם CLUSTER_DEFAULT (ברירת מחדל), STANDARD ו-AI. מידע נוסף זמין במאמר שימוש בעדיפות של סוגי אזורי מיקום.

בדוגמה הבאה מוצג כלל ליחידות TPU:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

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

  1. ‫GKE מנסה להקצות פרוסת TPU v5p עם 16 מארחים על ידי שימוש במקום שמור משותף ב-Compute Engine בשם tpu-reservation מהפרויקט reservation-project.
  2. אם אין מקומות שמורים של TPU זמינים, GKE מנסה להקצות פרוסת TPU v5p עם 16 צמתים בכמה מארחים שפועלת ב-VM במודל Spot.
  3. אם אף אחד מהכללים הקודמים לא מתקיים, GKE פועל לפי הלוגיקה שבקטע הגדרת התנהגות ההתאמה לעומס כשלא חלים כללי עדיפות.

אחרי שפורסים באשכול ComputeClass בהתאמה אישית ל-TPU, בוחרים את ה-ComputeClass בהתאמה אישית בעומס העבודה:

בנוסף, בעומסי עבודה של TPU אתם יכולים:

אזורי יעד של AI

אתם יכולים גם להשתמש במחלקת מחשוב כדי לציין אזורי AI לפודים. אזורי AI הם מיקומים ייעודיים בתוך Google Cloud אזורים שמותאמים לעומסי עבודה של AI ו-ML. במחלקה הבאה של Compute מוגדרת רשימה של אזורים לפי סדר עדיפות, שכוללת אזורי AI:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

ה-ComputeClass הזה מגדיר את GKE להקצות צמתים עם מעבדי TPU מסוג v5p או מעבדי GPU מסוג A100 לעומס העבודה. לצמתים יש את ההעדפות הבאות:

  • עדיפות 1: ניסיון להקצות את ה-TPU באזור us-central1-ai1a AI.
  • עדיפות 2: אם ה-TPU לא זמין באזור ה-AI הספציפי, מנסים להקצות אותו בכל אזור AI באזור של האשכול.
  • עדיפות 3: אם ה-TPU לא זמין באזורי AI, מנסים להקצות את ה-GPU באזורים הרגילים us-central1-a או us-central1-b.
  • אם אין GPU מסוג A100 באף אחד מהאזורים שצוינו, GKE לא ירחיב את מאגר הצמתים.

הגדרת רשת DRANET

נדרשת גרסת GKE‏ 1.35.2-gke.1842000 ואילך

כדי להשתמש ב-DRANET שמנוהל על ידי GKE כדי לבקש ולהקצות ממשקי רשת לפודים, צריך להפעיל את התכונה ב-ComputeClass. מה צריך לעשות:

  • מפעילים את מנהל ההתקן של הרשת DRANET על ידי הגדרת nodePoolConfig.dra.networking.enabled ל-true.
  • מגדירים את acceleratorNetworkProfile לערך auto ברשימה priorities.

מידע נוסף על השימוש ב-DRANET זמין במאמר הקצאת משאבי רשת באמצעות DRANET בניהול GKE.

איך GKE יוצר צמתים באמצעות כללי עדיפות

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

לדוגמה, שימו לב למפרט הבא:

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

כשפורסים עומס עבודה שמבקש ComputeClass עם כללי העדיפות האלה, GKE מתאים צמתים באופן הבא:

  1. ‫GKE ממקם Pods בכל הצמתים הקיימים שמשויכים ל-ComputeClass הזה.
  2. אם הצמתים הקיימים לא יכולים להכיל את ה-Pods,‏ GKE מקצה צמתים חדשים שמשתמשים בסדרת המכונות N4, הם VM במודל Spot ויש להם לפחות 64 vCPU.
  3. אם באזור אין מכונות וירטואליות מסוג N4 Spot עם לפחות 64 vCPU, ‏ GKE מקצה צמתים חדשים שמשתמשים במכונות וירטואליות מסוג N4 Spot שיכולות להתאים לפודים, בלי קשר למספר הליבות.
  4. אם אין מכונות וירטואליות זמינות מסוג N4 Spot באזור, GKE מקצה מכונות וירטואליות חדשות מסוג N4 על פי דרישה.
  5. אם אף אחד מהכללים הקודמים לא מתקיים, GKE פועל לפי הלוגיקה שמפורטת בקטע הגדרת התנהגות ההתאמה לעומס כשלא חלים כללי עדיפות.

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

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

אלה המגבלות של השדה priorityDefaults:

  • ‫GKE בגרסה 1.32.1-gke.1729000 ואילך.
  • לא תואם לכלל העדיפות nodepools, שלא מכיל שדות.

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

מאגרי צמתים ו-ComputeClasses ב-GKE Standard

אם אתם משתמשים במצב GKE Standard, יכול להיות שתצטרכו לבצע הגדרה ידנית כדי לוודא שהפודים של ComputeClass מתוזמנים כצפוי.

הגדרת מאגרי צמתים שנוצרו באופן ידני לשימוש ב-ComputeClass

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

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

כדי לשייך מאגר צמתים שנוצר באופן ידני ל-ComputeClass, מוסיפים תוויות צומת ואילוצי צומת למאגר הצמתים במהלך היצירה או במהלך העדכון, על ידי ציון הדגל --node-labels והדגל --node-taints, באופן הבא:

  • תווית הצומת: cloud.google.com/compute-class=COMPUTE_CLASS
  • thought Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

במאפיינים האלה, COMPUTE_CLASS הוא השם של ה-ComputeClass בהתאמה אישית.

לדוגמה, הפקודות הבאות מעדכנות יחד מאגר צמתים קיים ומשייכות את מאגר הצמתים ל-ComputeClass‏ dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

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

יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses

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

כדי לאפשר ל-GKE ליצור באופן אוטומטי מאגרי צמתים ל-ComputeClass, צריך לבצע את הפעולות הבאות:

  1. מוסיפים את השדה nodePoolAutoCreation עם הערך enabled: true למפרט של ComputeClass.
  2. אם באשכול פועלת גרסה קודמת לגרסה 1.33.3-gke.1136000 של GKE, צריך גם להפעיל הקצאת צמתים אוטומטית ברמת האשכול.

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

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

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

  • אי אפשר להשתמש בבוררי הצמתים משפחת מכונות או VM במודל Spot, כי הבוררים האלה מתנגשים עם ההתנהגות של ComputeClass. ‫GKE דוחה כל Pod שמבקש ComputeClass וגם מבקש VM במודל Spot או סדרת מכונות ספציפית.

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

    • ה-Pods בוחרים משפחת מכונות שתואמת לאחד מכללי העדיפות במחלקה שמוגדרת כברירת מחדל ברמת האשכול. לדוגמה, Pod שבוחר מכונות N4 מפעיל יצירת צומת אם למחלקה שמוגדרת כברירת מחדל ברמת האשכול יש כלל עדיפות למכונות N4.
    • ל-ComputeClass שמוגדר כברירת מחדל ברמת האשכול יש ערך של ScaleUpAnyway בשדה spec.whenUnsatisfiable. גם אם הפודים בוחרים משפחת מכונות שלא נמצאת בעדיפויות של ComputeClass, ‏GKE יוצר צמתים חדשים עם משפחת המכונות הזו.

    פודים שבוחרים משפחת מכונות שלא נמצאת בעדיפויות של מחלקת ברירת המחדל ברמת האשכול לא יפעילו יצירת צומת אם הערך של ComputeClass הוא DoNotScaleUp בשדה whenUnsatisfiable.

  • אתם יכולים להגדיר יצירה אוטומטית של מאגרי צמתים ל-ComputeClasses שמשתמשים בשדה nodepools כדי להפנות למאגרי צמתים קיימים. ‫GKE מעבד את סדרי העדיפויות לפי הסדר ומנסה להגדיל את מאגרי הצמתים הקיימים כדי למקם את ה-Pods.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

בדוגמה הזו, GKE מנסה לבצע את הפעולות הבאות:

  1. יוצרים צמתים חדשים במאגר הצמתים manually-created-pool.
  2. מקצים צומתי N4, במאגרי צומתי N4 קיימים או על ידי יצירת מאגר צמתים חדש.
  3. אם GKE לא יכול ליצור צומתי N4, הוא מנסה להרחיב אנכית את מאגרי הצמתים הקיימים של C4 או ליצור מאגרי צמתים חדשים של C4.

טירגוט מאגרי צמתים ספציפיים בהגדרה של ComputeClass

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

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

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

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

בדוגמה הזו, GKE מנסה קודם למקם פודים בהמתנה שמבקשים את ה-ComputeClass הזה בצמתים קיימים במאגרי צמתים שמסומנים בתווית של ה-ComputeClass. אם אין צמתים זמינים, GKE מנסה להקצות צמתים חדשים ב-pool1 או ב-pool2. אם GKE לא יכול להקצות צמתים חדשים במאגרי הצמתים האלה, הוא מנסה להקצות Pods חדשים ב-pool3.

הגדרת התנהגות ההתאמה לעומס כשלא חלים כללי עדיפות

המשאב המותאם אישית ComputeClass מאפשר לכם לציין מה GKE צריך לעשות אם אין צמתים שעומדים בכללי העדיפות. השדה whenUnsatisfiable במפרט תומך בערכים הבאים.

  • ‫ScaleUpAnyway: יצירת צומת חדש שמשתמש בהגדרות ברירת המחדל של המכונה באשכול. בגרסאות GKE שקודמות ל-1.33, זוהי התנהגות ברירת המחדל אם משמיטים את השדה הזה.

    ‫GKE מבצע אחת מהפעולות הבאות:

    • באשכולות Autopilot, ‏GKE ממקם את ה-Pod בצומת חדש או קיים, בלי קשר להגדרות המכונה של הצומת.
    • באשכולות Standard שלא משתמשים ביצירה אוטומטית של מאגרי צמתים, GKE מנסה להרחיב אנכית (scale up) כל מאגר צמתים שנוצר באופן ידני ומגדיר תווית ו-taint שתואמים ל-ComputeClass נתון.
    • באשכולות Standard שמשתמשים ביצירה אוטומטית של מאגרי צמתים, יכול להיות ש-GKE ייצור מאגר צמתים חדש שמשתמש בסדרת המכונות E2 שמוגדרת כברירת מחדל כדי למקם את ה-Pod.

  • ‫DoNotScaleUp: השארת ה-Pod בסטטוס Pending עד שיהיה זמין צומת שעומד בדרישות של ComputeClass. בגרסה 1.33 של GKE ואילך, זוהי התנהגות ברירת המחדל אם משמיטים את השדה הזה.

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

החל מגרסה 1.33.2-gke.1335000 של GKE, באשכולות של GKE Autopilot אתם יכולים להשתמש במיקום קומפקטי עם מדיניות מיקום בהתאמה אישית או מדיניות של עומסי עבודה. מידע נוסף זמין במאמר השוואה בין מדיניות למיקום קומפקטי לבין מדיניות עומס עבודה.

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

לדוגמה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

בתצורה הזו, GKE מחיל את המדיניות למיקום קומפקטי על כל עומסי העבודה שמשתמשים ב-ComputeClass הזה, ומקצה את הצמתים שלהם בהתאם למדיניות המשאבים הקיימת בשם my-placement-policy.

הגדרת פרמטרים להתאמה לעומס (autoscaling) לצורך איחוד צמתים

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

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

  • ‫consolidationDelayMinutes: מספר הדקות שאחריהן GKE מסיר צמתים שלא מנוצלים מספיק
  • ‫consolidationThreshold: סף הניצול של המעבד (CPU) והזיכרון, כאחוז מהמשאבים הזמינים של הצומת. ‫GKE מסיר צמתים רק אם ניצול המשאבים נמוך מהסף הזה.
  • gpuConsolidationThreshold: ערך הסף לניצול ה-GPU, כאחוז מהמשאבים הזמינים של הצומת. ‫GKE מסיר צמתים רק אם ניצול המשאבים נמוך מהסף הזה. כדאי להגדיר את הערך 100 או 0 כדי ש-GKE יאחד את כל הצמתים שבהם הניצול של ה-GPU המצורפים הוא לא 100%.

לדוגמה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

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

העברה פעילה

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

  • ‫optimizeRulePriority: GKE מחליף צמתים שמשתמשים בהגדרות בעדיפות נמוכה יותר בצמתים שמשתמשים בהגדרות בעדיפות גבוהה יותר. האפשרות הזו מספקת שחזור אוטומטי אחרי מחסור זמני בקיבולת באזור (ZONE_RESOURCE_POOL_EXHAUSTED). היא עוזרת לוודא שה-Pods ללא שמירת מצב או העמידים בפני שיבושים יחזרו בסופו של דבר להגדרת הצומת המועדפת, גם אם GKE נאלץ במקור להקצות חומרה חלופית מכלל בעדיפות נמוכה יותר.
  • ‫ensureAllDaemonSetPodsRunning: ‫GKE מחליף צמתים שיש בהם Pods של DaemonSet שלא ניתנים לתזמון בצמתים גדולים יותר שיכולים להריץ את כל ה-Pods הנדרשים של DaemonSet. האפשרות הזו עוזרת לוודא שכל ה-DaemonSets יפעלו בסופו של דבר בצמתים.

במהלך העברה פעילה, GKE מבצע את הפעולות הבאות:

  1. ‫GKE יוצר צומת חדש עם הגדרה שעומדת בדרישות של סוג ההעברה הפעיל.
  2. ‫GKE מבודד את הצומת הקיים כדי שפודים חדשים לא יפעלו בצומת הזה.

  3. ‫GKE מרוקן את הצומת הקיים, וכך מפנה Pods מהצומת. הגורמים הבאים משפיעים על מהירות הניקוז של הצומת:

    בקרי Kubernetes, כמו פריסות או משימות, יוצרים קבוצות Pod כדי להחליף את קבוצות ה-Pod שפונו. ‫GKE מתזמן את הפודים החדשים האלה בצומת החדש.

  4. אחרי שהצומת הקיים מרוקן, GKE מוחק אותו.

העברה פעילה לא משפיעה על Pods וצמתים בתרחישים הבאים:

  • העברה פעילה לא מפנה Pods עם ההערה cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • העברה פעילה לא מפנה Pods אם הפינוי יפר את PodDisruptionBudget.
  • העברה פעילה לא מחליפה צמתים שאי אפשר להסיר. לדוגמה, העברה פעילה לא מחליפה צומת אם הפעולה הזו מפרה את ההגדרה של מאגר הצמתים --min-nodes.

לפני שמפעילים העברה פעילה ב-ComputeClass, חשוב להביא בחשבון את ההשפעות האפשריות הבאות:

  • בהעברה פעילה לא מועברים נתונים שמאוחסנים באחסון מתמיד, כמו Persistent Disks ב-Compute Engine. כדי לצמצם את הסיכון לאובדן נתונים, אל תפעילו העברה פעילה ב-ComputeClasses שמשמשים לעומסי עבודה עם שמירת מצב.
  • באשכולות Standard, אם אתם משתמשים ביצירה אוטומטית של מאגרי צמתים, יכול להיות שהעברה פעילה תגרום ליצירה של מאגרי צמתים חדשים אם מאגרי הצמתים הקיימים לא עומדים בקריטריונים שהוגדרו ב-ComputeClass.
  • יכול להיות שעומסי עבודה שמשתמשים בנפחי אחסון קבועים עם משאבים של תחום מוגדר כמו Hyperdisk לא יפעלו טוב עם מיגרציה פעילה. הגבלות אזוריות והגבלות על סוגי המכונות של מוצרי Hyperdisk מסוימים יכולות להפחית את היעילות של העברה פעילה. בנוסף, יכול להיות שחלק מעומסי העבודה עם שמירת מצב לא יתמודדו טוב עם השיבוש שנגרם כתוצאה מהעברה פעילה.
  • אם מעדכנים ComputeClass קיים כדי להפעיל העברה פעילה, GKE מעביר פודים קיימים לצמתים חדשים כשמשאבי המחשוב הופכים לזמינים.

העברה פעילה לצמתים בעדיפות גבוהה יותר

סוג ההעברה הפעילה optimizeRulePriority מאפשר ל-GKE להחליף צמתים קיימים שמשתמשים בהגדרה עם עדיפות נמוכה יותר בצמתים שמשתמשים בהגדרה עם עדיפות גבוהה יותר.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

אם צומתי N4 לא היו זמינים כשפרסתם Pod עם ComputeClass כזה – לדוגמה, בגלל מחסור זמני במשאב של תחום מוגדר (ZONE_RESOURCE_POOL_EXHAUSTED) – GKE היה משתמש בצומתי C4 כאפשרות חלופית. כשהקיבולת של N4 תתאושש במיקום שלכם או כשהמכסה תגדל, GKE יעביר באופן אוטומטי את עומסי העבודה בחזרה לצומתי N4:

  1. ‫GKE יוצר צומת N4 חדש.
  2. ‫GKE מבודד ומרוקן את הצומת הקיים של C4. ה-Pods שלכם יפונו, בהתאם לכל הגדרות PodDisruptionBudgets וסיום תקין.
  3. בקרי Kubernetes יוצרים Pods כדי להחליף את ה-Pods שפונו. ה-Pods החדשים האלה פועלים בצומת N4.
  4. אחרי שכל הפודים בצומת C4 מרוקנים, GKE מוחק את הצומת.

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

העברה פעילה להרצת פודים של DaemonSet שלא ניתנים לתזמון

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

לדוגמה, המפרט הבא של ComputeClass מגדיר את סדרת המכונות N4:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  activeMigration:
    ensureAllDaemonSetPodsRunning: true

נניח שיצרתם פריסה של Pod אחד שמשתמש ב-ComputeClass הזה וביקשתם שני מעבדי vCPU. כדי להריץ את ה-Pod הזה, GKE יצר צומת n4-standard-2. בהמשך, אתם יוצרים DaemonSet שגם מבקש שני מעבדי vCPU. אי אפשר להריץ את ה-Pod של DaemonSet בצומת n4-standard-2. בתרחיש הזה, GKE מבצע את הפעולות הבאות:

  1. ‫GKE יוצר צומת שמשתמש בסוג מכונה גדול יותר של N4, כמו n4-standard-4, שיכול להריץ את ה-Pod ואת ה-DaemonSet Pod. ה-Pod של DaemonSet בהמתנה מתוזמן בצומת החדש הזה.
  2. ‫GKE מבודד ומרוקן את הצומת n4-standard-2.
  3. כשה-Pod שלכם מפונה, ה-Deployment יוצר Pod חלופי. ‫GKE מתזמן את ה-Pod הזה בצומת n4-standard-4, לצד ה-Pod של DaemonSet.
  4. אחרי שכל הפודים מועברים מהצומת n4-standard-2, ‏GKE מוחק את הצומת.

שימוש במקומות שמורים ב-Compute Engine

זמין ב-GKE מגרסה 1.31.1-gke.2105000 ואילך

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

כדי להשתמש במקומות שמורים ב-Compute Engine באמצעות ComputeClass בהתאמה אישית, אתם יכולים להשתמש בשיטות הבאות:

  • יצירה אוטומטית של מאגרי צמתים: GKE יוצר באופן אוטומטי מאגרי צמתים חדשים כדי לנצל את ההזמנות שציינתם. מידע נוסף זמין במאמר יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses.
  • מאגרי צמתים שנוצרו באופן ידני: באשכולות במצב רגיל, אפשר לנתב עומסי עבודה למאגרי צמתים שנוצרו באופן ידני על ידי ציון השדה spec.priorities.nodepools ב-ComputeClass.

החל מגרסה 1.36.0-gke.3204000 של GKE, אתם יכולים להגדיר את עומסי העבודה כך שיצרכו כל הזמנה תואמת בלי לחזור לקיבולת על פי דרישה, באמצעות הגדרת הזיקה AnyThenFail.

שימוש בהקצאות במאגרי צמתים שנוצרו באופן ידני

כדי להשתמש במאגרי צמתים שנוצרו ידנית באשכולות Standard באמצעות ComputeClasses, מבצעים את הפעולות הבאות:

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

  2. יוצרים ComputeClass שמשתמש בכלל העדיפות nodepools כדי לבחור את מאגרי הצמתים שיצרתם באופן ידני.

לדוגמה, נניח שיש לכם שני מאגרי צמתים, וכל אחד מהם מקושר להזמנת קיבולת נפרדת. אתם מעדיפים שהפודים ישתמשו בקיבולת השמורה במאגר הצמתים reservation-pool-1 במקום במאגר הצמתים reservation-pool-2. ה-ComputeClass שמיישם את ההעדפות האלה דומה לדוגמה הבאה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

בדוגמה הזו, GKE מנסה למקם פודים קודם ב-reservation-pool-1, כי כלל העדיפות הזה מופיע ראשון בשדה priorities.

יצירה אוטומטית של מאגרי צמתים לניצול הקצאות מקום

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

  • ב-ComputeClass צריך להפעיל יצירה אוטומטית של מאגרי צמתים.
  • אפשר להשתמש במאגרים שמורים שהם לא TPU רק אם מוגדר machineType או machineFamily.
  • ב-ComputeClasses שמגדירים כונני SSD מקומיים צריך להשתמש בכלל העדיפות machineType, ולא ב-machineFamily. פרטים נוספים זמינים בקטע סוג הכלל machineType.
  • ב-ComputeClasses שמציינים הזמנות ל-machineType עם כונני SSD מקומיים מצורפים, צריך לכלול שדה localSSDCount: באופן מפורש.

נבחן את המפרט הבא של ComputeClass לדוגמה, שנותן עדיפות לשימוש במקום שמור ספציפי שמשותף כשמקצים מכונות a3-highgpu-1g. אם סוגי המכונות שבעדיפות לא זמינים, GKE חוזר לכל ההזמנות התואמות במפרט:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

אם פורסים Pod שמשתמש ב-ComputeClass‏ accelerator-reservations,‏ GKE מנסה קודם להשתמש בהקצאה a3-shared-reservation כשיוצרים מכונות a3-highgpu-1g חדשות כדי להריץ את ה-Pod. אם במקום השמור הספציפי הזה אין קיבולת זמינה, GKE מנסה להגדיל את מספר המכונות ל-a3-highgpu-1g באמצעות כל מקום שמור תואם. אם אין מקומות שמורים זמינים, GKE חוזר ל-a3-highgpu-1g VM במודל Spot. אם אין מכונות וירטואליות זמינות במחיר Spot, פעולת ההתאמה לעומס תיכשל.

בדוגמה הזו, שני כללי העדיפות עם ההפניות להזמנה דורשים במפורש את השדה localSSDCount:, כי תצורת המכונה a3-highgpu-1g כוללת כונני SSD מקומיים.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

אפשר להשתמש בסוגים הבאים של הזמנות:

  • מקומות שמורים ספציפיים לפרויקט יחיד: מגדירים את השדות הבאים:

    • מציינים את שם ההזמנה בשדה reservations.specific.name.
    • מוודאים שהערך בשדה reservations.affinity הוא Specific.

  • Specific shared reservations: מגדירים את השדות הבאים:

    • מציינים את שם ההזמנה בשדה reservations.specific.name.
    • בשדה reservations.specific.project, מציינים את מזהה הפרויקט שההזמנה שייכת לו.
    • מוודאים שהערך בשדה reservations.affinity הוא Specific.

  • Any matching reservations with fallback: מגדירים את השדות הבאים:

    • מוודאים שהערך בשדה reservations.affinity הוא AnyBestEffort.
    • אל תגדירו שם או פרויקט להזמנה.

  • כל ההזמנות התואמות ללא חלופה: מגדירים את השדות הבאים:

    • מוודאים שהערך בשדה reservations.affinity הוא AnyThenFail.
    • אל תגדירו שם או פרויקט להזמנה.
    • זה שינוי אופציונלי. כדי לאכוף את הכישלון באופן מחמיר אם כל המקומות השמורים התואמים נוצלו, מגדירים את ההגדרה whenUnsatisfiable: DoNotScaleUp ברמה spec של ComputeClass.

כדי להזמין TPU, צריך לבחור ב-Specific affinity. ההגדרות reservations.affinity: AnyBestEffort ו-reservations.affinity: AnyThenFail לא נתמכות.

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

  • הזמנות ספציפיות: המערכת של GKE מנסה את כלל העדיפות הבא ב-ComputeClass.
  • ‫Any matching reservations with fallback (AnyBestEffort): המערכת של GKE מנסה להקצות צומת על פי דרישה שעומד בדרישות של כלל העדיפות הזה. אם GKE לא יכול להקצות צומת על פי דרישה, הוא מנסה את כלל העדיפות הבא ב-ComputeClass.
  • כל המקומות השמורים התואמים בלי חלופה (AnyThenFail): ‫GKE מדלג על הקצאת צומת על פי דרישה ומנסה את כלל העדיפות הבא ב-ComputeClass. אם לא חלים כללים אחרים, פעולת ההתאמה תיכשל בהתאם לערך של ההגדרה whenUnsatisfiable.

אם GKE לא יכול לעמוד בדרישות של אף אחד מכללי העדיפות של ComputeClass, מתרחשת ההתנהגות כשלא חלים כללים.

שימוש בבלוקים ספציפיים של הזמנות

החל מגרסה 1.31.4-gke.1072000 של GKE, אפשר לטרגט בלוק ספציפי של הקצאת מקום בהקצאת מקום שמגובה בחומרה. התכונה הזו זמינה למכונות מסוג A3 Ultra ו-A4.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

מחליפים את RESERVATION_BLOCK_NAME בשם של בלוק ההזמנה הרצוי.

החל מגרסה 1.33.1-gke.1788000 של GKE, אפשר לטרגט בלוק משנה ספציפי של הקצאת מקום בתוך בלוק הקצאת מקום. התכונה הזו זמינה במכונות מסוג A4X.

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

כשמשתמשים בתכונה הזו, חשוב לשים לב לנקודות הבאות:

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

מספר הצמתים המינימלי

זמין בגרסה 1.36.3-gke.1253000 של GKE ואילך.

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

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

  • אם הקיבולת היא לכל ה-ComputeClass, ‏ GKE שומר לפחות על מספר הצמתים הזה בכל כללי העדיפות ב-ComputeClass. אם הקיבולת מיועדת לכלל עדיפות ספציפי, GKE שומר לפחות על מספר הצמתים הזה לכלל העדיפות הזה.
  • אם מספר הצמתים קטן מהמספר המינימלי שצוין, GKE יוצר באופן אוטומטי צמתים חדשים כדי לשמור על הקיבולת המינימלית, גם אם הצמתים הנוספים האלה לא מריצים אף אחד מה-Pods שלכם.
  • ‫GKE לא מצמצם את הצמתים שמרכיבים את הקיבולת המינימלית, גם אם הצמתים האלה ריקים.
  • הקיבולת שצוינה היא ערך מינימלי. במהלך אירועי הגדלה, GKE יכול לחרוג ממספר הצמתים המינימלי כדי להריץ Pods בהמתנה.
  • אם מפעילים את האפשרות active migration to higher priority nodes, ‏GKE יכול להחליף את הצמתים של הקיבולת המינימלית בצמתים מכלל עם עדיפות גבוהה יותר. עם זאת, GKE לא מחליף צומת אם ההחלפה גורמת לכך שכלל עדיפות יהיה מתחת לקיבולת המינימלית שלו.
  • יכול להיות שזמינות המשאבים או המכסות ימנעו מ-GKE ליצור צמתים לדרישת הקיבולת המינימלית.
  • אם GKE לא יכול ליצור מספיק צמתים לקיבולת המינימלית של כלל עדיפות, GKE לא חוזר לכללי עדיפות אחרים. במקום זאת, GKE יוצר את הצמתים החסרים לכלל העדיפות הזה כשמתפנה קיבולת.
  • יכול להיות שצמתים עדיין יימחקו ויוחלפו כדי לשמור על תקינות האשכול (לדוגמה, כדי לתקן צומת לא תקין או להחליף VM במודל Spot). ‫GKE יוצר באופן אוטומטי צמתים חדשים כדי לשמור על הקיבולת המינימלית.

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

  • קיבולת מינימלית ל-ComputeClass: אם מציינים את השדה minimumCapacity.targetNodeCount לכל ה-ComputeClass, כל כללי העדיפות צריכים לבקש באופן ישיר או עקיף סוג מכונה ספציפי. כל כלל עדיפות חייב להשתמש לפחות באחת מההגדרות הבאות:

    • machineType
    • gpu
    • tpu
    • הזמנת קיבולת ספציפית

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

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

    • machineType
    • gpu
    • tpu
    • הזמנת קיבולת ספציפית

בדוגמאות הבאות מוצגת הגדרת הקיבולת המינימלית ל-ComputeClass ולכלל עדיפות:

  • ComputeClass:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: gpu-class-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  # Define a global minimum capacity of 5 nodes for this ComputeClass
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - gpu:
      type: "nvidia-tesla-a100"
      count: 1
    machineType: "a2-highgpu-1g"
  - gpu:
      type: "nvidia-l4"
      count: 1
    machineType: "g2-standard-8"

  • כלל עדיפות:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tiered-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: "n2-standard-16"
    # Maintain at least three nodes of this specific configuration
    minimumCapacity:
      targetNodeCount: 3
  - machineType: "e2-standard-4"

קיבולת מינימלית ל-ComputeClass ולכללי העדיפות שלו

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

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

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

ב-ComputeClass הזה, GKE יוצר שלושה צומתי e2-standard-16 לכלל העדיפות השני. הצמתים האלה נכללים במינימום של חמישה צמתים ב-ComputeClass. בשני הצמתים הנותרים, GKE מנסה קודם ליצור צמתים מסוג n2-standard-16. אם צומתי n2-standard-16 לא זמינים, GKE חוזר לצומתי e2-standard-16.

אם מפעילים את ההגדרה active migration to higher priority nodes, יכול להיות ש-GKE יחליף בהמשך עד שני צמתים מסוג e2-standard-16 בצמתים מסוג n2-standard-16. עם זאת, GKE שומר לפחות שלושה צומתי e2-standard-16 לקיבולת המינימלית של כלל העדיפות השני.

אם במקום זאת מגדירים את השדה targetNodeCount בכלל העדיפות השני לערך 6, ‏GKE יוצר שישה צומתי e2-standard-16. ששת הצמתים האלה עומדים בדרישת המינימום של ComputeClass לחמישה צמתים, ולכן GKE לא יוצר צמתים מסוג n2-standard-16 בשביל הקיבולת המינימלית.

התאמה אישית של הגדרות המערכת של הצומת

אתם יכולים להתאים אישית פרמטרים מסוימים ב-kubelet ובליבת Linux באמצעות השדה nodeSystemConfig במפרט של ComputeClass. אפשר לציין את השדה הזה בכל כלל עדיפות שמגדיר סדרת מכונות או סוג מכונה ב-Compute Engine. אפשר גם להגדיר ערכים גלובליים כברירת מחדל לכל שדות התצורה של מערכת הצמתים שהושמטו בכללי העדיפות, על ידי הוספת השדה nodeSystemConfig לשדה priorityDefaults ב-ComputeClass.

התכונה הזו זמינה ב-GKE מגרסה 1.32.1-gke.1729000 ואילך.

למידע נוסף, קראו את המאמרים הבאים:

ציון תוויות ופגמים של צמתים

בשדות nodeLabels ו-taints במפרט של ComputeClass, אתם יכולים להגדיר הגדרות שתואמות למאגרי הצמתים הקיימים וגם קובעות את היצירה של מאגרים חדשים. אפשר להחיל את ההגדרות האלה באופן גלובלי בשדה nodePoolConfig לכל ה-ComputeClass, או להגדיר אותן לעדיפות ספציפית באמצעות השדה priority. עם זאת, צריך לוודא שהתוויות וה-taints שמוגדרים ברמת העדיפות לא חופפים לאלה שהוגדרו באופן גלובלי.

התכונות האלה זמינות במוצרים הבאים:

  • תוויות של צומתי עדיפות ב-GKE מגרסה 1.33.2-gke.1111000 ואילך.
  • ‫Priority taints בגרסה 1.33.4-gke.1350000 ואילך של GKE.
  • תוויות ופגמים גלובליים של צמתים ב-GKE בגרסה 1.34.1-gke.3084002 ואילך.

בנוסף לתוויות בהתאמה אישית, GKE מקצה באופן אוטומטי את תווית המערכת cloud.google.com/compute-class לכל הצמתים שהוקצו ל-ComputeClass או שמשויכים אליו. אפשר לסנן ולפרט צמתים לפי ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

מידע נוסף זמין במאמר ComputeClass CustomResourceDefinition.

הגדרת ברירת המחדל של הכתם בארכיטקטורת Arm

כברירת מחדל, GKE מוסיף את הטיינט kubernetes.io/arch=arm64:NoSchedule לכל צומתי ה-Arm, כולל צמתים שנוצרו בשביל ComputeClasses בהתאמה אישית. ‫GKE מתזמן רק עומסי עבודה שיש להם סובלנות לטיינט הזה בצומתי Arm, וכך מונע מעומסי עבודה של x86 לפעול בארכיטקטורה לא תואמת. אם עומסי העבודה שלכם תואמים גם ל-x86 וגם ל-Arm, אתם יכולים להשבית את הכתם הזה שמוגדר כברירת מחדל. כל עומס עבודה שבוחרים בו את ComputeClass יכול לפעול בצומתי Arm, גם אם לעומסי העבודה האלה אין את הסבילות לארכיטקטורת Arm.

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

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

taintConfig:
  architectureTaintBehavior: NONE

בשדה הזה נדרש אשכול שפועל ב-GKE בגרסה 1.36.2-gke.1498000 ואילך.

ברירת המחדל של ComputeClasses לאשכולות ולמרחבי שמות

אתם יכולים להגדיר את GKE כך שיחיל ComputeClass כברירת מחדל על פודים שלא בוחרים ComputeClass ספציפי. אתם יכולים להגדיר ComputeClass כברירת מחדל למרחבי שמות ספציפיים או לאשכול שלם. במאמר החלת ComputeClasses על Pods כברירת מחדל מוסבר איך להגדיר את האשכולות או מרחבי השמות עם מחלקת ברירת מחדל.

מאגרי צמתים של קבוצות

החל מגרסה 1.32.2-gke.1359000 של GKE, אתם יכולים לקבץ כמה מאגרי צמתים ליחידה לוגית אחת שנקראת אוסף, באמצעות השדה nodePoolGroup במפרט של ComputeClass. הקיבוץ הזה מאפשר להחיל הגדרות משותפות על מאגרי צמתים רבים.

אוסף של מארחים מרובים של TPU

נדרשת גרסה 1.31.2-gke.1518000 ומעלה של GKE. זמין רק ב-TPU Trillium (v6e)

אתם יכולים לקבץ את פריסת ה-TPU עם כמה מארחים כדי להגדיר יעד ברמת השירות (SLO) לכל מאגרי הצמתים באוסף. כדי לקבץ מאגרי צמתים, מציינים את שם הקבוצה בשדה nodePoolGroup. כל מאגרי הצמתים שהוקצו באמצעות ComputeClass הזה שייכים לאותה קבוצה.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

למידע נוסף, קראו את המאמרים הבאים:

הגדרת מאגר הצמתים

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

ציון סוג התמונה

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

מידע נוסף זמין במאמר תמונות של צמתים.

חשבון שירות

השדה serviceAccount מציין את חשבון השירות Google Cloud שמשמש את הצמתים במאגרי הצמתים שמנוהלים על ידי ComputeClass. בדוגמה הבאה אפשר לראות איך מציינים את serviceAccount ב-ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

מידע נוסף זמין במאמר מידע על חשבונות שירות ב-GKE.

הגדרת סוג עומס העבודה (workload) ל-SLO של TPU

החל מגרסה 1.32.2-gke.1359000 של GKE, אתם יכולים להגדיר את יעד רמת השירות (SLO) לעומסי העבודה של ה-TPU באמצעות השדה workloadType ב-nodePoolConfig. הערך בשדה הזה מציין ל-GKE את השימוש המיועד למשאבי ה-TPU. אפשר להזין בשדה workloadType את הערכים הבאים:

  • ‫HIGH_AVAILABILITY: משתמשים בערך הזה לעומסי עבודה שמתמקדים בזמינות, כמו הצגת הסקות, כדי להגביל ולייעל את ההפרעות.
  • ‫HIGH_THROUGHPUT: השתמשו בערך הזה למשימות אצווה או למשימות אימון שדורשות שכל התשתית הבסיסית תפעל רוב הזמן כדי להתקדם. אפשר להשתמש בערך הזה רק אם מציינים גם את nodePoolGroup.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

למידע נוסף, קראו את המאמרים הבאים:

הגדרת ארגז החול

נדרשת גרסת GKE‏ 1.36.2-gke.1368000 ואילך

אתם יכולים לבודד עומסי עבודה מהליבה המארחת של הצמתים, על ידי הפעלת ה-Pods בארגזי חול (sandboxes) באמצעות GKE Sandbox. ב-ComputeClasses, אתם יכולים להפעיל את GKE Sandbox ולבחור סוג של ארגז חול לצמתים באמצעות השדה nodePoolConfig.sandbox. אלה סוגי ארגזי החול שנתמכים:

  • gvisor: נדרשת גרסת GKE‏ 1.36.2-gke.1368000 ואילך.
  • ‫microvm: נדרשת גרסת GKE‏ 1.37.0-gke.4713000 ואילך וצמתים שמשתמשים בווירטואליזציה בתצורה מקוננת.

למידע נוסף על התכונות, המגבלות והדרישות של סוגי ארגזי החול האלה, קראו את המאמר מידע על GKE Sandbox.

כדי להשתמש ב-ComputeClass כדי להפעיל ולבקש ארגזי חול, קראו את המאמר בידוד עומסי עבודה באמצעות GKE Sandbox.

הגדרת המטא-נתונים של המכונה

נדרשת גרסת GKE‏ 1.36.2-gke.1498000 ואילך.

השדה instanceMetadata במפרט של ComputeClass מאפשר להוסיף צמדי מפתח/ערך של מטא-נתונים בהתאמה אישית ישירות למכונות הווירטואליות של Compute Engine, שהוקצו למאגרי הצמתים על ידי המידרוג האוטומטי או הקצאת צמתים אוטומטית. זה דומה לציון הדגל --metadata כשיוצרים מאגרי צמתים באופן ידני באמצעות Google Cloud CLI.

אפשר להגדיר מטא-נתונים בהתאמה אישית למכונות באמצעות ComputeClasses רק באשכולות GKE במצב רגיל (spec.autopilot.enabled: false).

אפשר לציין את instanceMetadata בשני מקומות ב-ComputeClass:

  • הגדרה גלובלית (spec.nodePoolConfig.instanceMetadata): מחילה צמדי מפתח/ערך של מטא-נתונים בהתאמה אישית באופן גלובלי על כל המכונות הווירטואליות ומאגרי הצמתים החדשים שנוצרו על ידי ComputeClass.
  • שינויים ספציפיים לעדיפות (spec.priorities[].instanceMetadata): המערכת מחילה צמדי מפתח/ערך של מטא-נתונים בהתאמה אישית רק כש-GKE מקצה צמתים באמצעות העדיפות הספציפית הזו בהיררכיה.

אם אותו מפתח מטא-נתונים מוגדר גם ב-nodePoolConfig.instanceMetadata וגם ב-priorities[].instanceMetadata, הערך שצוין ב-priorities[].instanceMetadata מבטל את הערך הגלובלי.

סכימה וכללי אימות

כשמגדירים את instanceMetadata, צריך לפעול לפי אילוצי האימות הבאים:

  • סוג: צמדי מפתח/ערך במבנה של map (map[string]string).
  • מגבלות גודל:
    • הגודל המקסימלי של ערך מטא-נתונים בודד הוא 32KB‏ (32,768 בייטים).
    • הגודל המשולב המקסימלי של כל צמדי המפתח/ערך של המטא-נתונים בכל המשאב ComputeClass לא יכול להיות יותר מ-512KB‏ (524,288 בייטים).
  • מגבלות ופורמט של מפתחות:
    • אפשר להגדיר עד 32 צמדים של מפתח/ערך של מטא-נתונים בהתאמה אישית לכל ComputeClass.
    • המפתחות צריכים להיות באורך של פחות מ-128 תווים ויכולים להכיל רק תווים אלפאנומריים, מקפים (-) וקווים תחתונים (_).
  • מפתחות שמורים: GKE ו-Compute Engine שומרים מפתחות ספציפיים של מטא-נתונים של המערכת שנדרשים לניהול פעולות באשכול (כמו kube-env,‏ user-data,‏ startup-script ו-cluster-name). אי אפשר לשנות או לציין מפתחות שמורים של מטא-נתונים של המערכת.
  • חוסר שינוי במאגרי צמתים קיימים: שינוי של instanceMetadata ב-ComputeClass קיים חל רק כש-GKE מקצה מאגרי צמתים חדשים (כש-nodePoolAutoCreation מופעל). מאגרי הצמתים והמכונות הווירטואליות הקיימים לא משתנים רטרואקטיבית.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

הגדרת מגבלות להתאמה לעומס (autoscaling)

זמין ב-GKE מגרסה 1.36.2-gke.2064000 ואילך.

כברירת מחדל, GKE מקצה צמתים חדשים ל-ComputeClass עד מגבלות ההתאמה האוטומטית לעומס של האשכול כולו. כדי לאכוף גבולות מחמירים יותר של משאבים ל-ComputeClass ספציפי, כמו הגבלת המספר המקסימלי של מעבדי GPU, מעבדי CPU או סך כל הצמתים שאפשר להקצות ל-ComputeClass, אתם יכולים להחיל משאב מותאם אישית של CapacityQuota.

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

הגדרת צומתי GKE מוגנים

נדרשת גרסה ‎1.36.3-gke.1244000 או גרסה חדשה יותר של GKE

כדי להגדיר את התכונות של צומתי GKE מוגנים, כמו אתחול מאובטח ומעקב אחרי תקינות, למאגרי צמתים שנוצרו אוטומטית ומנוהלים על ידי ComputeClass, צריך לציין את השדה shieldedInstanceConfig בקטע nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig).

ערכי ברירת המחדל של shieldedInstanceConfig תלויים במצב האשכול ובהגדרות של ComputeClass:

  • באשכולות במצב רגיל: כשמאתחלים את shieldedInstanceConfig במהלך התאמה של nodePoolAutoCreation, השדה enableIntegrityMonitoring מוגדר כברירת מחדל ל-true והשדה enableSecureBoot מוגדר כברירת מחדל ל-false, אלא אם מגדירים אותם באופן מפורש.
  • באשכולות Autopilot (או כש-spec.autopilot.enabled הוא true ב-ComputeClass): ערך ברירת המחדל של השדות enableSecureBoot ו-enableIntegrityMonitoring הוא true ואי אפשר להשבית אותם.

בדוגמה הבאה מוסבר איך להגדיר את השדה shieldedInstanceConfig בתוך הבלוק nodePoolAutoCreation כדי להפעיל את התכונות של צומתי GKE מוגנים במאגרי צמתים שנוצרו באופן אוטומטי:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

בקשת ComputeClasses בעומסי עבודה (workloads)

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

לדוגמה, המניפסט הבא מבקש את ComputeClass cost-optimized:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

בוררי צמתים לתוויות של צומתי מערכת

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

  • k8s.io
  • cloud.google.com
  • gke.io
  • node.kubernetes.io/instance-type

בגרסה 1.32.3-gke.1499000 של GKE ואילך, אפשר לפרוס עומסי עבודה שמשתמשים בבורר צמתים כדי לבחור תוויות מערכת ו-ComputeClass בו-זמנית. אם בוחרים תוויות מערכת ב-Pods שבוחרים ComputeClasses, צריך לוודא שה-Pods האלה מתוזמנים כצפוי. אם יש התנגשות בין ההגדרות של ComputeClass לבין בוררי הצמתים ב-Pod, יכולות להיווצר בעיות כמו:

  • ‫GKE לא יכול ליצור צמתים שמשתמשים בהגדרת העדיפות הגבוהה ביותר של ComputeClass.
  • ה-Pod נשאר בסטטוס Pending.

בנוסף, GKE דוחה כל Pod שבוחר תוויות מערכת שיש להן שדה תואם במפרט ComputeClass. כשמשתמשים ב-ComputeClasses, צריך לעדכן את עומסי העבודה כדי להסיר את התוויות הבאות מבוררי הצמתים, ולהגדיר את השדה המתאים ב-ComputeClasses שיוצרים:

תווית הצומת השדה ComputeClass
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType
node.kubernetes.io/instance-type priorities.machineType

מעקב אחרי השימוש ב-ComputeClass

אתם יכולים לעקוב אחרי האינטראקציה של המידרוג האוטומטי של האשכול עם ComputeClasses באמצעות מדדי Cloud Monitoring. מדדים כמו kubernetes.io/autoscaler/cluster_pending_pods_per_ccc,‏ kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc ו-kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc עוקבים אחרי Pods בהמתנה, ניסיונות להקצאת צמתים וכשלים בהקצאה. המדדים האלה זמינים ב-GKE בגרסה 1.37 ואילך.

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

מגבלות

  • שם ComputeClass לא יכול להתחיל ב-gke או ב-autopilot (שמורים ל-ComputeClasses של המערכת).
  • באשכולות מסוימים יש שיעורים גבוהים של יצירה ומחיקה של Pods, מה שמאריך את זמן ההערכה של ה-autoscaler של האשכול. במהלך פעולת התאמה לעומס, יכול להיות שלמנגנון ההתאמה האוטומטית לעומס של האשכול לא יהיה זמן להעריך את כללי העדיפות הבאים ב-ComputeClass לפני שתקופת ההמתנה של כללי העדיפות הקודמים תסתיים. כתוצאה מכך, יכול להיות שה-Pods יישארו בסטטוס Pending. כדי לפתור את הבעיה, צריך להפחית את קצב היצירה והמחיקה של Pods, למשל על ידי השבתת ההעברה הפעילה של ComputeClass.

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