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

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

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

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

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

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

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

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

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

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

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

ספקי Kubernetes בקוד פתוח וספקי Kubernetes מנוהלים כמו GKE משתמשים בסוגי ה-API הבאים של 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 מגדירה תבנית שרכיבי Pod יכולים להשתמש בה כדי ליצור באופן אוטומטי משאבי ResourceClaim חדשים לכל Pod. תבניות ResourceClaim שימושיות כשצריך לתת לכמה עומסי עבודה גישה להגדרות דומות של מכשירים, במיוחד כשמשתמשים בבקר עומסי עבודה כמו Deployments או StatefulSets.

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

מידע נוסף על סוגי DRA API זמין במאמר מינוח של DRA.

איך DRA עובד

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

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

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

  1. אדמינים של אשכולות מתקינים בצמתים מנהלי התקנים שתומכים ב-DRA.
  2. אדמינים של אשכולות יוצרים DeviceClasses שמסננים חומרה שעומדת בדרישות ספציפיות, כמו כל כרטיסי ה-GPU עם יותר מ-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 בצומת כדי לצרף את החומרה שהוקצתה ל-Pod כדי למלא את בקשת המשאבים שלו.

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

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

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

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

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

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

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

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

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

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

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

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

התאמה אוטומטית של DRA ושל התשתית לעומס

כדי לשנות באופן אוטומטי את מספר הצמתים במאגר צמתים במצב רגיל, משתמשים ב-Cluster Autoscaler. אפשר להפעיל את התכונה 'שינוי גודל אוטומטי של אשכולות' בכל מאגר צמתים שנוצר באופן ידני, כולל מאגרי צמתים שיש להם מנהלי התקנים של DRA.

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

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

הגורמים האלה יכולים להוביל לכך שתבחינו בהתנהגות שונה של הקטנת הקיבולת במאגרי צמתים של DRA בהשוואה למאגרי צמתים אחרים.

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

בטבלה הבאה מתוארים המכשירים שאפשר להקצות לעומסי עבודה באמצעות DRA ב-GKE:

טבלה 3. מכשירים נתמכים ל-DRA ב-GKE
מכשירים נתמכים ל-DRA
יחידות GPU כל סוג GPU שזמין במיקום שלכם. מידע נוסף זמין במאמר בנושא מיקומי GPU.
ממשקי רשת כמה סוגים של ממשקי רשת, כמו ממשקים עם יכולת RDMA, על ידי התקנת הדרייבר המנוהל DRANET. מידע נוסף זמין במאמר הקצאת משאבי רשת באמצעות DRANET מנוהל של GKE.

מגבלות

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

  • מצב הפעולה: DRA זמין רק באשכולות במצב רגיל.

  • סוג המאיץ: במהלך התצוגה המקדימה, DRA ב-GKE תומך רק ב-GPU.

  • GPUs:

  • ממשקי רשת (גרסת Preview): מידע נוסף זמין בקטע מגבלות במאמר בנושא הקצאת משאבי רשת באמצעות DRANET מנוהל ב-GKE.

  • התאמה אוטומטית לעומס:

    • במקרה של מנהלי התקנים של DRA מצד שלישי שאתם מתקינים, נדרש שמאגרי הצמתים יכללו לפחות צומת אחד כדי שהכלי לשינוי גודל האשכול יפעל. כדי למנוע מצביעים של צמתים שמשתמשים במנהלי התקנים של צד שלישי להתרחב לאפס צמתים, צריך להגדיר את המספר המינימלי של הצמתים ל-1 לפחות.
    • יכול להיות שהמידרוג האוטומטי של האשכול לא יפעל כמו שצריך עם מנהלי התקנים של DRA של צד שלישי. אם אתם משתמשים במנהלי התקנים של צד שלישי, ודאו שהם מפרסמים מידע רק על מכשירים שנמצאים באופן מקומי בצמתים ספציפיים.
    • ב-DaemonSets במאגרי צמתים עם התאמה אוטומטית לעומס שמשתמשים ב-ResourceClaim סטטי כדי לשתף גישה למכשיר בין Pods, ההתאמה האוטומטית לעומס תומכת בעד 128 DaemonSet Pods. כדי לעקוף את ההגבלה הזו, אפשר לבצע אחת מהפעולות הבאות:
    • אם הפודים שלכם מפנים ל-ResourceClaims ויש להם PriorityClass שמגדיר את מדיניות ההפסקה הזמנית ל-PreemptLowerPriority, יכול להיות שזמן הטעינה של התאמה אוטומטית לעומס יתארך. ‫PreemptLowerPriority היא מדיניות הקדימות שמוגדרת כברירת מחדל ל-PriorityClass, לכן צריך לוודא ששדה preemptionPolicy מוגדר במפורש ל-Never ב-PriorityClass. מידע נוסף מופיע במאמר בנושא PriorityClass שלא מאפשר קדימה.

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

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