در این مقاله به kube-scheduler و نقش زمان‌بندی آگاهانه در بارهای کاری Kubernetes نسخه 1.35 می‌پردازیم.


Workload API و Gang scheduling در kube-scheduler


کلمه کلیدی این مطلب kube-scheduler است که به بهبود زمان‌بندی در سطح گروه‌های Pod کمک می‌کند.

Kubernetes نسخه 1.35 — معرفی زمان‌بندی آگاهانه بار کاری 😊 | دوشنبه 29 دسامبر 2025

زمان‌بندی بارهای کاری بزرگ خیلی پیچیده‌تر و حساس‌تر از زمان‌بندی یک Pod تنها است. در مثال‌های رایج مثل یک job دسته‌ای برای یادگیری ماشین، معمولاً نیاز دارید که کارگرها به‌صورت استراتژیک توزیع شوند (مثلاً روی یک قفسه) تا کلیت کار سریع و کارآمد اجرا شود. از طرف دیگر، پادهایی که عضوی از یک چنین بار کاری هستند معمولاً از منظر نیازمندی‌های زمان‌بندی یکسان‌اند و این رفتار، مدل زمان‌بندی را تغییر می‌دهد.

هرچند چندین scheduler سفارشی برای این نوع بارها وجود دارد، با توجه به رشد چشمگیر استفاده از workloads در عصر هوش مصنوعی، منطقی است که قابلیت‌های مرتبط به‌صورت بومی در kube-scheduler ارائه شوند. نسخه 1.35 اولین گام‌ها را برای زمان‌بندی آگاهانه از بار کاری (workload-aware scheduling) برداشته است و این به‌عنوان بخشی از یک تلاش بزرگتر برای یکپارچه‌سازی برنامه‌ریزی و مدیریت بارهای کاری ارائه می‌شود.

یکی از اجزای کلیدی در این نسخه، معرفی Workload API است. این منبع جدید در گروه API scheduling.k8s.io/v1alpha1 قرار دارد و به‌عنوان یک تعریف ساختاریافته از الزامات زمان‌بندی یک برنامه چند-Pod عمل می‌کند. در حالی که مثلاً Job مشخص می‌کند چه چیزی باید اجرا شود، Workload مشخص می‌کند چگونه یک گروه Pod باید برنامه‌ریزی و در طول چرخه‌عمر مدیریت شود — یعنی شما می‌توانید گروهی از Pods را تعریف و یک سیاست زمان‌بندی روی آن‌ها اعمال کنید.

برای مثال، یک پیکربندی ساده برای زمان‌بندی «باند» (Gang scheduling) که نیازمند حداقل تعداد مشخصی Pod است می‌تواند این‌طور به نظر برسد:

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: workers
spec:
  policy:
    gang:
      minCount: 4

هنگامی که Podها را می‌سازید، آن‌ها را با استفاده از فیلد جدید WorkloadRef به Workload مرتبط می‌کنید تا kube-scheduler بداند هر Pod متعلق به کدام گروه است. بدون زمان‌بندی گروهی، ممکن است بخشی از یک Job برنامه‌ریزی شود اما نتواند اجرا شود، که منجر به هدررفت منابع یا بن‌بست می‌شود — Workload و افزونه GangScheduling برای حل این‌ها طراحی شده‌اند.

نحوه کارِ GangScheduling به‌طور کلی این است: چرخه‌عمر گروه‌های Pod را مدیریت می‌کند و تا وقتی که شرایط زیر برقرار نباشد، اجازه اتصال به گره‌ها را صادر نمی‌کند:
– شیء Workload ارجاع‌شده وجود دارد،
– گروه Pod مربوط در آن Workload تعریف شده است،
– تعداد Podهای آماده حداقل برابر minCount تعریف‌شده باشد.

وقتی Podها به اندازه کافی رسیدند، kube-scheduler تلاش می‌کند تا آن‌ها را مکان‌یابی کند. اما به‌جای bind فوری، همه Podها در یک permit gate منتظر می‌مانند تا مشخص شود کل گروه قابل تخصیص است. اگر فضای لازم برای کل گروه وجود داشته باشد، دروازه باز و همه Podها به گره‌ها متصل می‌شوند. اگر تنها زیرمجموعه‌ای از گروه در بازه زمانی 5 دقیقه برنامه‌ریزی شد، کل گروه دوباره در صف قرار می‌گیرد و منابع آزاد می‌شوند تا از تعارض یا بن‌بست جلوگیری شود.

این پیاده‌سازی اولیۀ Gang scheduling است و تیم Kubernetes برنامه دارد الگوریتم و قابلیت‌ها را در نسخه‌های بعدی گسترش دهد — از جمله هدف‌هایی مثل یک‌مرحله‌ای کردن زمان‌بندی کل گروه، پیش‌دستی در سطح Workload و دیگر بهبودها تا به «ستاره شمالی» یعنی برنامه‌ریزی و مدیریت یکپارچهٔ Workloadها نزدیک‌تر شود.

علاوه بر Gang scheduling، نسخه 1.35 ویژگی Opportunistic batching را هم معرفی می‌کند (حالت Beta). این ویژگی برای سرعت‌بخشی به زمان‌بندی Podهای «یکسان» طراحی شده و نیازی به تعریف صریح Workload ندارد. وقتی kube-scheduler یک Pod را پردازش می‌کند، می‌تواند محاسبات feasibility را برای Podهای مشابه بعدی دوباره استفاده کند و در نتیجه تاخیر زمان‌بندی را به‌طرز محسوسی کاهش دهد — بسیاری از کاربران به‌طور خودکار از این بهینه‌سازی بهره‌مند خواهند شد، به شرطی که Podهایشان معیارهای لازم را داشته باشند 😊.

چند نکته مهم درباره محدودیت‌ها: Opportunistic batching تنها وقتی فعال است که همه فیلدهایی که kube-scheduler برای پیدا کردن مکان استفاده می‌کند بین Podهای مشابه یکسان باشند. برخی امکانات یا پیکربندی‌ها می‌توانند مکانیسم گروه‌بندی را برای حفظ درستی کار غیرفعال کنند؛ بنابراین احتمالاً لازم است فایل پیکربندی kube-scheduler خود را بازبینی کنید تا مطمئن شوید گروه‌بندی به‌طور ضمنی غیرفعال نشده است.

چشم‌انداز کلی پروژه جاه‌طلبانه است: این APIها و بهبودهای زمان‌بندی فقط شروع کارند. در مسیر بعدی انتظار می‌رود مواردی مثل فاز زمان‌بندی Workload، پشتیبانی بهتر از DRA چندگره‌ای، زمان‌بندی آگاهانه توپولوژی، پیش‌گیرانه‌سازی در سطح Workload، تعامل بهتر بین زمان‌بندی و مقیاس‌دهی خودکار، و مدیریت کامل چرخه‌های کاری بهبود یابند. ترتیب و اولویت این موارد ممکن است تغییر کند؛ منتظر به‌روزرسانی‌های بعدی باشید.

شروع به امتحان کردن این قابلیت‌ها:
– فعال‌سازی Workload API: Feature gate GenericWorkload را هم در kube-apiserver و هم در kube-scheduler فعال کنید و مطمئن شوید گروه API scheduling.k8s.io/v1alpha1 در کلاستر شما فعال است.
– Gang scheduling: برای استفاده نیاز به فعال بودن Workload API دارد.
– Opportunistic batching: این ویژگی در 1.35 به‌صورت Beta به‌طور پیش‌فرض فعال است؛ در صورت نیاز می‌توانید با Feature gate OpportunisticBatching در kube-scheduler آن را غیرفعال کنید.

ما شما رو تشویق می‌کنیم این قابلیت‌ها رو در محیط‌های آزمایشی خود امتحان کنید و بازخوردتون رو برای شکل‌ دادن آیندهٔ زمان‌بندی Kubernetes ارسال کنید. برای مشارکت می‌تونید در Slack به #sig-scheduling سر بزنید یا issue مرتبط با workload-aware scheduling در مخزن Kubernetes باز کنید. 🙌