מידע על 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 מותאם אישית, גם אם יש צמתים קיימים עם עדיפויות שונות.

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

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

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

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

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

kubectl describe crd computeclasses.cloud.google.com

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

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

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

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

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

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

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

  • בחירת מאגר צמתים: באשכולות GKE Standard, מציינים את השמות של מאגרי צמתים קיימים כדי לשייך אותם ל-ComputeClass. כש-Pod מפעיל פעולת הגדלה, ‏ GKE מנסה למקם את ה-Pod במאגרי הצמתים האלה. כללי עדיפות שבוחרים מאגרי צמתים לא תומכים בשדות אחרים. מידע נוסף זמין בקטע GKE Standard node pools and 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. אם מופעי N1 לא זמינים, GKE חוזר לסדרת המכונות המוגדרת כברירת מחדל עבור האשכול.

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

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

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

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

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

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

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

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

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

הגדרות של machineFamily

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

בקשה למשפחת מכונות רחבה יותר לא תספק סוגי מכונות Bare Metal. לדוגמה, בקשה של c3 או c4a לא תספק סוגי מכונות כמו c3-standard-192-metal או c4a-standard-72-metal בהתאמה. מכיוון שסוגי הצמתים של Bare Metal דורשים בקשה של סוג מכונה מדויק, אי אפשר להשתמש גם ב-ComputeClass המוגדר מראש של Autopilot‏ Performance. במקום זאת, צריך ליצור ComputeClass בהתאמה אישית ולציין את סוג המכונה המדויק בשדה machineType. כדי להשתמש בסוגי מכונות Bare Metal‏ c3 או c4a עם ComputeClasses, יצירה אוטומטית של מאגרי צמתים או מצב Autopilot, נדרשת גרסה GKE 1.35.3-gke.1389000 ואילך.

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

  • ‫spot: מכונות וירטואליות במודל Spot. ערך ברירת המחדל הוא false.
  • ‫minCores: מספר ה-vCPU המינימלי לכל צומת. ערך ברירת המחדל הוא 0. השדה הזה שימושי למניעת יצירה של צמתים קטנים מדי לצרכים שלכם.
  • ‫minMemoryGb: כמות הזיכרון המינימלית לכל צומת. ערך ברירת המחדל הוא 0.
  • ‫storage.bootDiskType: סוג דיסק האתחול. בקטרי Autopilot, נתמך רק הסוג 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: Persistent Disk שמשמשים לטעינה מראש של נתונים בצמתים של 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: פרטים ספציפיים על מיקום המודעה על ידי המערכת:
  • ‫enableNestedVirtualization: האם להפעיל וירטואליזציה מקוננת בצמתים. ערך ברירת המחדל הוא false.

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

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

הגדרות machineType

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

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

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

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

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

הגדרת GPU

כדי לבחור מעבדי GPU בכללי העדיפות, מציינים את הסוג, המספר ו-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.
  • ‫acceleratorNetworkProfile: פרופיל רשת המאיץ של ה-GPU, לדוגמה auto. נדרשת גרסה ‎1.35.2-gke.1842000 ואילך של 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: שימוש ב-VM במודל Spot. ברירת המחדל היא false.
  • ‫storage: הגדרת אחסון בצומת.
    • ‫storage.bootDiskType: סוג דיסק האתחול.
    • ‫storage.bootDiskKMSKey: הנתיב למפתח Cloud KMS שבו רוצים להשתמש להצפנת דיסק האתחול.
    • ‫storage.bootDiskSize: הגודל ב-GB של דיסק האתחול של הצומת.
  • ‫reservations: שימוש בהזמנה ב-Compute Engine. פרטים נוספים זמינים בקטע שימוש בהזמנות של Compute Engine.
  • location:
    • ‫zones: רשימה של Google Cloud אזורים שבהם GKE יכול להקצות צמתים. אם לא מציינים אזור, GKE מקצה צמתים באזורים שהוגדרו בהגדרות של הקצאת צמתים אוטומטית באשכול. אם לא מוגדרים אזורים להקצאת צמתים אוטומטית (NAP), GKE מקצה צמתים בכל אחד מהאזורים הרגילים שמישור הבקרה משתמש בהם.

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

    • ‫zoneTypes: רשימה של סוגי אזורים שמציינת קבוצה של Google Cloud אזורים שבהם 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 המותאם אישית הזה בעומס העבודה:

בנוסף, אתם יכולים לבצע את הפעולות הבאות לגבי עומסי עבודה (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: 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.
  • אם מעבדי A100 GPU לא זמינים באף אחד מהאזורים שצוינו, GKE לא יגדיל את מספר הצמתים במאגר הצמתים.

הגדרת רשת DRANET

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

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

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

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

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

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

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

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

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

  1. ‫GKE ממקם את ה-Pods בכל הצמתים הקיימים שמשויכים ל-ComputeClass הזה.
  2. אם הצמתים הקיימים לא יכולים להכיל את ה-Pods,‏ GKE יקצה צמתים חדשים שמשתמשים בסדרת המכונות N4, שהן מכונות וירטואליות מסוג 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 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 מחליטה אם להגדיל את מספר הצמתים ב-node pool קיים או ליצור node pool חדש על סמך גורמים כמו גודל האשכולות והדרישות של ה-Pod. לפודים עם ComputeClasses שלא מגדירים יצירה אוטומטית של מאגר צמתים, ממשיך להיות שינוי גודל רק של מאגרי צמתים קיימים.

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

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

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

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

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

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

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

    • באשכולות Autopilot, ‏ GKE ממקם את ה-Pod בצומת חדש או קיים, ללא קשר להגדרת המכונה של הצומת.
    • באשכולות Standard שלא משתמשים ביצירה אוטומטית של מאגר צמתים,‏ 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 מתזמנת את ה-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 יכולות להפחית את היעילות של העברה פעילה. בנוסף, יכול להיות שחלק מעומסי העבודה עם מצב (stateful) לא יאפשרו את השיבוש שנגרם כתוצאה מהעברה פעילה.
  • אם מעדכנים 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. כשמפנים את ה-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 ישתמש בהזמנות כשיוצר צמתים חדשים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

taintConfig:
  architectureTaintBehavior: NONE

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

‫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 מציין את Google Cloud חשבון השירות שבו נעשה שימוש בצמתים במאגרי צמתים שמנוהלים על ידי ComputeClass. בדוגמה הבאה אפשר לראות איך מציינים את serviceAccount ב-ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.

מידע נוסף זמין במאמר מידע על חשבונות שירות ב-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

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

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

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

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

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

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

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

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

נדרשת גרסה ‎1.36.2-gke.1498000 של GKE או גרסה מתקדמת יותר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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