devops

Kubernetes 1.35：In-Place Pod Resize 正式进入稳定

发布: (2025年12月20日 GMT+8 02:30)
9 min read
原文: Kubernetes Blog

Source: Kubernetes Blog

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原有的格式。

发布公告

此版本标志着一次重大进展：在最初构思六年多之后，In‑Place Pod Resize 功能（亦称 In‑Place Pod Vertical Scaling），最初在 Kubernetes v1.27 中以 alpha 形式引入，并在 Kubernetes v1.33 中升级为 beta，现已在 Kubernetes v1.35 中达到 stable (GA)！

此升级是提升在 Kubernetes 上运行的工作负载资源效率和灵活性的重大里程碑。

Source: …

就地 Pod 大小调整

历史上，Pod 中容器定义的 CPU 和内存资源是 不可变 的。
更改这些资源需要删除并重新创建整个 Pod——这对以下场景是破坏性的：

  • 有状态服务
  • 批处理作业
  • 对延迟敏感的工作负载

就地 Pod 大小调整 使 CPU 和内存的 请求 与 限制 可变，允许在 Pod 运行时调整这些资源，通常无需重启容器。

关键概念

概念描述
期望资源spec.containers[*].resources 字段现在表示容器的 期望 资源。CPU 和内存的这些字段是可变的。
实际资源status.containerStatuses[*].resources 字段显示当前正在运行的容器已配置的 实际 资源。
触发大小调整通过 resize 子资源 更新 Pod 规范中的期望 requests 和 limits。Kubernetes 将调和该更改并就地应用。

如何执行就地大小调整

  1. 编辑 Pod 规范（或使用 kubectl patch / kubectl apply）修改 spec.containers 下的 resources 部分。

    spec:
  containers:
  - name: my-app
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "1"
        memory: "512Mi"

  2. 提交大小调整请求，使用 resize 子资源：

    kubectl replace --subresource=resize -f pod-resize.yaml

  3. 验证更改：

    kubectl get pod -o jsonpath='{.status.containerStatuses[*].resources}'

好处

  • 对资源密集型工作负载实现 零停机时间更新。
  • 更快的性能调优迭代。
  • 降低运维开销——无需为简单的扩缩容删除/重新创建 Pod。

就地 Pod 大小调整 已成为近期 Kubernetes 发行版的标准特性，为生产工作负载提供了更灵活、响应更快的资源管理方式。

如何开始使用就地 Pod 调整大小？

提供了详细的使用说明和示例，请参阅官方文档：

Resize CPU and Memory Resources assigned to Containers

这对我有什么帮助？

就地 Pod 调整是一个基础构建块，可实现无缝的垂直自动伸缩并提升工作负载效率。

好处

  • 资源在不中断的情况下调整
    对延迟或重启敏感的工作负载可以就地修改资源，避免停机或状态丢失。

  • 更强大的自动伸缩
    自动伸缩器现在可以在更小的影响下调整资源。例如，已升级至 beta 的垂直 Pod 自动伸缩器（VPA）InPlaceOrRecreate 更新模式即利用此功能，根据使用情况自动且无缝地调整 Pod 大小。

    查看 AEP‑4016 enhancement 了解详情。

  • 满足瞬时资源需求
    临时需要更多资源的工作负载可以快速调整。这支持 CPU 启动加速（AEP‑7862）等特性，应用在启动期间请求额外 CPU，随后自动缩减。

示例使用场景

  • 随玩家数量变化而扩缩的游戏服务器。
  • 预热的工作者在空闲时收缩，在首次请求时膨胀。
  • 用于高效 bin‑packing 工作负载的动态伸缩。
  • 启动期间进行即时（JIT）编译时临时增加资源。

Beta（1.33）与 Stable（1.35）之间的更改

自 v1.33 的最初 beta 以来，开发工作主要集中在对该特性进行稳定化并根据社区反馈提升可用性。以下是稳定版 v1.35 中引入的主要改动。

1. 内存限制降低

  • 之前，禁止降低内存限制。
  • 该限制已解除；现在允许降低内存限制。
  • Kubelet 将尝试通过仅在当前内存使用量低于新期望限制时才允许调整大小，从而防止 OOM‑kill。
  • 注意： 此检查为尽力而为，不能保证一定生效。

2. 优先级调整

当节点没有足够空间满足所有调整请求时，Deferred（延迟）调整会按照以下优先级顺序重新尝试：

  1. PriorityClass
  2. QoS 类别
  3. Deferred 状态的持续时间 —— 较早的请求优先处理。

3. Pod 级别资源（Alpha）

  • 原位 Pod Resize 现在支持 Pod Level Resources（Pod 级别资源）。
  • 此功能受特性标记控制，在 v1.35 中为 alpha 版本。

4. 可观测性提升

  • 为 In‑Place Pod Resize 新增了 Kubelet 指标和 Pod 事件。
  • 这些增强帮助用户更有效地跟踪和调试资源变更。

接下来是什么？

In‑Place Pod Resize 正式升级为 stable，为 Kubernetes 生态系统中的强大集成打开了大门。目前已计划多项后续改进。

与自动伸缩器及其他项目的集成

计划中的与自动伸缩器及相关项目的集成旨在提升大规模工作负载的效率。正在讨论的项目包括：

  • VPA CPU 启动加速 – AEP‑7862
    允许应用在启动时请求更多 CPU，并在特定时间后缩减回去。

  • VPA 对原地更新的支持 – AEP‑4016
    InPlaceOrRecreate 支持已升至 beta；目标是将该特性升级为 stable。对纯 InPlace 模式的支持仍在进行中（参见 PR #8818）。

  • Ray 自动伸缩器 – 计划利用 In‑Place Pod Resize 提升工作负载效率。详情请参阅 Google Cloud 博客文章。

  • Agent‑sandbox “软暂停” – 正在研究使用 In‑Place Pod Resize 来降低延迟。参见 GitHub issue。

  • 运行时支持 – Java 和 Python 运行时目前无法在不重启的情况下调整内存。与 Java 开发者的公开讨论正在进行中（参见 JDK bug）。

如果您的项目可以从与 In‑Place Pod Resize 的集成中受益，请通过 Feedback 部分列出的渠道联系我们。

功能扩展

目前，使用 In‑Place Pod Resize 时被禁止的情况包括：

  • Swap
  • 静态 CPU Manager
  • 静态 Memory Manager

CPU 与内存之外的资源仍保持不可变。随着社区反馈的收集，正在考虑扩展支持的特性和资源集合。

未来计划还包括 工作负载抢占：当高优先级 Pod 因节点容量不足而无法调整大小时，策略可以自动驱逐低优先级 Pod 或对节点进行扩容。

稳定性提升

  • 解决 kubelet‑scheduler 竞争条件
    已知的 kubelet 与 scheduler 之间的竞争条件会影响 In‑Place Pod Resize。相关工作正在进行中，预计在后续发行版中解决。参见 issue #126891。

  • 更安全的内存限制下降
    通过将内存使用检查移至容器运行时本身，可使 kubelet 的最佳努力 OOM‑kill 防护机制更安全。参见 issue #135670。

提供反馈

如果您想帮助改进和扩展此功能，欢迎提供您的意见！

  • GitHub: 在相关仓库中打开 issue。

  • 邮件列表: 在适当的 Kubernetes 邮件列表上分享您的想法。

  • Slack: 加入 Kubernetes 社区的讨论：

感谢所有为实现这一期待已久的功能做出贡献的人！

Back to Blog

相关文章

阅读更多 »