מידע על הקצאת משאבים דינמית ב-GKE

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

הדף הזה מיועד לתפקידים הבאים:

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

מבוא ל-DRA

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

לדוגמה, אדמין של פלטפורמה יכול להגדיר סוג מכשיר שיש בו רק כרטיסי GPU מסוג NVIDIA A100. מפעילים של אפליקציות יכולים לסנן את המכשירים בקטגוריית המכשירים הזו על סמך דרישות עומס העבודה, למשל סינון של זיכרון GPU בנפח 80GB לפחות. כשאופרטור האפליקציה פורס עומס עבודה שמבקש את ההגדרה המסוננת, GKE מציב את ה-Pods בצמתים שעומדים בקריטריונים שנבחרו. בדוגמה הזו, מערכת GKE מוצאת צמתים עם מעבדי GPU מסוג A100 (80 GB) שזמינים. מפעיל האפליקציה לא צריך לבחור צמתים ספציפיים או הגדרות מכשיר במניפסט של עומס העבודה.

היתרונות של DRA

בלי DRA, הקצאת מכשירי חומרה ב-Kubernetes מסתמכת על תוספים למכשירים. כדי לצרף משאבי חומרה ל-Pods באמצעות תוספים למכשירים, משתמשים בתוויות של צמתים כדי למקם את ה-Pods בצמתים ספציפיים. בנוסף, כדי להקצות את כל המשאבים של צומת מסוים ל-Pod יחיד, צריך לבקש את המספר המדויק של המכשירים שמחוברים לצמתים.

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

  • הקצאת מכשירים הצהרתית: אדמינים של הפלטפורמה יכולים להגדיר תצורות של מכשירים לסוגים ספציפיים של עומסי עבודה או צוותים.
  • מורכבות מופחתת בין צוותים: כשמנהלי פלטפורמה מקצים צמתים עם הגדרות חומרה מיוחדות, מפעילים של אפליקציות לא צריכים לדעת אילו צמתים כוללים הגדרות ספציפיות. אדמינים של פלטפורמות לא צריכים להוסיף תוויות לצמתים או להעביר למפעילים מידע על צמתים ומכשירים ספציפיים.
  • מורכבות מופחתת למפתחים: מערכת Kubernetes מתזמנת את ה-Pods על סמך הגדרת המכשיר שאליה יש הפניה. מפעילים של אפליקציות לא צריכים לבחור צמתים ספציפיים בעומסי העבודה שלהם, ולא צריכים לוודא שכל Pod מבקש בדיוק את מספר המכשירים שמחוברים לצמתים האלה.
  • ניהול ריכוזי של התשתית: אדמינים של הפלטפורמה יכולים להגדיר באופן מרכזי תצורות חומרה שעונות על דרישות עסקיות ספציפיות. לדוגמה, אדמין של פלטפורמה יכול להצהיר על הגדרה של ביצועים גבוהים עם כרטיסי GPU מסוג H100, לצד הגדרה קטנה של הסקה עם כרטיסי GPU מסוג Tesla T4.
  • בחירת חומרה גמישה: DRA מאפשרת להשתמש בביטויי CEL כדי לסנן מכשירים עם מאפיינים ספציפיים. השימוש בביטויים מאפשר גמישות בסינון מכשירים שמתאימים לעומסי עבודה ספציפיים.

מתי כדאי להשתמש ב-DRA

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

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

הסברים על המונחים

ב-Kubernetes בקוד פתוח ובספקי Kubernetes מנוהלים כמו GKE נעשה שימוש במונחים הבאים של DRA:

ResourceSlice
ב-ResourceSlice מפורטים מכשיר חומרה אחד או יותר באשכול שהצמתים יכולים לגשת אליהם. לדוגמה, בצומת שיש לו גישה ל-GPU יחיד, ה-ResourceSlice מפרט את ה-GPU ואת שם הצומת. מנהלי ההתקנים של DRA בכל צומת יוצרים ResourceSlices. מתזמן Kubernetes משתמש ב-ResourceSlices כדי להחליט אילו מכשירים להקצות כדי לענות על בקשות לעומס עבודה.
DeviceClass
‫
DeviceClass מגדיר קטגוריה של מכשירים, כמו GPUs, שאפשר לבקש עבור עומסי עבודה. חלק ממנהלי ההתקנים (דרייברים) של המכשירים מספקים DeviceClasses מובנים, כמו gpu.nvidia.com DeviceClass עבור GPUs של NVIDIA. אדמינים של הפלטפורמה יכולים גם ליצור DeviceClasses בהתאמה אישית שמגדירים תצורות ספציפיות של מכשירים.
ResourceClaim

ה-ResourceClaim מאפשר ל-Pod או למשתמש לבקש משאבי חומרה על ידי סינון פרמטרים מסוימים בתוך DeviceClass. כשעומס עבודה מפנה ל-ResourceClaim, ‏ Kubernetes מקצה ל-ResourceClaim הזה מכשירים שתואמים לפרמטרים שצוינו.

לדוגמה, נניח שאתם יוצרים ResourceClaim ל-GPU אחד מסוג A100 (40 GB) ואז פורסים עומס עבודה שבוחר ב-ResourceClaim הזה. ‫Kubernetes מקצה GPU מסוג A100 (40 GB) שזמין ל-ResourceClaim ומתזמן את ה-Pod שלכם בצומת שיש לו גישה ל-GPU הזה.

ResourceClaimTemplate

‫ResourceClaimTemplate מגדיר תבנית ש-Pods יכולים להשתמש בה כדי ליצור באופן אוטומטי ResourceClaims חדשים לכל Pod. תבניות ResourceClaim שימושיות כשרוצים לתת לכמה עומסי עבודה גישה להגדרות דומות של מכשירים, במיוחד כשמשתמשים בבקר עומסי עבודה כמו Deployments או StatefulSets.

מפעילים של אפליקציות פורסים ResourceClaimTemplates ואז מפנים לתבניות בעומסי עבודה. ‫Kubernetes יוצרת ResourceClaims לכל Pod על סמך התבנית שצוינה, מקצה מכשירים ומתזמנת את ה-Pods. כשמפסיקים את הפודים, Kubernetes מנקה את ה-ResourceClaims התואמים.

איך DRA עובד

השימוש ב-DRA באשכולות ובעומסי העבודה דומה לשימוש ב-StorageClasses, ב-PersistentVolumeClaims וב-PersistentVolumes כדי להקצות נפחי אחסון באופן דינמי לפודים.

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

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

  1. אדמינים של אשכולות מתקינים מנהלי התקנים שתומכים ב-DRA בצמתים.
  2. אדמינים של אשכולות יוצרים DeviceClasses שמסננים חומרה שעומדת בדרישות ספציפיות, כמו כל המעבדים הגרפיים עם יותר מ-40 GB של זיכרון. חלק מהמכשירים עשויים לכלול גם DeviceClasses מובנים.
  3. מפעילים של אפליקציות יוצרים ResourceClaimTemplates או ResourceClaims שמבקשים הגדרות של מכשירים. תרחיש השימוש העיקרי לכל סוג של תלונה הוא כדלקמן:
    • האובייקט ResourceClaim מאפשר לכמה פודים לשתף גישה לאותו מכשיר.
    • תבנית ResourceClaim מאפשרת לכמה פודים לגשת למכשירים נפרדים דומים על ידי יצירת ResourceClaim לכל פוד באופן אוטומטי.
  4. אופרטורים של אפליקציות מוסיפים את ResourceClaimTemplates או ResourceClaims למניפסטים של עומסי העבודה שלהם.
  5. מפעילים של אפליקציות פורסים את עומס העבודה.

כשפורסים עומס עבודה שמפנה אל ResourceClaimTemplate או אל ResourceClaim, ‏ Kubernetes מבצע את שלבי התזמון הבאים:

  1. אם עומס העבודה מפנה אל ResourceClaimTemplate, ‏ Kubernetes יוצר אובייקט ResourceClaim חדש לכל מופע של עומס העבודה (לדוגמה, כל רפליקה בפריסת Deployment).
  2. מתזמן Kubernetes משתמש ב-ResourceSlices באשכול כדי להקצות מכשירים זמינים שעומדים בדרישות לכל ResourceClaim של Pod.
  3. מתזמן הפעולות ממקם כל Pod בצומת שיש לו גישה למכשירים שהוקצו ל-ResourceClaim של ה-Pod.
  4. ה-kubelet בצומת היעד קורא ל-DRA driver בצומת כדי לצרף את החומרה שהוקצתה ל-Pod, וכך לעמוד בדרישה למשאבים.

מתי כדאי להשתמש ב-ResourceClaims וב-ResourceClaimTemplates

גם ResourceClaims וגם ResourceClaimTemplates מאפשרים לציין ל-Kubernetes שאתם רוצים מכשירים שעומדים בדרישות ספציפיות. כשמפנים אל ResourceClaim ב-Pod, ‏ Kubernetes מקצה מכשירים למשאב ה-API המתאים ResourceClaim בשרת ה-API של Kubernetes. ההקצאה הזו מתבצעת גם אם יצרתם את ResourceClaim וגם אם Kubernetes יצר את ResourceClaim מ-ResourceClaimTemplate.

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

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

בטבלה הבאה מפורטים כמה הבדלים בין יצירה ידנית של ResourceClaims לבין יצירה של ResourceClaims על ידי Kubernetes מתוך ResourceClaimTemplate:

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

השוואה בין הקצאת מכשירים דינמית (DRA) לבין הקצאת מכשירים ידנית

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

  1. אדמין של אשכול יוצר צמתים עם מכשירים מצורפים, כמו יחידות GPU.
  2. האדמין של האשכול מעביר למפעילים של עומסי עבודה מידע על צמתים ספציפיים ועל המכשירים שמחוברים אליהם.
  3. מפעיל של עומס עבודה מבקש מכשירים במניפסט של עומס העבודה באופן הבא:
    • בוחרים צומת עם הגדרת המכשיר הנדרשת, כמו דגם ה-GPU או סוג ה-TPU והטופולוגיה, באמצעות שדה nodeSelector.
    • כדי לציין את המספר המדויק של המכשירים שהקונטיינרים צריכים להשתמש בהם, צריך להשתמש בשדה resources במפרט של ה-Pod.

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

בטבלה הבאה מוצגת השוואה בין DRA לבין תוספים למכשירים:

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

מכשירי GKE נתמכים ל-DRA

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

המגבלות של DRA ב-GKE

יש כמה מגבלות ל-DRA באשכולות GKE:

  • אי אפשר להשתמש ב-DRA עם הקצאת משאבים אוטומטית של צמתים.
  • אי אפשר להשתמש ב-DRA עם התכונות הבאות של שיתוף GPU:
    • יחידות GPU עם שיתוף זמן.
    • יחידות GPU עם כמה מופעים במקביל.
    • Multi-Process Service (MPS).
  • אי אפשר להשתמש ב-DRA באשכולות Autopilot.
  • צריך להשתמש ב-GKE מגרסה 1.34 ואילך.

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

שיפור הזמינות של הצמתים במהלך שינוי הגודל

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

לדוגמה, כדי שעומס עבודה יפעל בצורה אופטימלית, יכול להיות שיהיה צורך בשני מעבדי GPU מסוג NVIDIA L4 או במעבד GPU אחד מסוג NVIDIA A100 (40GB). אפשר ליצור ComputeClass שנותן עדיפות ליצירת צמתים עם GPU אחד מסוג A100 ‏ (40GB), אבל יכול לחזור ליצירת צמתים עם שני GPU מסוג L4 לכל צומת. לאחר מכן תוכלו להשתמש ב-DRA כדי לבקש GPU זמין לעומס העבודה. כשפורסים את עומס העבודה ובוחרים את ComputeClass, ‏ GKE יוצר צמתים עם אחת מההגדרות שצוינו של GPU. בעזרת DRA,‏ GKE יכול למקם את עומס העבודה בצומת הזמין הראשון, בלי קשר למודל ה-GPU, לתווית הצומת או למספר ה-GPU.

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

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