Kubernetes v1.36：Pod 级别资源的原地垂直缩放进入 Beta 阶段

原文链接:https://kubernetes.io/blog/2026/04/30/kubernetes-v1-36-inplace-pod-level-resources-beta/

在 Pod 级资源（Pod-Level Resources）于 v1.34 进入 Beta 阶段、原地 Pod 垂直伸缩（In-Place Pod Vertical Scaling）于 v1.35 正式发布（GA）之后，Kubernetes 社区激动地宣布：原地 Pod 级资源垂直伸缩（In-Place Pod-Level Resources Vertical Scaling）已在 v1.36 进入 Beta 阶段！

该功能现通过 InPlacePodLevelResourcesVerticalScaling 特性门控默认启用。它允许用户更新运行中 Pod 的聚合资源预算（.spec.resources），通常无需重启容器。

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

Pod 级资源模型通过允许容器共享一个资源池，简化了复杂 Pod（例如带有边车容器的 Pod）的管理。在 v1.36 中，你可以实时调整这个聚合边界。

这对于那些容器未定义独立资源限制的 Pod 尤其有用。这些容器会自动调整其有效边界，以适应新调整的 Pod 级维度，从而让你在高峰需求时扩展共享资源池，而无需手动逐个容器重新计算。

资源继承与 resizePolicy

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

• 非破坏性更新： 如果容器的 restartPolicy 设置为 NotRequired，kubelet 会尝试通过容器运行时接口（CRI）动态更新 cgroup 限制。
• 破坏性更新： 如果设置为 RestartContainer，容器将被重启，以安全地应用新的聚合边界。

注意： 目前，resizePolicy 在 Pod 级不受支持。kubelet 始终依据单个容器的设置来决定更新是原地应用还是需要重启。

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

1. 初始 Pod 规格

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\. 调整大小操作（resize operation）

要将 CPU 容量翻倍至 4 个 CPU，请使用 resize 子资源（subresource）应用补丁（patch）：

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

节点级现实：可行性与安全性

应用调整补丁只是第一步。Kubelet 会执行多项检查，并遵循特定顺序以确保节点稳定性：

1. 可行性检查

在允许调整之前，Kubelet 会验证新的聚合请求是否在节点的可分配容量范围内。如果节点已超量使用，调整不会被忽略；相反，PodResizePending 条件将反映 Deferred（延迟）或 Infeasible（不可行）状态，从而即时反馈“资源包”为何未能增长。

2. 更新顺序

为防止资源“超调”（overshoot），Kubelet 按特定顺序协调 cgroup 更新：

• 增加时： 先扩展 Pod 级别的 cgroup，为后续单个容器 cgroup 的扩大“腾出空间”。
• 减少时： 先限制容器 cgroup，然后才缩小聚合的 Pod 级别 cgroup。

可观测性：跟踪调整状态

随着功能进入 Beta 阶段，Kubernetes 使用 Pod 条件（Pod Conditions）来跟踪调整的生命周期：

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

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

约束与要求

• 仅支持 cgroup v2： 实现精确的聚合执行所必需。
• CRI 支持： 需要容器运行时支持 UpdateContainerResources CRI 调用（例如 containerd v2.0+ 或 CRI-O）。
• 特性门控（Feature Gates）： 需要启用 PodLevelResources、InPlacePodVerticalScaling、InPlacePodLevelResourcesVerticalScaling 和 NodeDeclaredFeatures。
• 仅限 Linux： 目前仅适用于基于 Linux 的节点。

下一步计划

在迈向正式发布（GA）的过程中，社区正专注于垂直 Pod 自动扩缩器（VPA）集成，使 VPA 能够发出 Pod 级别的资源建议，并自动触发原地执行。

开始使用并提供反馈

我们鼓励您测试此功能，并通过标准的 Kubernetes 沟通渠道提供反馈：

• Slack：#sig-node
• 邮件列表
• 开放社区问题/PR