Kubernetes v1.36 promotes the ability to modify container resource requests and limits in the pod template of a suspended Job to beta. First introduced as alpha in v1.35, this feature allows queue controllers and cluster administrators to adjust CPU, memory, GPU, and extended resource specifications on a Job while it is suspended, before it starts or resumes running. Why mutable pod resources for suspended Jobs? Batch and machine learning workloads often have resource requirements that are not precisely known at Job creation time. The optimal resource allocation depends on current cluster capacity, queue priorities, and the availability of specialized hardware like GPUs. Before this feature, resource requirements in a Job’s pod template were immutable once set. If a queue controller like Kueue determined that a suspended Job should run with different resources, the only option was to delete and recreate the Job, losing any associated metadata, status, or history. This feature also provides a way to let a specific Job instance for a CronJob progress slowly with reduced resources, rather than outright failing to run if the cluster is heavily loaded. Consider a machine learning training Job initially requesting 4 GPUs: 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 A queue controller managing cluster resources might determine that only 2 GPUs are available.…
Want more insights? Join Grow With Caliber - our career elevating newsletter and get our take on the future of work delivered weekly.
