Kubernetes v1.36：Pod 级资源的原地垂直伸缩进入 Beta-未完纪

继 Pod 级资源在 v1.34 进入 Beta、Pod 原地垂直伸缩在 v1.35 正式可用（GA）之后，Kubernetes 社区宣布：Pod 级资源的原地垂直伸缩在 v1.36 进入 Beta！

这项功能通过 InPlacePodLevelResourcesVerticalScaling 特性门控默认启用。它允许用户更新正在运行的 Pod 的整体资源预算（.spec.resources），通常不需要重启容器。

为什么需要 Pod 级原地调整？

Pod 级资源模型允许容器共享一个资源池，简化了复杂 Pod（例如包含边车容器的 Pod）的管理。在 v1.36 中，你可以动态调整这个整体边界。

对于没有定义各自资源限制的容器，这尤其有用。它们的有效资源边界会自动随调整后的 Pod 级资源额度变化，因此你可以在需求高峰期间扩充共享资源池，无须手动重新计算每个容器的资源额度。

资源继承与 `resizePolicy`

发起 Pod 级资源调整时，kubelet 会把这次变更视为每一个从 Pod 级预算继承资源限制的容器的资源调整事件。为了判断是否需要重启，kubelet 会检查各容器内定义的 resizePolicy：

不中断的更新：如果其中的 restartPolicy 设置为 NotRequired，kubelet 会尝试通过容器运行时接口（CRI）动态更新 cgroup 限制。
会中断的更新：如果设置为 RestartContainer，容器会重启，以安全应用新的整体资源边界。

目前，Pod 级别不支持 resizePolicy。kubelet 始终依据各容器的设置，决定更新能否原地完成，还是需要重启。

示例：扩充共享资源池

在这个场景中，Pod 定义了一个 2 CPU 的 Pod 级限制。由于各容器没有定义自己的限制，它们共享这个资源池。

1. 初始 Pod 定义

Pod 初始配置（YAML）

apiVersion: v1
kind: Pod
metadata:
  name: shared-pool-app
spec:
  resources: # Pod-level limits
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: main-app
    image: my-app:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
  - name: sidecar
    image: logger:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]

2. 调整资源

要将 CPU 容量翻倍到 4 CPU，通过 resize 子资源应用补丁：

通过 resize 子资源更新 CPU（Shell）

kubectl patch pod shared-pool-app --subresource resize --patch \
  '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

节点侧的实际处理：可行性与安全性

应用资源调整补丁只是第一步。kubelet 会执行多项检查，并按照特定顺序处理，以保证节点稳定。

1. 可行性检查

接受资源调整之前，kubelet 会验证新的整体资源请求是否能容纳在节点的可分配容量内。如果节点资源已被超额承诺，这次调整不会被直接忽略；PodResizePending 条件会反映 Deferred 或 Infeasible 状态，立即反馈为什么资源“包络”尚未扩大。

2. 更新顺序

为了避免资源“超出边界”，kubelet 按特定顺序协调 cgroup 更新：

增大资源时：先扩充 Pod 级 cgroup，为各容器 cgroup 的扩充腾出空间，再增大容器 cgroup。
减小资源时：先限制容器 cgroup，再缩小整体 Pod 级 cgroup。

可观测性：跟踪调整状态

进入 Beta 后，Kubernetes 使用 Pod 条件跟踪资源调整的生命周期：

PodResizePending：spec 已更新，但节点尚未接受变更，例如节点容量不足。
PodResizeInProgress：节点已经接受调整（status.allocatedResources），但变更尚未完全应用到 cgroup（status.resources）。

Pod 状态片段（YAML）

status:
  allocatedResources:
    cpu: "4"
  resources:
    limits:
      cpu: "4"
  conditions:
  - type: PodResizeInProgress
    status: "True"

限制与要求

仅支持 cgroup v2：这是准确执行整体资源限制的必要条件。
CRI 支持：需要支持 UpdateContainerResources CRI 调用的容器运行时，例如 containerd v2.0+ 或 CRI-O。
特性门控：需要 PodLevelResources、InPlacePodVerticalScaling、InPlacePodLevelResourcesVerticalScaling 和 NodeDeclaredFeatures。
仅支持 Linux：目前只能用于 Linux 节点。

下一步是什么？

随着功能向正式可用（GA）推进，社区正在关注与 Vertical Pod Autoscaler（VPA）的集成，让 VPA 能够提供 Pod 级资源建议，并自动触发原地调整。

开始使用并提供反馈

欢迎测试这项功能，并通过 Kubernetes 的常用沟通渠道提供反馈：

原文：Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta。作者：Narang Dixita Sohanlal（Google），2026年4月30日。原页最后修改于2026年5月2日。本文为中文翻译，适用 Kubernetes v1.36。原文及本译文遵循 CC BY 4.0；Kubernetes 文档许可。材料按原样提供，不作保证。

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

THE END