Kubernetes v1.36：暂停 Job 的 Pod 资源可变更功能进入 Beta-未完纪

Kubernetes v1.36 将“修改暂停 Job 的 Pod 模板中容器资源请求和限制”的能力提升为 Beta。该功能在 v1.35 首次以 Alpha 引入，允许队列控制器和集群管理员在 Job 暂停期间、启动或恢复运行之前，调整 CPU、内存、GPU 和扩展资源配置。

为什么暂停 Job 需要可变更的 Pod 资源？

批处理和机器学习工作负载的资源需求，在创建 Job 时往往无法精确确定。最佳资源分配取决于集群当前容量、队列优先级，以及 GPU 等专用硬件是否可用。

此前，Job 的 Pod 模板中的资源需求一旦设置便不可变。如果 Kueue 等队列控制器判定暂停的 Job 应使用不同资源，唯一办法是删除并重建 Job，失去关联的元数据、状态和历史。

该功能也让 CronJob 的某个 Job 实例能够在集群高负载时减少资源、较慢地推进，而不是完全无法运行。

考虑最初请求4块 GPU 的机器学习训练 Job：

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 可用。通过此功能，控制器可以在恢复 Job 前更新其资源请求：

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，恢复 Job；新 Pod 将使用调整后的资源配置创建。

工作原理

Kubernetes API 服务器专门针对暂停的 Job，放宽 Pod 模板资源字段不可变的约束。没有引入新的 API 类型；现有 Job 和 Pod 模板结构通过放宽校验规则来支持变化。

可变更字段为：

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 此前运行过，随后被暂停，那么所有活动 Pod 必须已经终止，即 status.active 等于0，才会接受资源修改。

常规资源校验仍然适用。例如，limits 必须大于或等于 requests；需要整数的扩展资源仍必须按整数指定。

Beta 阶段的新变化

进入 Kubernetes v1.36 Beta 后，MutablePodResourcesForSuspendedJobs 特性门控默认启用。v1.36 集群无需额外配置 API 服务器即可使用。

试用

在 Kubernetes v1.36或更高版本集群中，此功能默认可用。对于 v1.35 集群，应在 kube-apiserver 上启用 MutablePodResourcesForSuspendedJobs 特性门控。

可以创建暂停的 Job，使用 kubectl edit 或控制器更新容器资源，然后恢复 Job：

# 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}}'

注意事项

暂停已运行的 Job

如果暂停的 Job 此前已运行，修改资源前必须等待其所有活动 Pod 终止。当 status.active 大于0时，API 服务器拒绝资源修改。这能避免正在运行的 Pod 与更新后的 Pod 模板不一致。

Pod 替换策略

如果结合可能包含失败 Pod 的 Job 使用此功能，可以考虑设置 podReplacementPolicy: Failed。这确保先前的 Pod 完全终止后才创建替代 Pod，防止 Pod 重叠造成资源竞争。

ResourceClaims

动态资源分配（DRA）的 resourceClaimTemplates 仍不可变。如果工作负载使用 DRA，必须单独重建声明模板，使其与资源变化匹配。

参与

该功能由 SIG Apps 开发（参见其社区目录），并吸收了 WG Batch 的意见。随着功能向稳定阶段推进，两个组都欢迎反馈。可以通过 Slack 的 #sig-apps、#wg-batch 频道，或 KEP-5440 跟踪项参与。

原文：Kubernetes v1.36: Mutable Pod Resources for Suspended Jobs (beta)
作者：Kevin Hannon（Red Hat），2026年4月27日。本文为中文译稿，保留原文 v1.35 Alpha／v1.36 Beta 范围。示例镜像与扩展资源名是原文占位值。© 2026 The Kubernetes Authors；文档依据 CC BY 4.0 提供，本篇为中文翻译与版式整理。

文章版权归作者所有，未经允许请勿转载。

THE END