قابلیت تغییر Mutable Pod Resources برای Suspended Jobs

Kubernetes v1.36 قابلیتی را به حالت beta ارتقاء داده که اجازه می‌دهد منابع کانتینرها در pod template یک Job که در حالت suspended است تغییر داده شوند. 😎 این امکان برای queue controllerها و مدیران کلاستر مفید است تا قبل از شروع یا resume کردن Job، درخواست‌های CPU، memory، GPU و extended resources را تنظیم کنند.

چرا این قابلیت مهم است؟ 🧠 در بارکاری‌های batch و machine learning معمولاً زمانی که Job ساخته می‌شود دقیقاً نمی‌دانیم چه منابعی لازم است. تخصیص بهینه منابع وابسته به ظرفیت فعلی کلاستر، اولویت صف‌ها و دسترسی به سخت‌افزارهای ویژه مثل GPU است. پیش از این، فیلدهای منابع در pod template پس از تعیین شدن غیرقابل‌تغییر بودند و اگر queue controller تصمیم می‌گرفت منابع را تغییر دهد، ناچار بودند Job را حذف و دوباره ایجاد کنند که باعث از دست رفتن متادیتا، وضعیت یا تاریخچه می‌شد. این ویژگی همچنین به شما اجازه می‌دهد یک نمونه مشخص از CronJob در شرایط بار سنگین به‌صورت تدریجی با منابع کمتر جلو برود به‌جای اینکه اجرای آن به‌طور کامل شکست بخورد. 🚀

مثال: فرض کنید یک Job آموزش ML که در ابتدا 4 GPU درخواست کرده است:

apiVersion: batch/v1
kind: Job
metadata:
  name: training-job-example-abcd123
  labels:
    app.kubernetes.io/name: trainer
spec:
  suspend: true
  template:
    metadata:
      annotations:
        kubernetes.io/description: "ML training, ID abcd123"
    spec:
      containers:
      - name: trainer
        image: example-registry.example.com/training:2026-04-23T150405.678
        resources:
          requests:
            cpu: "8"
            memory: "32Gi"
            example-hardware-vendor.com/gpu: "4"
          limits:
            cpu: "8"
            memory: "32Gi"
            example-hardware-vendor.com/gpu: "4"
      restartPolicy: Never

اگر کنترلری که صف‌ها را مدیریت می‌کند ببیند تنها 2 GPU در دسترس است، با این ویژگی می‌تواند قبل از resume کردن Job، resource requests را به‌روزرسانی کند:

apiVersion: batch/v1
kind: Job
metadata:
  name: training-job-example-abcd123
  labels:
    app.kubernetes.io/name: trainer
spec:
  suspend: true
  template:
    metadata:
      annotations:
        kubernetes.io/description: "ML training, ID abcd123"
    spec:
      containers:
      - name: trainer
        image: example-registry.example.com/training:2026-04-23T150405.678
        resources:
          requests:
            cpu: "4"
            memory: "16Gi"
            example-hardware-vendor.com/gpu: "2"
          limits:
            cpu: "4"
            memory: "16Gi"
            example-hardware-vendor.com/gpu: "2"
      restartPolicy: Never

پس از به‌روزرسانی منابع، کنترلر spec.suspend را false می‌کند و Pods جدید با منابع تنظیم‌شده ساخته می‌شوند. 🔁

عملکرد داخلی: API server محدودیت immutability روی فیلدهای منابع در pod template را فقط برای Jobs معلق (suspended) شل می‌کند. هیچ نوع API جدیدی اضافه نشده و ساختارهای Job و pod template موجود با اعتبارسنجی شل شده این تغییر را تحمل می‌کنند.

فیلدهای قابل تغییر عبارتند از:
spec.template.spec.containers[*].resources.requests
spec.template.spec.containers[*].resources.limits
spec.template.spec.initContainers[*].resources.requests
spec.template.spec.initContainers[*].resources.limits

قوانین پیش‌نیاز برای انجام به‌روزرسانی منابع:
– Job باید spec.suspend را روی true داشته باشد.
– اگر Job قبلاً در حال اجرا بود و سپس معلق شد، تمام Pods فعال آن باید خاتمه یافته باشند (یعنی status.active برابر 0) تا اجازه mutation داده شود؛ در غیر این صورت API server درخواست را رد می‌کند. این کار از ناسازگاری بین Pods در حال اجرا و template به‌روز‌شده جلوگیری می‌کند.
– اعتبارسنجی استاندارد منابع همچنان اعمال می‌شود؛ مثلاً limits باید بزرگ‌تر یا مساوی requests باشند و extended resources در صورت نیاز باید به صورت اعداد صحیح مشخص شوند.

چه چیز جدیدی در beta شده است؟ 📌 با ارتقاء به beta در v1.36، feature gate مربوطه MutablePodResourcesForSuspendedJobs به‌صورت پیش‌فرض فعال است، یعنی در کلاسترهایی که v1.36 اجرا می‌کنند این قابلیت بدون پیکربندی اضافی در kube-apiserver قابل استفاده است.

آزمایش کردن در کلاستر:
اگر کلاستر شما v1.36 یا بالاتر است، این قابلیت به‌صورت پیش‌فرض فعال است. در کلاسترهای v1.35 باید feature gate را روی kube-apiserver فعال کنید. برای تست می‌توانید یک Job معلق بسازید، منابع کانتینر را ویرایش کنید و سپس Job را resume کنید:

# Create a suspended Job
kubectl apply -f my-job.yaml --server-side

# Edit the resource requests
kubectl edit job training-job-example-abcd123

# Resume the Job
kubectl patch job training-job-example-abcd123 -p '{"spec":{"suspend":false}}'

نکات و موارد قابل توجه:
– suspend کردن Jobهای در حال اجرا: اگر Job را بعد از اجرا معلق کنید، باید منتظر بمانید تا تمام Pods فعال آن خاتمه یابند پیش از اینکه بتوانید منابع را تغییر دهید؛ تا وقتی status.active بزرگ‌تر از صفر باشد، تغییرات منابع رد می‌شود.
– podReplacementPolicy: اگر با Jobهایی کار می‌کنید که ممکن است Pods آن‌ها Fail شده باشد، در نظر بگیرید podReplacementPolicy: Failed را تنظیم کنید تا Pods جایگزین تنها پس از خاتمه کامل Pods قبلی ایجاد شوند و از همپوشانی و رقابت منابع جلوگیری شود.
– ResourceClaims/DRA: templateهای resourceClaim برای Dynamic Resource Allocation (DRA) همچنان immutable باقی می‌مانند. اگر از DRA استفاده می‌کنید باید claim templates را جداگانه بازسازی کنید تا با تغییر منابع مطابقت داشته باشند.

درگیر شدن و بازخورد: این قابلیت توسط SIG Apps توسعه یافته و WG Batch نیز در طراحی آن مشارکت داشته؛ اگر بازخورد یا سوال دارید، این گروه‌ها پذیرای نظرات شما هستند و پیگیری توسعه از طریق KEP-5440 انجام می‌شود. 🛠️