‏Kubernetes 1.36: زمان‌بندی هوشمند برای بارهای کاری AI و Batch

کوبرنتیز ۱.۳۶ یه تغییر معماری مهم تو زمان‌بندی بارهای کاری معرفی می‌کنه. تا قبل از این، اطلاعات مربوط به Pod Group و وضعیت runtime هر دو داخل یه شیء Workload بودن. حالا این دو از هم جدا شدن: Workload فقط یه قالب ثابته که کنترلرها (مثل Job controller) ازش استفاده می‌کنن، و PodGroup یه شیء مستقل runtime‌ه که وضعیت واقعی زمان‌بندی گروه رو نگه می‌داره. هر دو این APIها در گروه scheduling.k8s.io/v1alpha2 عرضه می‌شن.

این جداسازی چند مزیت داره: scheduler دیگه نیازی نداره شیء Workload رو بخونه و پارس کنه؛ مستقیم سراغ PodGroup می‌ره که همه اطلاعات لازم رو داره. علاوه بر این، فیلد workloadRef در Pod API جای خودش رو به فیلد schedulingGroup داده که Pod رو مستقیماً به PodGroup runtime مرتبط می‌کنه.

برای مدیریت بهتر این بارهای کاری، scheduler حالا یه PodGroup scheduling cycle اختصاصی داره. به‌جای اینکه پادها رو یکی‌یکی زمان‌بندی کنه (که ممکنه به deadlock بینجامه)، کل گروه رو به‌صورت یه واحد اتمیک ارزیابی می‌کنه. اول یه snapshot از وضعیت کلاستر می‌گیره، بعد برای همه پادها جای مناسب پیدا می‌کنه، و در آخر تصمیم رو برای کل گروه اعمال می‌کنه. این چرخه پایه gang scheduling هست؛ یعنی اگه نشه همه پادها رو با هم اجرا کرد، هیچ‌کدوم اجرا نمی‌شن.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-job-workers-pg
  namespace: some-ns
spec:
  podGroupTemplateRef:
    workload:
      workloadName: training-job-workload
      podGroupTemplateName: workers
  schedulingPolicy:
    gang:
      minCount: 4
status:
  conditions:
  - type: PodGroupScheduled
    status: "True"

قابلیت topology-aware scheduling هم در این نسخه معرفی شده. برای بارهای کاری توزیع‌شده‌ای مثل آموزش مدل‌های AI، جایگذاری تصادفی پادها می‌تونه تأخیر شبکه رو زیاد کنه. این ویژگی بهت اجازه می‌ده محدودیت‌های توپولوژی (مثل rack یا zone) رو مستقیم روی PodGroup تعریف کنی تا پادها در یه دامنه فیزیکی یا منطقی مشخص کنار هم بمونن. Scheduler سه مرحله رو طی می‌کنه: تولید candidate placement‌ها، ارزیابی امکان‌پذیری، و امتیازدهی برای انتخاب بهترین جایگذاری.

workload-aware preemption هم یه مکانیزم جدید preemption معرفی می‌کنه که کل PodGroup رو به‌عنوان یه واحد در نظر می‌گیره. برخلاف preemption پیش‌فرض که نودها رو جداگانه بررسی می‌کنه، این مکانیزم می‌تونه همزمان پادها رو از چند نود حذف کنه تا جای کافی برای کل گروه باز بشه. دو فیلد جدید هم به PodGroup API اضافه شده: priority که اولویت گروه رو مشخص می‌کنه، و disruptionMode که تعیین می‌کنه پادهای گروه می‌تونن جداگانه preempt بشن یا باید همه با هم.

در نهایت، DRA (Dynamic Resource Allocation) که از نسخه ۱.۳۴ به general availability رسیده، حالا با PodGroup یکپارچه شده. یعنی می‌شه یه ResourceClaimTemplate رو برای کل PodGroup تعریف کرد تا همه پادهای گروه به یه سخت‌افزار مشترک (مثل GPU یا TPU) دسترسی داشته باشن، بدون اینکه لازم باشه به‌صورت دستی ResourceClaim جداگانه بسازی.

نکات کلیدی:

• Workload API حالا فقط قالب ثابته؛ PodGroup وضعیت runtime رو مدیریت می‌کنه
• PodGroup scheduling cycle، زمان‌بندی اتمیک کل گروه پادها رو ممکن می‌کنه
• Gang scheduling: اگه همه پادها نشه اجرا کرد، هیچ‌کدوم اجرا نمی‌شن
• Topology-aware scheduling پادها رو در یه دامنه فیزیکی مشخص کنار هم نگه می‌داره
• Workload-aware preemption کل PodGroup رو به‌عنوان یه واحد preempt می‌کنه
• DRA ResourceClaim برای PodGroup: اشتراک GPU/TPU بین پادهای یه گروه بدون نیاز به تنظیمات دستی