DRA اومد، ولی HAMi هنوز سرجاشه
خلاصهٔ کاملتر
HAMi که تیر امسال پروژهٔ incubating بنیاد CNCF شد، برای کاری ساخته شده بود که رابط device plugin کوبرنتیز بلد نبود: تقسیم یه کارت گرافیک بین چند پاد. اون رابط فقط میتونست دستگاه بشمره، یعنی یه کارت کامل، بگیر یا بیخیال شو. نویسنده، که خودش از مشارکتکنندههای HAMiه، توضیح میده که کاربر این پروژه بهجاش سه تا extended resource مینویسه:
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/gpumem: 8000
nvidia.com/gpucores: 10به گفتهٔ نویسنده هیچکدوم اینا برای زمانبند پیشفرض معنایی نداره، برای همین HAMi مجبور بود پاد رو از یه mutating webhook رد کنه تا اکستندر خودش کارت رو انتخاب کنه و تصمیم رو تو یه انوتیشن بنویسه. DRA همین وصلهکاری رو تموم میکنه: درایور ResourceSlice منتشر میکنه، ادمین DeviceClass میسازه و کاربر ResourceClaim مینویسه، پس تخصیص یه آبجکت واقعی APIه که kubectl میخونتش. با consumable capacity هم هر claim سهم مشخصی از حافظهٔ کارت رو میگیره.
ولی نویسنده تأکید میکنه که زمانبندی فقط نصف ماجراست. DRA یه دفتردار قوله و تضمین میکنه زمانبند بیشتر از ظرفیت کارت قول نده، ولی کاری به کانتینری نداره که سر اجرا قولش رو زیر پا میذاره — و با GPU همینجا درد میگیره. اعمال واقعی محدودیت کار HAMi-coreه؛ یه کتابخانهٔ C به اسم libvgpu.so که تو کانتینر preload میشه و فراخوانیهای CUDA و NVML رو میگیره. سقفش هم صادقانه گفته شده: هر workloadای که این preload رو دور بزنه ازش فرار میکنه.
نکات کلیدی:
- DRA تو کوبرنتیز v1.34 به GA رسید و از v1.35 پیشفرض روشنه؛ consumable capacity از v1.36 بتاست
- پروژهٔ HAMi-DRA یه وبهوک ادمیشنه که منیفستهای قدیمی رو خودکار به ResourceClaim تبدیل میکنه، پس چیزی لازم نیست بازنویسی بشه
- چون HAMi دیگه زمانبند خودش رو تزریق نمیکنه، با Volcano و هر زمانبند دیگهای که DRA رو میفهمه بدون پچ کار میکنه
- در عوض HAMi-DRA دید توپولوژی نداره، پس برای workloadهایی که پهنای باند NVLink براشون مهمه انتخاب خوبی نیست
- حالت DRA و حالت device plugin نباید همزمان تو یه کلاستر اجرا بشن، چون هر دو فکر میکنن صاحب همون حافظهان
- برای ناوگان چندفروشندهای یا کلاستر مدیریتشدهای که به feature gate دسترسی نداره، همون حالت سنتی انتخاب درسته
