نسخه Kubernetes 1.36 که برای 22 آوریل برنامهریزی شده، مجموعهای متنوع از قابلیتهای alpha جدید را معرفی میکند که روی سه محور اصلی تمرکز دارند: عملکرد workload، مقیاسپذیری API و استفاده بهینه از منابع. این بهروزرسانی چند ویژگی مهم و مدتها مورد انتظار را هم با خودش میآورد؛ از جمله workload-aware preemption برای jobهای AI/ML، sharded API streams برای کلاسترهای بزرگ، و یکپارچگی عمیقتر Dynamic Resource Allocation (DRA) با scheduler. در این مرور، 20 بهبود جدید را بررسی میکنیم؛ قابلیتهایی که بهصورت alpha به Kubernetes اضافه شدهاند و بهطور پیشفرض غیرفعال هستند، از APIهای gRPC در سطح node گرفته تا graceful leader transitions، که هرکدام تصویری از آینده container orchestration به ما میدهند. 🚀
نکته مهم این است که این تغییرات تا زمان نزدیک شدن به تاریخ release ممکن است جابهجا شوند یا حتی از milestone حذف شوند، چون مسیر توسعه قابلیتهای Kubernetes همیشه در حال تغییر است.
Nodes DRA: Device Attributes in Downward API KEP #5304 (issue) Feature gate: none. این قابلیت یک روش استاندارد برای این میدهد که DRA driver بتواند metadata مربوط به device را پر کند. بعد از آن، framework این metadata را بهصورت خودکار به container منتقل میکند و آن را به شکل یک فایل JSON در مسیر مشخص mount میکند. نتیجه این است که دیگر لازم نیست برای این کار controllerهای سفارشی بنویسید یا workloadها را مجبور کنید مستقیم سراغ Kubernetes API بروند تا این اطلاعات را بگیرند. ⚙️
در نسخه فعلی DRA، اگر بخواهید اطلاعات deviceهای تخصیصدادهشده را بگیرید – مثلاً PCIe bus address برای GPUها یا UUID برای mediated deviceها – باید وضعیت ResourceClaim را بخوانید، ResourceSlice مرتبط را پیدا کنید و بعد attributeها را parse کنید. واقعاً این مسیر هم طولانی است و هم دردسرساز.
KEP-5304 این روند را ساده میکند: DRA driver میتواند metadata دستگاه را مستقیماً در PrepareResourceClaims تحویل بدهد، kubelet هم این داده را به یک فایل JSON مینویسد و در مسیر مشخص داخل container mount میکند. در عمل، اپلیکیشن داخل container فقط کافی است فایلی مثل /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json را بخواند تا همه attributeهای لازم را داشته باشد. 📄
New kubelet gRPC API with endpoint returning local pods information KEP #4188 (issue) Feature gate: PodInfoAPI. الان برای گرفتن آخرین وضعیت یک Pod در Kubernetes – مثل اینکه آماده است یا نه، IP آن چیست و چه labelهایی دارد – componentهایی که روی همان node اجرا میشوند، مثل CNI pluginها یا monitoring agentها، باید از Kubernetes API server query بگیرند. این مدل چند مشکل جدی دارد:
اول، در بحث reliability اگر یک node ارتباطش را با control plane از دست بدهد، componentهای محلی دیگر نمیتوانند اطلاعات بهروز Pod را بگیرند، در حالی که همین اطلاعات روی kubelet محلی وجود دارد. دوم، از نظر scalability، وقتی روی هر node تعداد زیادی agent درخواست بفرستند، فشار اضافهای روی API server ایجاد میشود. سوم، از نظر latency، یک network call تا API server همیشه از یک call محلی روی node کندتر است. ⏱️
نویسندگان این KEP یک API جدید gRPC برای Pods پیشنهاد کردهاند که مستقیم روی node اجرا میشود. این API از طریق یک UNIX socket در مسیر /var/lib/kubelet/pods/kubelet.sock در دسترس خواهد بود. برای امنیت، فقط کاربران یا processهای privileged میتوانند به فایل socket دسترسی داشته باشند. این API جدید، تازهترین اطلاعاتی را که kubelet در اختیار دارد برمیگرداند، حتی اگر هنوز با API server sync نشده باشد.
Clientها میتوانند یا کل PodSpec و PodStatus را درخواست کنند یا با استفاده از google.protobuf.FieldMask فقط فیلدهای خاصی را بگیرند. این API سه متد اصلی دارد: ListPods، GetPod و WatchPods که تغییرات وضعیت Podها را بهصورت stream دنبال میکند. 🔄
CRI List Streaming KEP #5825 (issue) Feature gate: CRIListStreaming. گاهی kubelet لازم دارد فهرستی از همه containerهای روی یک node را بگیرد، مثلاً برای garbage collection. برای این کار یک درخواست CRI مثل ListContainers ارسال میکند. مشکل اینجاست که RPCهای فعلی CRI از نوع unary هستند؛ یعنی client یک درخواست میفرستد و server هم یک پاسخ واحد برمیگرداند که کل لیست را داخل خودش دارد.
روی nodeهای شلوغ که هزاران container همزمان اجرا میشوند – مثلاً بهخاطر تعداد زیادی CronJob کوتاهعمر – این لیست میتواند از 16 MB هم بزرگتر شود؛ که همان حداکثر اندازه پیشفرض message در gRPC است. جالب اینکه این محدودیت را حتی با حدود 11,000 container یا 14,000 Pod هم ممکن است رد کنید. 😅
برای اینکه backward compatibility در RPCهای unary فعلی حفظ شود، این KEP سراغ server-side streaming RPCهای جدید میرود. وقتی container runtime یک درخواست streaming دریافت میکند، دیگر کل پاسخ را یکجا در memory نمیسازد. بهجای آن یک gRPC stream باز میکند و برای هر container یک StreamContainersResponse جداگانه میفرستد. kubelet هم این stream را میخواند تا زمانی که بسته شود. بعد یک wrapper function ویژه، همه قطعات را در memory کنار هم میگذارد و یک لیست نهایی برای پردازشهای بعدی میسازد.
DRA: Resource Availability Visibility KEP #5677 (issue) Feature gate: DRAResourcePoolStatus. بهعنوان developer، شاید بخواهید ببینید کدام resourceهای DRA در کلاستر آزاد هستند تا مشکل یک Pod را که بهخاطر “insufficient DRA resources” زمانبندی نشده، عیبیابی کنید. از طرف دیگر، بهعنوان administrator ممکن است لازم داشته باشید بدانید چند GPU واقعاً در دسترس است تا برای capacity آینده برنامهریزی کنید. اما الان این کار چندان ساده نیست، چون:
ResourceSliceها cluster-scoped هستند و فقط capacity کل deviceها در یک pool را نشان میدهند. ResourceClaimها namespaced هستند و تخصیصهای مشخص منابع را track میکنند. کاربرانی که permission محدود دارند هم نمیتوانند ResourceClaimهای خارج از namespace خودشان را ببینند. از طرف دیگر، هیچ مکانیزم API-level برای دیدن نسبت ظرفیت آزاد به ظرفیت تخصیصیافته وجود ندارد. 📊
این KEP یک API جدید به نام ResourcePoolStatusRequest اضافه میکند که الگوی آن شبیه CertificateSigningRequest است. کاربر یک ResourcePoolStatusRequest میسازد و داخل آن driver را بهصورت اجباری و pool filter را بهصورت اختیاری مشخص میکند. سپس یک controller در kube-controller-manager درخواستهای جدید را watch میکند و آنها را برمیدارد. بعد controller میزان availability آن pool را محاسبه میکند و نتیجه را در فیلد status همان object مینویسد. کاربر هم با خواندن status میتواند وضعیت availability pool را ببیند.
اگر بخواهید یک update جدید بگیرید، باید request قدیمی را حذف کنید و یک request تازه بسازید. این مدل، ساده و شفاف است و برای مشاهده وضعیت poolهای DRA، مخصوصاً در سناریوهای capacity planning و troubleshooting، خیلی کمک میکند. 🛠️
نمونهای برای دیدن وضعیت یک DRA device pool: یک request ایجاد کنید تا status همه GPU poolها بررسی شود و تا کامل شدن آن صبر کنید: $ kubectl create -f –
