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

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

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

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

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

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

התכונה Node pool auto-creation (יצירה אוטומטית של מאגר צמתים) נועדה לאפשר ל-GKE להקטין את מאגרי הצמתים הריקים ולהסיר אותם מהאשכול באופן אוטומטי. אי אפשר להגדיר מספר מינימלי של צמתים שכל מאגר צמתים שנוצר אוטומטית חייב לכלול, כי מספר מינימלי שגדול מאפס ימנע את ההסרה של מאגרי צמתים ריקים. אם בתרחיש השימוש שלכם נדרש מספר מינימלי של צמתים שיפעלו תמיד באשכול, צריך ליצור מאגר צמתים באופן ידני עם התאמה אוטומטית לעומס.

איך זה עובד

התכונה Node pool auto-creation (יצירה אוטומטית של מאגר צמתים) מרחיבה את האפשרויות של התאמה אוטומטית לעומס באשכול GKE, ומאפשרת ל-GKE להקצות מאגרי צמתים חדשים שעומדים בדרישות החומרה ובבקשות המשאבים של Pods בהמתנה. אפשר להגדיר את דרישות החומרה בדרכים הבאות:

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

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

  • בקשות למשאבים של מעבד, זיכרון ואחסון זמני ב-Pods ובקונטיינרים, כולל Pods שמנוהלים על ידי DaemonSets.
  • בקשות ל-GPU ול-TPU במפרטים של Pod או ב-ComputeClasses.
  • דרישות חומרה, כמו סוגי מכונות או סוגי דיסקים לאתחול, במפרטים של Pods בהמתנה או ב-ComputeClasses.
  • Tolerations במפרטים של Pods בהמתנה שיש להם בוררי צמתים תואמים.

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

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

‫GKE גם מגדיר מטא-נתונים של צמתים (כמו תוויות, הערות ו-node taints) על סמך דרישות עומס העבודה, כמו בדוגמאות הבאות:

  • אם מבקשים את סדרת מכונות N2, ‏ GKE מוסיף את תווית הצומת cloud.google.com/machine-family: n2 לכל אחד מהצמתים.
  • אם בוחרים ComputeClass ב-Pod, ‏ GKE מוסיף תווית של צומת עם המפתח cloud.google.com/compute-class שמוגדר לשם של אותו ComputeClass.
  • אם ל-Pod יש toleration וגם בורר צמתים לאותה תווית צומת, מערכת GKE מוסיפה taints של צמתים ל-toleration האלה לצמתים שנוצרו אוטומטית.

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

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

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

העדפות לגבי שינוי גודל ב-GKE

ההעדפות הבאות חלות כשמפעילים התאמה אוטומטית לעומס (autoscaling) בתשתית שלכם ב-GKE:

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

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

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

אתם יכולים לשלוט באופן ידני בגודל המינימלי של המופעים ש-GKE משתמש בהם עבור מאגרי הצמתים שנוצרו אוטומטית, באמצעות ComputeClass שיש לו priorities.machineFamily שדה וגם שדה priorities.minCores או שדה priorities.minMemoryGb.

שיטות להפעלת יצירה אוטומטית של מאגר צמתים

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

שיטות הפעלה
ברמת עומס העבודה (מומלץ)

ב-GKE מגרסה 1.33.3-gke.1136000 ואילך, אפשר להשתמש ב-ComputeClasses כדי להפעיל יצירה אוטומטית של מאגר צמתים בלי להשתמש בהקצאת צמתים אוטומטית (NAP) ברמת האשכול. ‫GKE יוצר מאגרי צמתים חדשים רק לעומסי עבודה שבהם נבחרו ComputeClasses ספציפיים שהופעלה בהם יצירה אוטומטית. עומסי עבודה קיימים באשכול לא יושפעו.

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

ברמת האשכול

הפעלת הקצאת צמתים אוטומטית (NAP) לכל האשכול. צריך להגדיר מגבלות למשאבים כמו מעבד (CPU) וזיכרון באשכול. המגבלות האלה חלות על כל האשכול. ההגדרה ברמת האשכול נדרשת כדי להפעיל יצירה אוטומטית של מאגר צמתים בגרסאות GKE קודמות ל-1.33.3-gke.1136000.

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

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

  1. מפרט ComputeClass או Pod: אם מציינים הגדרה (למשל סוג מכונה) ב-ComputeClass או במפרט Pod,‏ GKE משתמש בהגדרה הזו.
  2. ברירת מחדל של הקצאת משאבים אוטומטית של צמתים ברמת האשכול: אם הגדרה לא מצוינת ב-ComputeClass או במפרט של Pod, ‏ GKE בודק אם הגדרתם ערך ברירת מחדל להקצאת משאבים אוטומטית של צמתים באשכול. אם קיים ערך ברירת מחדל ברמת האשכול, GKE משתמש בערך הזה.
  3. ברירת מחדל ברמת האשכול: אם הגדרה לא מצוינת ב-ComputeClasses, במפרטים של Pod או כערך ברירת מחדל להקצאה אוטומטית של צמתים ברמת האשכול, GKE משתמש בערך ברירת המחדל שמוגדר לאשכול ב-Google Cloud.

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

  1. ‫GKE בודק אם במפרט של ה-Pod או ב-ComputeClass של ה-Pod מצוין סוג מכונה.
  2. אם לא מצוין סוג מכונה במפרט של ה-Pod או ב-ComputeClass,‏ GKE בודק אם הגדרתם סוג מכונה שמוגדר כברירת מחדל להקצאה אוטומטית של צמתים באשכול.
  3. אם לא הגדרתם סוג מכונה שמוגדר כברירת מחדל להקצאת צמתים אוטומטית (NAP), מערכת GKE משתמשת בסוג המכונה שמוגדר כברירת מחדל של האשכול.

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

הפעלה ברמת עומס העבודה באמצעות ComputeClasses

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

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

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

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

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: example-computeclass
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  whenUnsatisfiable: ScaleUpAnyway
  nodePoolAutoCreation:
    enabled: true

הפעלה ברמת האשכול באמצעות הקצאת צמתים אוטומטית (NAP)

כדי להפעיל יצירה אוטומטית של מאגר צמתים באשכול כולו, מפעילים את התכונה node auto-provisioning באשכול באמצעות Google Kubernetes Engine API. הקצאה אוטומטית של צמתים מאפשרת ל-GKE ליצור מאגרי צמתים חדשים לפי הצורך לכל עומס עבודה באשכול, על סמך מפרטי Pod או הגדרות ComputeClass. ‫GKE לא מנהל מאגרי צמתים קיימים באשכול, אבל אפשר לסמן מאגרי צמתים בודדים כמאגרי צמתים שהוקצו אוטומטית אחרי שמפעילים הקצאת צמתים אוטומטית (NAP) באשכול.

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

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

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

  • רוצים להגדיר ערכי ברירת מחדל של הגדרות צומת לכל האשכול.

אחרי שמפעילים הקצאת צמתים אוטומטית (NAP), אפשר להגדיר ערכי ברירת מחדל להגדרות שונות של צמתים באמצעות Google Cloud CLI או קובץ תצורת YAML.

הגבלות על משאבים ברמת האשכול באמצעות הקצאת צמתים אוטומטית (NAP)

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

הגבלות המשאבים ברמת האשכול נדרשות רק אם מפעילים הקצאת צמתים אוטומטית (NAP) באשכול. באשכולות שמשתמשים ב-GKE מגרסה 1.33.3-gke.1136000 ואילך, אפשר להשתמש ביצירה אוטומטית של מאגר צמתים ב-ComputeClasses בלי להפעיל הקצאה אוטומטית של צמתים.

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

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

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

  • הגדרות ברירת מחדל ברמת עומס העבודה: אפשר להשתמש בשדה spec.nodePoolConfig ובשדה spec.priorityDefaults במפרט ComputeClass כדי להגדיר ערכי ברירת מחדל להגדרות ספציפיות של צמתים. ערכי ברירת המחדל האלה חלים רק על מאגרי הצמתים ש-GKE יוצר עבור ComputeClass.
  • הגדרות ברירת מחדל ברמת האשכול: אתם יכולים להגדיר ערכי ברירת מחדל למאגרי צמתים שנוצרו אוטומטית כשאתם מגדירים הקצאת משאבים אוטומטית של צמתים. כדי לציין ערכי ברירת מחדל, משתמשים ב-CLI של gcloud או בקובץ תצורה בפורמט YAML.

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

הגדרות ברירת מחדל ברמת האשכול באמצעות קובץ הגדרה

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

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

    management:
      autoRepair: true
      autoUpgrade: true
    
  • בקובץ התצורה לדוגמה הבא מוגדרות מגבלות המשאבים ברמת האשכול להקצאת צמתים אוטומטית, ומוגדרות כמה הגדרות ברירת מחדל:

    resourceLimits:
      - resourceType: 'cpu'
        minimum: 4
        maximum: 10
      - resourceType: 'memory'
        maximum: 64
      - resourceType: 'nvidia-tesla-t4'
        maximum: 4
    management:
      autoRepair: true
      autoUpgrade: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true
    diskSizeGb: 100
    

    קובץ תצורה זה מגדיר את ערכי ברירת המחדל הבאים:

אחרי שמחילים את קובץ התצורה על האשכול, GKE משתמש בהגדרות שבקובץ רק עבור מאגרי צמתים חדשים שנוצרו אוטומטית באשכול. ההגדרות החדשות או ששונו שציינתם בקובץ לא חלות על מאגרי צמתים קיימים שנוצרו על ידי GKE באשכול. אם מעדכנים ערך שהוגדר קודם לאשכול, GKE משתמש בערך החדש לכל מאגרי הצמתים החדשים. לדוגמה, אם הגדרתם בעבר את סדרת המכונות של ברירת המחדל ל-N2, ואתם מעדכנים את הערך ל-N4 בקובץ התצורה, כל מאגרי הצמתים החדשים ישתמשו בסוגי מכונות N4.

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

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

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

בחירה של סדרת מכונות או סוג מכונה

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

  • ComputeClasses: שימוש ב-machineFamily או בmachineType כללי עדיפות.
  • מפרטי Pod: בסדרת מכונות, משתמשים בבורר צמתים לתווית הצומת cloud.google.com/machine-family. כדי להגדיר סוג מכונה, צריך להשתמש בתוויות הצמתים cloud.google.com/machine-family ו-node.kubernetes.io/instance-type. מידע נוסף זמין במאמר בנושא בחירת סדרת מכונות או סוג מכונה.

אם לא בוחרים מכונה באופן מפורש, GKE משתמש בסדרת מכונות E2 או בסוג מכונה שתואם לחומרה שעומס העבודה דורש. לדוגמה, ב-GKE נעשה שימוש בסוגי מכונות GPU עבור מעבדי GPU ובמכונות ייעודיות עבור משאבי TPU.

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

סדרות מכונות נתמכות

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

סדרות מכונות אחרות נתמכות בכל הגרסאות של GKE.

בחירת GPU

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

  • ComputeClasses:
    1. משתמשים בכלל העדיפות gpu כדי להגדיר את מעבדי ה-GPU.
    2. בקשת משאבי GPU בקבוצות ה-Pod.
  • מפרטים של מכשירי Pod:
    1. הגדרת מגבלות GPU ברמת האשכול עבור הקצאת צמתים אוטומטית (NAP).
    2. משתמשים בבוררי צמתים כדי להגדיר את כרטיסי ה-GPU.
    3. בקשת משאבי GPU בקבוצות ה-Pod.

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

דרישות לגבי גרסת GKE ל-GPU

בחירת Cloud TPU

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

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

גם מאגרי צמתים של פרוסות TPU במארח יחיד וגם מאגרי צמתים של פרוסות TPU במארחים מרובים תומכים בהתאמה אוטומטית של נפח האחסון (autoscaling) וביצירה אוטומטית של מאגרי צמתים. כדי ליצור מאגר צמתים באופן אוטומטי,‏ GKE יוצר מאגרי צמתים של פרוסות TPU עם מארח יחיד או עם כמה מארחים, עם גרסת TPU וטופולוגיה שעומדות בדרישות של עומסי עבודה בהמתנה.

דרישות לגבי גרסת GKE לשימוש ב-Cloud TPU

יצירה אוטומטית של מאגר צמתים תומכת ב-Cloud TPU רק בגרסאות ספציפיות של GKE:

  • TPU v3: גרסה 1.31.0 ואילך.
  • TPU v5 ו-TPU v4: גרסה 1.29.0 ואילך.
  • TPU Trillium: גרסה 1.32.0 ואילך.
  • Ironwood (TPU7x) (גרסת Preview): גרסה 1.34.1-gke.2541000 ואילך.

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

שינוי אוטומטי של גודל מאגר הצמתים ב-Cloud TPU

מערכת GKE משנה את הגודל של מאגרי צמתים של Cloud TPU שנוצרו באופן אוטומטי או באופן ידני, שמשתמשים ב-Cluster Autoscaler, באחת מהדרכים הבאות:

  • מאגר צמתים של פרוסת TPU עם מארח יחיד: מערכת GKE מוסיפה או מסירה צמתי TPU במאגר הצמתים הקיים. מאגר הצמתים יכול להכיל כל מספר של צמתי TPU בין אפס לבין הגודל המקסימלי של מאגר הצמתים, כפי שנקבע על ידי הדגלים של התאמה אוטומטית לעומס --max-nodes ו---total-max-nodes. לכל צמתי ה-TPU במאגר הצמתים יש את אותו סוג מכונה ואותה טופולוגיה. מידע נוסף על יצירת מאגר צמתים של פרוסת TPU במארח יחיד זמין במאמר יצירת מאגר צמתים של פרוסת TPU במארח יחיד.
  • מאגר צמתים של פרוסת TPU עם כמה מארחים: מערכת GKE מגדילה את מאגר הצמתים באופן אטומי מאפס למספר הצמתים שנדרש כדי לעמוד בדרישות הטופולוגיה של ה-TPU. לדוגמה, אם יש מאגר צמתים של TPU עם ct5lp-hightpu-4t סוג מכונה וטופולוגיה של 16x16, במאגר הצמתים תמיד יהיו 64 צמתים או אפס צמתים. מערכת GKE מצמצמת את מאגר הצמתים אם אין בו עומסי עבודה של TPU. כדי להקטין את מאגר הצמתים, GKE מוציא את כל ה-Pods המתוזמנים ומסיר את כל הצמתים במאגר הצמתים. מידע נוסף על יצירת מאגר צמתים של TPU slice עם כמה מארחים זמין במאמר יצירת מאגר צמתים של TPU slice עם כמה מארחים.

הגדרת מאגר צמתים של Cloud TPU

‫GKE משתמש בהגדרה ב-Pod או ב-ComputeClass כדי לקבוע את ההגדרה של צמתי ה-TPU. המניפסט הבא הוא דוגמה למפרט פריסה שמבקש TPU במפרט ה-Pod. אם ההגדרה של הקצאת צמתים אוטומטית ברמת האשכול מופעלת, פריסת ה-Deployment הזו מפעילה יצירה אוטומטית של מאגר צמתים. כשיוצרים את פריסת הדוגמה הזו, GKE יוצר מאגר צמתים שמכיל פרוסת TPU v4 עם טופולוגיה של 2x2x2 ושתי מכונות ct4p-hightpu-4t.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 2
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

במניפסט הזה, השדות הבאים מגדירים את תצורת ה-TPU:

  • cloud.google.com/gke-tpu-accelerator: הגרסה והסוג של TPU. לדוגמה, משתמשים ב-tpu7x-standard-4t עבור Ironwood (TPU7x).
  • cloud.google.com/gke-tpu-topology: הטופולוגיה עם המספר והסידור הפיזי של שבבי ה-TPU בתוך פרוסת TPU. לדוגמה, משתמשים ב-2x2x2.
  • limits.google.com/tpu: מספר שבבי ה-TPU לכל מכונה וירטואלית. לדוגמה, אם משתמשים ב-tpu7x-standard-4t, מספר שבבי ה-TPU לכל מכונה וירטואלית הוא 4.

בחירת VM במודל Spot

אפשר לבחור באפשרות Spot VMs (מכונות וירטואליות מסוג Spot) עבור מאגרי צמתים שנוצרו אוטומטית באחת מהדרכים הבאות:

  • ComputeClasses: משתמשים בשדה spot בכלל עדיפות.
  • מפרטי ה-Pod: יש להשתמש בטולרנטיות עבור תווית הצומת cloud.google.com/gke-spot="true" עם האפקט NoSchedule. מוסיפים בורר צמתים לתוויות הצמתים cloud.google.com/gke-spot=true או cloud.google.com/gke-provisioning=spot. לחלופין, אפשר לבחור VM זמני באמצעות תווית הצומת cloud.google.com/gke-preemptible ב-toleration וב-node selector. עם זאת, אנחנו ממליצים מאוד להשתמש במכונות וירטואליות מסוג Spot במקום זאת.

הגדרת שטח אחסון זמני

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

  • ComputeClasses: משתמשים בשדות storage.bootDiskSize וב-storage.bootDiskType בכלל עדיפות. אתם יכולים להגדיר הגדרות שונות של דיסק האתחול עבור ComputeClass שונים.
  • מפרטי ה-Pod: משתמשים בשדות diskSizeGb ו-diskType בקובץ התצורה ברמת האשכול. אי אפשר לקבוע את הגודל והסוג של דיסק האתחול של כל Pod בנפרד באמצעות השיטה הזו.

מידע נוסף זמין במאמר בנושא דיסקים מותאמים אישית להפעלה. אם לא משנים במפורש את ההגדרות של דיסק האתחול, ברירת המחדל היא נפח pd-balanced בקיבולת של 100 GiB.

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

הפרדת עומסי עבודה

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

  • ComputeClasses: הצמתים ש-GKE יוצר עבור ComputeClass ספציפי יכולים להריץ רק Pods שבוחרים את ה-ComputeClass הזה. אין צורך לשנות את מפרטי ה-Pod. אפשר להפריד בין ה-Pods ב-ComputeClass באמצעות זיקה בין Pods ודחייה בין Pods.
  • מפרטים של Pod: אם מפעילים הקצאת צמתים אוטומטית (NAP) באשכול, אפשר להגדיר הפרדה של עומסי עבודה באמצעות שדות במפרט של ה-Pod. במהלך יצירה אוטומטית של מאגר צמתים, יכול להיות ש-GKE ייצור מאגרי צמתים עם תוויות וכתמים אם כל התנאים הבאים מתקיימים:
    • ה-Pod משתמש בבורר צמתים כדי לבקש מַפתח התווית וערך של תווית צומת בהתאמה אישית. אי אפשר להשתמש בתוויות של צמתי מערכת להפרדה של עומסי עבודה.
    • ל-Pod יש toleration לאותו מפתח התווית של הצומת.
    • האפקט של ההגדרה הוא NoSchedule,‏ NoExecute או לא צוין.

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

מגבלות

  • כל ההגבלות של המידרוג האוטומטי של אשכולות חלות גם על יצירה אוטומטית של מאגר צמתים.
  • יכול להיות שבאשכולות עם יותר מ-200 מאגרי צמתים סך הכול, זמן האחזור יגדל במהלך התאמה אוטומטית לעומס. כל הגדרה שמפעילה יצירה של מאגר צמתים חדש, כמו הפרדה של עומסי עבודה או שימוש בכמה ComputeClasses, מגדילה את המספר הזה. מידע נוסף על מגבלות של אשכולות זמין במאמר מגבלות ושיטות מומלצות בקטע 'תכנון אשכולות גדולים'.
  • כל מגבלות המשאבים שאתם מגדירים לאשכול כשאתם מפעילים הקצאה אוטומטית של צמתים חלות גם על מאגרי הצמתים ש-GKE יוצר עבור ComputeClasses.
  • ההגדרות הבאות לא נתמכות על ידי ComputeClasses:
    • שדרוגים בהדרגה (rolling) או שדרוגים כחול-ירוק (blue-green).
    • תקינות הצומת והפעלה מאובטחת.
  • כדי להפעיל יצירה אוטומטית של מאגר צמתים עבור ComputeClass בגרסאות GKE קודמות ל-1.33.3-gke.1136000, צריך גם להפעיל הקצאת צמתים אוטומטית (NAP) ברמת האשכול. המגבלה הזו לא חלה בגרסה ‎1.33.3-gke.1136000 של GKE ואילך.

הגדרות שלא נתמכות

‫GKE לא יוצר מאגרי צמתים חדשים שמשתמשים בהגדרות הבאות:

הכלי Cluster Autoscaler יכול לשנות את גודל הצמתים במאגרי צמתים קיימים שמשתמשים בהגדרות האלה.

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