Dynamic Resource Allocation (DRA) به‌طرز بنیادی نحوه مدیریت شتاب‌دهنده‌های سخت‌افزاری و منابع تخصصی در Kubernetes را تغییر داده است. در نسخه v1.36، DRA باز هم بالغ‌تر شده و ترکیبی از graduations ویژگی‌ها، بهبود‌های مهم در استفاده‌پذیری و قابلیت‌های جدید را ارائه می‌دهد که دامنه کاربرد DRA را به منابع بومی مثل memory و CPU گسترش می‌دهد و همچنین پشتیبانی از ResourceClaims در PodGroups را فراهم می‌کند. دسترسی به درایورها هم در حال رشد است و فراتر از شتاب‌دهنده‌های محاسباتی، حالا networking و انواع سخت‌افزار دیگر نیز پشتیبانی می‌شوند تا زیرساختی مقاوم‌تر و hardware-agnostic شکل بگیرد. چه در حال مدیریت ناوگانی بزرگ از GPUها باشید، چه به دنبال مدیریت بهتر خطاها یا تعریف گزینه‌های fallback برای منابع، ارتقای DRA در 1.36 چیزهایی برای شما دارد — بزنیم داخل جزئیات! 🚀

توسعه‌دهندگان و جامعه وقت زیادی گذاشته‌اند تا مفاهیم کلیدی DRA را پایدار کنند. در Kubernetes 1.36 چندین قابلیت پرانتظار به حالت Beta و Stable رسیده‌اند که تجربۀ استفاده و قابلیت اطمینان را بالا می‌برد.

Prioritized list (stable): در دنیأ واقعی خوشه‌ها معمولاً از سخت‌افزار‌های ناهمگون تشکیل شده‌اند. با ویژگی Prioritized list می‌توانید هنگام درخواست دستگاه، فهرست ترجیحات ترتیبی تعریف کنید به‌جای اینکه صرفاً یک مدل مشخص را درخواست کنید. مثلاً بگویید «اول H100، اگر نبود A100 را بده». Scheduler این فهرست را به ترتیب بررسی می‌کند که باعث انعطاف بیشتر در scheduling و استفاده بهینه‌تر از کلستر می‌شود.

Extended resource support (beta): برای انتقال نرم از سیستم‌های قدیمی به DRA، این قابلیت اجازه می‌دهد تا اپ‌ها همچنان از extended resources مرسوم در Pod استفاده کنند. به این ترتیب اپلیکیشن‌ها می‌توانند به‌تدریج به API جدید ResourceClaim مهاجرت کنند در حالی که اپراتورها کلستر را به DRA منتقل کرده‌اند — بدون نیاز به تغییر فوری در همه اپ‌ها.

Partitionable devices (beta): گاهی یک workload به تمام ظرفیت یک دستگاه نیاز ندارد. با Partitionable devices می‌توان سخت‌افزار فیزیکی را به نمونه‌های منطقی کوچک‌تر (مثلاً Multi-Instance GPUs) تقسیم کرد و بر اساس نیاز بار کاری، این قسمت‌ها را به Pods تخصیص داد. این امکان کمک می‌کند شتاب‌دهنده‌های گران‌قیمت به‌صورت ایمن و مؤثر بین چندین Pod به اشتراک گذاشته شوند.

Device taints (beta): همان‌طور که روی Nodeها می‌توان taint گذاشت، حالا می‌توان به صورت مستقیم به دستگاه‌های DRA نیز taint اعمال کرد. Device taints و tolerations به مدیران کلستر امکان می‌دهد تا دستگاه‌های معیوب را از تخصیص عمومی خارج کنند یا سخت‌افزار خاصی را برای تیم‌ها یا بارهای ویژه رزرو کنند؛ فقط Podهایی که toleration مناسب داشته باشند می‌توانند آن دستگاه‌ها را claim کنند.

Device binding conditions (beta): برای افزایش اطمینان در زمان Schedule شدن، Scheduler می‌تواند از Binding conditions استفاده کند تا کامیت کردن یک Pod به یک Node را تا زمانی که منابع خارجی مورد نیاز (مثلاً دستگاه‌های attachable یا FPGA) آماده نشده‌اند به تأخیر بیندازد. با مدل کردن صریح readiness منابع، از تخصیص‌های زودهنگام که ممکن است به شکست Pod منجر شود جلوگیری می‌شود.

Resource health status (beta): تشخیص سریع زمانی که یک دستگاه خراب یا unhealthy شده برای بارهایی که روی سخت‌افزار تخصصی اجرا می‌شوند حیاتی است. با Resource health status، اطلاعات سلامت دستگاه مستقیماً در Pod status قابل مشاهده می‌شود و پیغام‌های human-readable برای تشخیص ساده‌تر مشکلات ارائه می‌شود — بدون نیاز به جستجوی عمیق در logهای درایور.

در کنار پایدارسازی امکانات موجود، v1.36 چند قابلیت پایه‌ای جدید هم معرفی کرده که فعلاً در مرحله alpha و پشت feature gates قرار دارند؛ اینها زیرساخت را برای قابلیت‌های پیشرفته‌تر آینده آماده می‌کنند.

ResourceClaim support for workloads: این ویژگی به مدیریت منابع مشترک برای کارهای بزرگ AI/ML که نیاز به scheduling توپولوژیک دارند کمک می‌کند. با اتصال ResourceClaims یا ResourceClaimTemplates به PodGroups، مشکلات مقیاس‌پذیری قبلی (مثل محدودیت تعداد پادهایی که می‌توانند یک claim را به اشتراک بگذارند) برطرف می‌شود و نیاز به مدیریت دستی claimها توسط اورکستراتورهای تخصصی کاهش می‌یابد.

Node allocatable resources: چرا DRA فقط محدود به شتاب‌دهنده‌های خارجی باشد؟ اولین نسخه‌ای که از DRA APIs برای مدیریت منابع allocatable نود مانند CPU و memory استفاده می‌کند معرفی شده است. با آوردن CPU و memory زیر چتر DRA، می‌توان از semanticsهای پیشرفته‌ای مثل placement بهتر، NUMA-awareness و prioritization برای منابع عادی محاسباتی بهره برد و tuning خیلی دقیق‌تری برای عملکرد داشت.

DRA resource availability visibility: یکی از خواسته‌های مهم اپراتورها دید بهتر به ظرفیت سخت‌افزار است. ویژگی Resource pool status به شما اجازه می‌دهد تا با ایجاد یک ResourcePoolStatusRequest، snapshot نقطه‌ای از تعداد دستگاه‌ها (total, allocated, available, unavailable) در هر pool که توسط یک driver مدیریت می‌شود دریافت کنید. این اطلاعات برای داشبوردها و برنامه‌ریزی ظرفیت بسیار کاربردی است.

List types for attributes: ارزیابی قیدهای ResourceClaim بهتر شده تا با مقادیر scalar و list سازگارتر باشد: matchAttribute اکنون برای وجود یک تقاطع غیرخالی بررسی می‌کند و distinctAttribute برای مقادیر pairwise disjoint است. همچنین یک تابع includes() در CEL اضافه شده تا selectors دستگاه به‌سادگی با تغییر نمایشی یک attribute بین scalar و list کار کنند. (تابع includes() فقط در contextهای DRA برای ارزیابی عبارت‌ها در دسترس است).

Deterministic device selection: Scheduler حالا دستگاه‌ها را به‌صورت lexicographical بر اساس نام resource pool و ResourceSlice ارزیابی می‌کند. این تغییر به درایورها امکان می‌دهد که به‌صورت پیشگیرانه ترتیب انتخاب دستگاه را تحت تأثیر قرار دهند که منجر به throughput بهتر و تصمیم‌گیری‌های scheduling بهینه‌تر می‌شود. ResourceSlice controller toolkit هم نام‌هایی تولید می‌کند که ترتیب دقیق موردنظر نویسنده درایور را منعکس می‌کند.

Discoverable device metadata in containers: بارها اپلیکیشن‌ها نیاز دارند بدون پرس‌وجوی مستقیم به API، اطلاعاتی مثل PCI bus address یا تنظیمات interface شبکه دستگاه‌های تخصیص‌یافته را بفهمند. با Device metadata، یک پروتکل استاندارد تعریف شده که درایورهای DRA مشخصات دستگاه را به صورت فایل‌های JSON versioned در مسیرهای شناخته‌شده در داخل کانتینرها قرار می‌دهند. درایورهایی که با DRA kubelet plugin library ساخته شوند این رفتار را شفافاً دریافت می‌کنند و کتابخانه مسئول layout فایل، CDI bind-mounts، versioning و lifecycle است. این روش یک راه یکنواخت و مستقل از درایور برای کشف و مصرف metadata فراهم می‌کند، بدون نیاز به کنترلرهای سفارشی یا lookup روی ResourceSlice.

چه در پیش است؟ در این ریلیز مجموعه‌ای از قابلیت‌های DRA معرفی شد و شتاب توسعه همچنان ادامه دارد. نقشه راه روی بالغ کردن قابلیت‌ها به Beta و Stable و همزمان تقویت عملکرد، مقیاس‌پذیری و پایداری DRA متمرکز است. یک اولویت مهم در دوره‌های آتی ادغام عمیق‌تر با workload-aware و topology-aware scheduling خواهد بود. هدف بزرگ، مهاجرت کاربران از Device Plugin به DRA است و مشارکت شما در این مسیر حیاتی است — چه در حال نگهداری یک درایور باشید و چه تازه می‌خواهید شروع کنید.

برای مشارکت: شروع خوب وصل شدن به کانال WG Device Management در Slack و شرکت در جلسات است (زمان‌هایی مناسب برای Americas/EMEA و EMEA/APAC وجود دارد). همه ایده‌ها هنوز به‌صورت issue ثبت نشده‌اند، پس اگر می‌خواهید کمک کنید یا ایده‌ای دارید، بیایید و صحبت کنید! حوزه‌های کاری از تغییرات هسته‌ای تا بهبودهای usability در kubectl متنوع‌اند و مورد استقبال تازه‌واردها نیز قرار می‌گیرند. 🤝🔧