Kubernetes v1.36：暂停 Job 的可变 Pod 资源（beta）

Kubernetes v1.36 将在暂停 Job 的 Pod 模板中修改容器资源请求和限制的能力提升至 beta。该功能最早在 v1.35 中作为 alpha 引入，允许队列控制器和集群管理员在 Job 处于暂停状态、尚未开始或恢复运行之前，调整该 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 server 专门针对暂停 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

在满足以下条件时允许进行资源更新：

1. Job 的 spec.suspend 设置为 true。
2. 对于先前已运行后又被暂停的 Job，必须在所有活动 Pod 都已终止（status.active 等于 0）后，才会接受资源变更。

标准资源校验仍然适用。例如，资源限制必须大于或等于请求；扩展资源在需要时必须以整数形式指定。

beta 版的新变化

随着 Kubernetes v1.36 提升至 beta，MutablePodResourcesForSuspendedJobs 功能门控默认启用。这意味着运行 v1.36 的集群无需在 API server 上进行任何额外配置即可使用此功能。

试用

如果你的集群运行 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，必须等待该 Job 的所有活动 Pod 终止后才能修改资源。当 status.active 大于零时，API server 会拒绝资源变更。这可防止运行中的 Pod 与更新后的 Pod 模板之间出现不一致。

Pod 替换策略

将此功能用于可能存在失败 Pod 的 Job 时，请考虑设置 podReplacementPolicy: Failed。这可确保只有在先前的 Pod 完全终止后才创建替换 Pod，避免重叠 Pod 造成资源争用。

正文：ResourceClaims

动态资源分配（DRA）的 resourceClaimTemplates 仍然不可变。如果你的工作负载使用 DRA，必须单独重新创建 claim 模板，以匹配任何资源变更。

参与方式

此功能由 SIG Apps 开发；此功能由 SIG Apps 在 WG Batch 提供意见的基础上开发。随着该功能迈向稳定版，两个小组都欢迎反馈。

你可以通过以下方式联系：

• Slack 频道 #sig-apps。
• Slack 频道 #wg-batch。
• KEP-5440 跟踪议题。

• ← 上一篇
• 下一篇 →