Kubernetes v1.36：挂起作业的可变 Pod 资源（测试版）

原文链接:https://kubernetes.io/blog/2026/04/27/kubernetes-v1-36-mutable-pod-resources-for-suspended-jobs/

Kubernetes v1.36 将修改挂起（suspended）Job 的 Pod 模板中容器资源请求（resource requests）和限制（limits）的能力提升至 Beta 阶段。该特性最初在 v1.35 作为 Alpha 引入，允许队列控制器（queue controller）和集群管理员在 Job 挂起期间、启动或恢复运行之前，调整其 CPU、内存、GPU 及扩展资源（extended resource）规格。

为什么需要可变的挂起 Job 的 Pod 资源？

批处理（batch）和机器学习工作负载的资源需求在 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

当满足以下条件时，允许更新资源：

1. Job 的 spec.suspend 设置为 true。
2. 对于之前运行过然后被挂起的 Job，所有活跃的 Pod 必须已终止（status.active 等于 0），之后才能接受资源变更。

标准的资源验证仍然适用。例如，资源 limits（限制）必须大于或等于 requests（请求），扩展资源在需要时必须指定为整数。

Beta 版本的新变化

随着 Kubernetes v1.36 中升级为 Beta 版本，MutablePodResourcesForSuspendedJobs 特性门控（feature gate）默认启用。这意味着运行 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

# 编辑资源请求
kubectl edit job training-job-example-abcd123

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

注意事项

运行已暂停的 Job

如果你暂停了一个正在运行的 Job，必须等待该 Job 的所有活跃 Pod 终止后才能修改资源。当 status.active 大于零时，API 服务器会拒绝资源变更。这可以防止运行中的 Pod 与更新后的 Pod 模板之间出现不一致。

Pod 替换策略

当将此功能用于可能包含失败 Pod 的 Job 时，建议设置 podReplacementPolicy: Failed。这确保只有在之前的 Pod 完全终止后才会创建替换 Pod，从而避免重叠 Pod 导致的资源争用。

ResourceClaims

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

参与贡献

此功能由 SIG Apps 和 SIG Apps 开发，并得到了 WG Batch 的输入。两个小组都欢迎在功能向稳定版推进的过程中提供反馈。

你可以通过以下渠道联系：

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