Pod原地扩缩容GA：Kubernetes 1.35支持有状态服务资源动态调整

Kubernetes 1.35 版本中，一个备受瞩目的功能——Pod 原地扩缩容 (In-Place Pod Resize) 正式升级为稳定版 (GA)。这项功能允许您直接调整运行中 Pod 的 CPU 和内存资源请求与限制，而无需重启 Pod 或其容器，极大地提升了资源管理的灵活性与应用效率。

该功能的发展历程跨越了六年：它最初在 Kubernetes v1.27 作为 Alpha 功能引入，在 v1.33 进入 Beta 阶段，如今在 v1.35 中达到生产就绪的稳定状态，标志着 Kubernetes 在提升工作负载资源效率方面迈出了关键一步。

功能解析：什么是 Pod 原地扩缩容？

在过去，Pod 中容器的资源定义 (requests 和 limits) 一经创建便无法更改。若需调整资源，唯一的办法是删除并重建整个 Pod。对于数据库、有状态服务或对延迟敏感的在线业务而言，这种操作带来的中断是不可接受的。

Pod 原地扩缩容功能改变了这一现状，它使 CPU 和内存资源变为可变字段。核心概念包括：

• 期望资源：由 spec.containers
• .resources 定义，现在可以动态更新。
• 实际资源：由 status.containerStatuses
• .resources 反映，表示容器当前实际使用的资源。
• 触发方式：通过更新 Pod 规约中的资源字段或调用新的 resize 子资源来发起调整请求。

如何使用此功能？

具体的操作指南和 YAML 示例，请参考 Kubernetes 官方文档：调整分配给容器的 CPU 和内存资源。

核心价值与应用场景

该功能是构建高效、弹性应用架构的基础模块，主要带来以下优势：

1. 实现无中断运维：对重启敏感的有状态服务可以在不丢失连接或状态的情况下，直接调整资源配额。
2. 赋能智能弹性伸缩：它为自动扩缩器提供了更精细的操作手段。例如，垂直 Pod 自动扩缩器 (VPA) 的 InPlaceOrRecreate 更新模式（基于此功能）已进入 Beta 阶段，能根据监控指标自动、平滑地调整资源，最小化对业务的影响。这正是在 运维/DevOps 实践中追求的目标。
3. 满足瞬时资源需求：工作负载可以临时“借用”更多资源以应对峰值。例如，支持 CPU 启动加速 特性，让应用在启动阶段获得更多CPU资源以快速完成初始化，随后再自动缩减。

典型应用场景包括：

• 在线游戏服务器根据实时玩家人数动态调整资源。
• 数据处理任务在空闲时缩容以节省成本，接收到新数据时快速扩容。
• Java 应用服务在启动后执行 JIT 编译时，临时增加 CPU 资源。

从 Beta (v1.33) 到 Stable (v1.35) 的改进

在 Beta 版基础上，v1.35 稳定版主要围绕稳定性与易用性进行了增强：

• 允许降低内存限制：此前禁止的操作现已放开。Kubelet 会尽力检查当前内存使用量，仅在低于新限制时才执行缩容，但这并非绝对保证。
• 引入调整优先级：当节点资源紧张时，延迟执行的扩缩容请求会依据 Pod 的 PriorityClass、QoS 等级和请求时间进行优先级排序。
• 增强可观测性：新增了 Kubelet 指标和 Pod 事件，帮助管理员更好地监控和调试资源调整过程。
• Alpha 支持 Pod 级资源：通过特性门控，新增了对 Pod 级别资源（而非容器级别）进行原地扩缩容的 Alpha 支持。

未来展望与生态整合

Pod 原地扩缩容达到稳定，为更广泛的 云原生/IaaS 生态集成铺平了道路。未来的工作重点包括：

• 深化与 VPA、HPA 及 Ray 等项目的集成，实现大规模工作负载的自动化资源优化。
• 扩展支持范围：计划解除与 Swap、静态资源管理器共用的限制，并探索支持 CPU 和内存之外的其他资源类型。
• 提升稳定性：着手解决 Kubelet 与调度器之间已知的竞态条件，并通过容器运行时层面的改进来增强内存缩容的安全性。值得注意的是，部分运行时（如某些 Java 版本）目前尚不支持不重启调整内存，相关改进正在与社区讨论中，这也是 Java 开发者可以关注的方向。

参与与反馈

欢迎社区用户通过 Kubernetes 项目的 GitHub Issue、邮件列表或 Slack 频道（如 #sig-node 和 #sig-autoscaling）分享您的使用体验和改进建议。