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

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

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

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

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

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

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

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

תרחישי שימוש ב-ComputeClasses בהתאמה אישית

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

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

איך פועלות ComputeClasses מותאמות אישית

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

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

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

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

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

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

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

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

kubectl describe crd computeclasses.cloud.google.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרות של machineFamily

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

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

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

בדוגמה הבאה מוצג כלל עדיפות שמשתמש בפונקציה 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. כדי להשתמש בסוגי מכונות בהתאמה אישית, צריך להשתמש ב-GKE בגרסה 1.33.2-gke.1111000 ואילך. אפשר לציין סוגי מכונות מכל סדרת מכונות ש-GKE תומך בה.

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

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

בדוגמה הבאה מוצג כלל עדיפות שמשתמש ב-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 בכללי העדיפות, מציינים את הסוג, המספר ו-driverVersion (אופציונלי) של ה-GPU בשדה gpu של כלל העדיפות. השדות הבאים נתמכים:

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

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

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

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

הגדרת TPU

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

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

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

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

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

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

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

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

בנוסף, לעומסי עבודה של TPU אפשר לבצע את הפעולות הבאות:

טירגוט אזורים מבוססי-AI

אפשר גם להשתמש בסוג מחשוב כדי לציין אזורי AI עבור ה-Pods. אזורי AI הם מיקומים מיוחדים בתוך Cloud de Confiance by S3NS אזורים שעברו אופטימיזציה לעומסי עבודה של AI/ML. בסוג המכונה הבא מוגדרת רשימה של אזורים עם עדיפות, כולל אזורים עם 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 לא יגדיל את מספר הצמתים במאגר הצמתים.

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

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

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

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

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

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

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

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

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

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

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

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

  • תווית הצומת: cloud.google.com/compute-class=COMPUTE_CLASS
  • 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 מותאם אישית אחד. תאי Pod ש-GKE מתזמן במאגרי הצמתים האלה שנוצרו באופן ידני מפעילים יצירת צמתים בתוך מאגרי הצמתים האלה רק במהלך אירועים של התאמה אוטומטית לעומס.

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

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

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

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

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

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

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

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

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

    • ה-Pods בוחרים משפחת מכונות שתואמת לאחד מכללי העדיפות במחלקה שמוגדרת כברירת מחדל ברמת האשכול. לדוגמה, אם יש Pod שבוחר מופעי N4, יופעל תהליך ליצירת צומת אם למחלקה שמוגדרת כברירת מחדל ברמת האשכול יש כלל עדיפות למופעי N4.
    • ל-ComputeClass שמוגדר כברירת מחדל ברמת האשכול יש ערך של ScaleUpAnyway בשדה spec.whenUnsatisfiable. גם אם ה-Pods בוחרים משפחת מכונות שלא נמצאת בעדיפויות של 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 מנסה לתזמן את ה-Pods בהמתנה במאגרי הצמתים האלה. יכול להיות ש-GKE ייצור צמתים חדשים במאגרי הצמתים האלה כדי למקם את ה-Pods.

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

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

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

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

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

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

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

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

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

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

בקשה למדיניות בנושא מיקומי מודעות

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

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

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

דוגמה:

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

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

העברה פעילה

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

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

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

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

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

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

  4. אחרי שהנתונים בשלב הקיים יועברו, GKE ימחק את השלב.

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

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

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

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

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

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

  1. ‫GKE יוצר צומת N4 חדש.
  2. ‫GKE מבודד את צומת C4 הקיים ומרוקן אותו. ה-Pods שלכם מוצאים מהמערכת, בהתאם לכל הגדרה של PodDisruptionBudgets ושל סיום תקין.
  3. בקרי Kubernetes יוצרים קבוצות Pod כדי להחליף את קבוצות ה-Pod שהוצאו. ה-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. כשמפנים את הפוד, ה-Deployment יוצר פוד חלופי. ‫GKE מתזמן את ה-Pod הזה בצומת n4-standard-4, לצד ה-Pod של DaemonSet.
  4. אחרי שכל העומס מוסר מצומת n4-standard-2, ‏ GKE מוחק את הצומת.

שימוש בהזמנות ב-Compute Engine

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

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

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

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

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

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

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

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

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

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

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

  • ב-ComputeClass צריך להפעיל יצירה אוטומטית של מאגר צמתים.
  • אפשר להשתמש בהזמנות ללא TPU רק אם מוגדר machineType או machineFamily.
  • ב-ComputeClasses שמגדירים כונני SSD מקומיים צריך להשתמש בכלל העדיפות machineType ולא ב-machineFamily. פרטים נוספים מופיעים בקטע machineType rule type.
  • ‫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 שמשתמש ב-accelerator-reservations ComputeClass,‏ GKE מנסה קודם להשתמש ב-a3-shared-reservation reservation כשיוצרים מכונות a3-highgpu-1g חדשות להרצת ה-Pod. אם אין קיבולת זמינה בהזמנה הספציפית הזו, ‏ GKE מנסה להגדיל את מספר המופעים של a3-highgpu-1g באמצעות הזמנה תואמת כלשהי. אם אין גישה להזמנות, GKE חוזר לשימוש במכונות וירטואליות מסוג a3-highgpu-1gSpot. לבסוף, אם אין מכונות וירטואליות מסוג Spot, פעולת ההרחבה נכשלת.

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

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

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

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

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

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

בהזמנות של TPU נדרשת זיקה ספציפית. אין תמיכה ב-reservations.affinity: AnyBestEffort

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

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

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

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

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

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

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

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

אפשר להתאים אישית פרמטרים מסוימים ב-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 ואילך.
  • דחיות בעדיפות בגרסת GKE‏ 1.33.4-gke.1350000 ואילך.
  • תוויות וכתמים גלובליים של צמתים ב-GKE בגרסה ‎1.34.1-gke.3084002 ואילך.

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

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

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

קיבוץ מאגרי צמתים

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

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

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

אתם יכולים לקבץ את הפריסה של TPU multi-host כדי להגדיר יעד לרמת השירות (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 מציין את חשבון השירות שבו נעשה שימוש בצמתים במאגרי צמתים שמנוהלים על ידי ComputeClass. Cloud de Confiance by S3NS בדוגמה הבאה אפשר לראות איך מציינים את serviceAccount ב-ComputeClass:

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

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

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

החל מגרסה GKE 1.32.2-gke.1359000, אפשר להגדיר את יעד רמת השירות (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

מידע נוסף זמין בדפים הבאים:

בקשה ל-ComputeClasses בעומסי עבודה

כדי להשתמש ב-ComputeClass בהתאמה אישית, ה-Pod צריך לבקש במפורש את ה-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"

Node selectors for system node labels

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

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

ב-GKE בגרסה 1.32.3-gke.1499000 ואילך, אפשר לפרוס עומסי עבודה שמשתמשים בבורר צמתים כדי לבחור תוויות מערכת ו-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 לא יכול להתחיל ב-gke או ב-autopilot (השמות האלה שמורים ל-ComputeClass של המערכת).
  • באשכולות מסוימים יש שיעורים גבוהים של יצירה ומחיקה של Pod, מה שמגדיל את זמן ההערכה של הכלי לשינוי גודל האשכול. במהלך פעולת התאמה לעומס, יכול להיות שלא יהיה למידרוג אוטומטי של האשכול מספיק זמן להעריך כללי עדיפות עוקבים ב-ComputeClass לפני שתקופת ההשהיה לפני ניסיון חוזר של כללי עדיפות קודמים תסתיים. כתוצאה מכך, יכול להיות ש-Pods יישארו במצב Pending (בהמתנה). כדי לצמצם את הבעיה הזו, צריך להקטין את קצב היצירה והמחיקה של ה-Pod, למשל על ידי השבתת ההעברה הפעילה של ComputeClass.

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