Kubernetes v1.36：Pod 级资源的原地垂直扩缩容晋级 Beta

继 Pod-Level Resources 在 v1.34 晋级 Beta、In-Place Pod Vertical Scaling 在 v1.35 达到通用可用（GA）之后，Kubernetes 社区很高兴宣布，In-Place Pod-Level Resources Vertical Scaling 已在 v1.36 晋级 Beta！

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

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

Pod 级资源模型允许容器共享一个统一的资源池，从而简化了复杂 Pod（例如带有 sidecar 的 Pod）的管理。在 v1.36 中，你现在可以动态调整这个聚合边界。

这对于未定义单独限制的容器所在的 Pod 尤其有用。这些容器会自动扩展其有效边界，以适配新调整后的 Pod 级尺寸，使你能够在需求高峰期扩展共享资源池，而无需手动逐个容器重新计算。

资源继承与 resizePolicy

当发起 Pod 级调整大小时，Kubelet 会将该变更视为每个从 Pod 级预算继承限制的容器的调整大小事件。为确定是否需要重启，Kubelet 会参考各个容器内定义的 resizePolicy：

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

注意：目前，Pod 级别不支持 resizePolicy。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. 调整大小操作

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

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

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

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

1. 可行性检查

在准许调整大小之前，Kubelet 会验证新的聚合请求是否适合 Node 的可分配容量。如果 Node 已超额提交，该调整不会被忽略；相反，PodResizePending 条件会反映 Deferred 或 Infeasible 状态，立即反馈为什么“包络”尚未扩大。

2. 更新顺序

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

• 增加时：先扩展 Pod 级 cgroup，在扩大各个容器 cgroup 之前先创建“空间”。
• 减少时：先限制容器 cgroup，随后才缩小聚合的 Pod 级 cgroup。

可观测性：跟踪调整大小状态

随着该功能进入 Beta，Kubernetes 使用 Pod Conditions 来跟踪调整大小的生命周期：

• PodResizePending：spec 已更新，但 Node 尚未准许该变更（例如由于容量原因）。
• PodResizeInProgress：Node 已准许调整大小（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）。
• 特性门控：需要 PodLevelResources、InPlacePodVerticalScaling、InPlacePodLevelResourcesVerticalScaling 和 NodeDeclaredFeatures。
• 仅限 Linux：目前仅适用于基于 Linux 的节点。

下一步是什么？

随着我们迈向通用可用（GA），社区正专注于 Vertical Pod Autoscaler（VPA）Integration，使 VPA 能够发出 Pod 级资源建议，并自动触发原地执行。

开始使用并提供反馈

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

• 正文：Slack：#sig-node
• 邮件列表
• 开放社区 Issues/PRs

• ← 上一篇
• 下一篇 →