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

此次发布标志着重要的一步：在该功能最初构想提出 6 年多之后，In-Place Pod Resize 功能（亦称为 In-Place Pod Vertical Scaling）自 Kubernetes v1.27 作为 alpha 版本首次引入，并于 Kubernetes v1.33 晋升至 beta 版本，如今在 Kubernetes 1.35 中正式成为稳定版（GA）！

该功能正式进入稳定版是提升运行于 Kubernetes 上的工作负载资源效率与灵活性的重要里程碑。

什么是 In-Place Pod Resize？

过去，分配给 Pod 中容器的 CPU 和内存资源是不可变的。这意味着若要更改这些资源，必须删除并重新创建整个 Pod。对于有状态服务、批处理作业或对延迟敏感的工作负载而言，这是一种极具破坏性的操作。

In-Place Pod Resize 使 CPU 和内存的 requests 与 limits 变为可变，允许您在运行中的 Pod 内调整这些资源，且通常无需重启容器。

核心概念：

• 期望资源：容器的 spec.containers[*].resources 字段现代表期望资源。对于 CPU 和内存，这些字段现已变为可变。
• 实际资源：status.containerStatuses[*].resources 字段反映了当前为运行中容器配置的资源。
• 触发资源调整：您可以利用新增的 resize 子资源，通过更新 Pod 规范中期望的 requests 和 limits 来发起调整请求。

如何开始使用原地 Pod 调整大小（In-place Pod Resize）？

官方文档提供了详细的使用说明与示例：调整分配给容器的 CPU 和内存资源（Resize CPU and Memory Resources assigned to Containers）。

这能为我带来什么帮助？

原地 Pod 调整大小是一项基础构建块，能够实现无缝的垂直自动扩缩容并提升工作负载效率。

• 无中断调整资源：对延迟或重启敏感的工作负载可以在原地进行资源修改，且不会导致停机或状态丢失。
• 更强大的自动扩缩容：自动扩缩器现已能够调整资源且影响更小。例如，基于此特性实现的 Vertical Pod Autoscaler (VPA) 的 InPlaceOrRecreate 更新模式已晋升至 Beta 阶段。该功能支持根据实际使用情况自动、无缝地调整资源，并将干扰降至最低。更多详情请参阅 AEP-4016。
• 满足瞬时资源需求。对于暂时需要更多资源的工作负载，可快速进行调整。这使得 CPU Startup Boost（AEP-7862）等特性成为可能，应用可在启动期间请求更多 CPU，随后自动缩减。

以下是部分使用场景示例：

• 需要根据玩家数量波动动态调整规模的游戏服务器。
• 预先预热的工作节点，闲置时可缩小规模，在接收到首个请求时可迅速扩容。
• 根据负载动态伸缩，以实现高效的 bin-packing。
• 在启动时为 JIT 编译分配更多资源。

Beta（1.33）与 Stable（1.35）版本之间的变更

自 v1.33 推出初始 Beta 版以来，开发工作主要致力于稳定该功能，并根据社区反馈提升其易用性。以下是 Stable 版本的主要变更：

• 内存限制调低 此前禁止降低内存限制。该限制现已解除，允许调低内存限制。为防止发生 OOM-kills，Kubelet 仅在当前内存使用量低于新的目标限制时才允许调整大小。但此检查为尽力而为，不作绝对保证。
• 优先级调整 若节点没有足够资源接收所有调整请求，Deferred 调整将按以下优先级重新尝试：PriorityClass、QoS 类别、Deferred 持续时间，且较早提交的请求优先处理。
• Pod 级资源（Alpha） 现已支持结合 Pod 级资源进行 In-Place Pod Resize。该功能由独立的特性门控控制，在 v1.35 版本中处于 Alpha 阶段。
• 可观测性提升：新增了专门与 In-Place Pod Resize 关联的 Kubelet 指标和 Pod 事件，旨在帮助用户追踪和调试资源变更。

下一步计划？

In-Place Pod Resize 晋升至稳定阶段，为 Kubernetes 生态系统内的深度集成打开了大门。目前已有多个方向的进一步优化计划正在推进中。

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

目前已计划与多款自动扩缩器及其他项目进行集成，旨在更大规模上提升工作负载效率。部分正在探讨的项目如下：

• VPA CPU 启动增强（AEP-7862）：允许应用程序在启动时请求更多 CPU，并在特定时间段后自动缩减。
• VPA 对原地更新的支持（AEP-4016）：VPA 对 InPlaceOrRecreate 的支持近期已晋升至 beta 阶段，最终目标是将该功能推向 stable 阶段。对 InPlace 模式的支持仍在开发中；请参阅此 pull request。
• Ray autoscaler：计划利用 In-Place Pod Resize 提升工作负载效率。请参阅此 Google Cloud 博客文章了解更多详情。
• Agent-sandbox “Soft-Pause”：正在探索利用 In-Place Pod Resize 以进一步优化延迟。请参阅此 Github issue 了解更多详情。
• 运行时支持：Java 和 Python 运行时不支持无需重启即可调整内存。目前正与 Java 开发者进行公开讨论，请参阅该 bug。

如果您的项目能够通过与 in-place pod resize 集成获益，请通过反馈部分列出的渠道与我们联系！

功能扩展

目前，In-Place Pod Resize 在结合以下组件使用时被禁止：swap、静态 CPU Manager 以及静态 Memory Manager。此外，除 CPU 和内存外的其他资源仍不可变。随着社区需求反馈的不断增多，我们正考虑扩大所支持的功能和资源范围。

此外，还计划支持工作负载抢占；如果节点上没有足够的空间用于调整高优先级 Pod 的规格，我们的目标是启用相关策略，以自动驱逐低优先级 Pod 或对节点进行扩容。

稳定性提升

• 解决 kubelet 与调度器之间的竞态条件。在 Pod 原地调整规格方面，kubelet 与调度器之间存在已知的竞态条件。我们正致力于在接下来的几个版本中解决这些问题。详情请参阅相关 Issue。
• 更安全地降低内存限制。通过将内存使用量检查直接移至容器运行时内部，可以进一步提升 Kubelet 防止 OOM-kill 的尽力检查机制的安全性。详情请参阅相关 Issue。

提供反馈

若希望在此基础特性之上进一步开发，欢迎分享您关于如何改进和扩展该特性的反馈。您可以通过 Kubernetes #sig-node 和 #sig-autoscaling 社区相关的 GitHub Issue、邮件列表或 Slack 频道提交反馈。

感谢所有为让这一期待已久的特性成为现实而做出贡献的开发者！

• ← 上一篇
• 下一步 →