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

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

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

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

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

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

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

כללי עדיפות

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

יש שני סוגים של כללי עדיפות:

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

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

כללי עדיפות הצהרתיים

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

הגדרות של machineFamily

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

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

  • ‫spot: מכונות וירטואליות במודל Spot. ערך ברירת המחדל הוא false.
  • ‫minCores: מספר ליבות ה-CPU הווירטואליות המינימלי לכל צומת. ערך ברירת המחדל הוא 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 ואילך.

אתם יכולים לציין שדות 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 יכול להקצות צמתים. Google Cloud אם לא מציינים אזור, GKE מקצה צמתים באזורים שהוגדרו בהקצאת צמתים אוטומטית (NAP) באשכול. אם לא מוגדרים אזורים להקצאת צמתים אוטומטית (NAP), GKE מקצה צמתים בכל אחד מהאזורים הרגילים שמישור הבקרה משתמש בהם.

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

בדוגמה הבאה מוצג כלל ל-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 המותאם אישית הזה בעומס העבודה:

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

טירגוט אזורי AI

אפשר גם להשתמש בסוג מחשוב כדי לציין אזורי AI עבור ה-Pods. אזורי AI הם מיקומים מיוחדים בתוך Google Cloud אזורים שעברו אופטימיזציה לעומסי עבודה של 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: 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 להקצאת צמתים עם מעבדי GPU מסוג A100 לעומס העבודה. לצמתים יש את ההעדפות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • ה-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 מנסה לתזמן את הפודים בהמתנה במאגרי הצמתים האלה. יכול להיות ש-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 מחליף צמתים שנמצאים בתחתית הרשימה priorities של ComputeClass בצמתים שנמצאים בחלק העליון של רשימת העדיפויות. האפשרות הזו עוזרת לוודא שרכיבי ה-Pod יפעלו בסופו של דבר בהגדרת הצומת המועדפת ביותר, גם אם במקור GKE נאלץ להפעיל את רכיבי ה-Pod האלה בהגדרת צומת פחות מועדפת.
  • ‫ensureAllDaemonSetPodsRunning: GKE מחליף צמתים עם פודים של DaemonSet שלא ניתן לתזמן בצמתים גדולים יותר שיכולים להריץ את כל הפודים הנדרשים של DaemonSet. האפשרות הזו עוזרת לוודא שכל ה-DaemonSets יפעלו בסופו של דבר בצמתים.

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

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

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

    בקרי Kubernetes, כמו Deployments או Jobs, יוצרים קבוצות Pod כדי להחליף קבוצות Pod שהוצאו. מערכת GKE מתזמנת את ה-Pods החדשים האלה בצומת החדש.

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

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

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

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

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

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

סוג ההעברה הפעיל optimizeRulePriority מאפשר ל-GKE להחליף צמתים קיימים שנמצאים במקום נמוך יותר ברשימת ComputeClass priorities בצמתים שנמצאים במקום גבוה יותר ברשימה. לדוגמה, במפרט ComputeClass הבא, הצמתים מסוג N4 מקבלים עדיפות על פני הצמתים מסוג C4:

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 מוחק את הצומת.

העברה פעילה להפעלת פודים של 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

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

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

כדי להשתמש בשמירת מקום ב-ComputeClasses בהתאמה אישית, צריך לעמוד בדרישות הבאות:

  • כדי ש-GKE ישתמש בהזמנות ליצירת צמתים חדשים, צריך להשתמש ביצירה אוטומטית של מאגר צמתים. מידע נוסף זמין בקטע יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses. אתם יכולים גם להמשיך להשתמש בהזמנות כשאתם יוצרים מאגרי צמתים באשכול באופן ידני.
  • אפשר להשתמש בהזמנות ללא 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 ואילך.
  • דחיות בעדיפות בגרסה ‎1.33.4-gke.1350000 של GKE ואילך.
  • תוויות וכתמים גלובליים של צמתים ב-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. Google Cloud בדוגמה הבאה אפשר לראות איך מציינים את serviceAccount ב-ComputeClass:

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

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

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

החל מגרסה 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.

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