Kubernetes v1.33：Pod 原地调整大小功能进阶至 Beta

作者：Tim Allclair (Google) |

我谨代表 Kubernetes 项目，激动地宣布，最初在 Kubernetes v1.27 中作为 Alpha 功能引入的 Pod 原地调整大小（in-place Pod resize）功能（也称为原地 Pod 垂直扩缩），已升级至 Beta 阶段，并将在 Kubernetes v1.33 版本中默认启用！这标志着在使 Kubernetes 工作负载的资源管理更灵活、干扰更小方面，我们取得了重要的里程碑。

什么是 Pod 原地调整大小？

传统上，更改分配给容器的 CPU 或内存资源需要重启 Pod。虽然这对于许多无状态应用来说是可以接受的，但对于有状态服务、批处理作业或任何对重启敏感的工作负载来说，这可能会造成中断。

Pod 原地调整大小允许你更改分配给一个正在运行的 Pod 内的容器的 CPU 和内存请求（requests）与限制（limits），通常无需重启容器。

核心理念如下

  • Pod 规范中的 spec.containers[*].resources 字段现在代表期望的资源，并且对于 CPU 和内存是可变的。
  • status.containerStatuses[*].resources 字段反映了当前在一个运行中容器上配置的实际资源。
  • 你可以通过新的 resize 子资源更新 Pod 规范中的期望资源来触发调整大小操作。

你可以在 v1.33 的 Kubernetes 集群上，使用 kubectl 编辑一个 Pod 来尝试此功能（需要 kubectl v1.32+ 版本）。

kubectl edit pod <pod-name> --subresource resize

有关详细的使用说明和示例，请参阅 Kubernetes 官方文档：调整分配给容器的 CPU 和内存资源。

为什么 Pod 原地调整大小很重要？

Kubernetes 在水平扩展工作负载（增加或减少副本）方面仍然表现出色，但 Pod 原地调整大小为垂直扩展解锁了几个关键优势：

  • 减少中断： 有状态应用、长时间运行的批处理作业和敏感工作负载可以在不遭受与 Pod 重启相关的停机或状态丢失的情况下调整其资源。
  • 提高资源利用率： 在不中断的情况下，缩减配置过度的 Pod，从而释放集群中的资源。反之，为负载较重的 Pod 提供更多资源，而无需重启。
  • 更快的扩展速度： 更迅速地应对临时的资源需求。例如，Java 应用在启动时通常比在稳定状态下需要更多的 CPU。可以从较高的 CPU 开始，之后再调低。

从 Alpha 到 Beta 有哪些变化？

自 v1.27 的 Alpha 版本发布以来，我们投入了大量工作来使该功能成熟，提高其稳定性，并根据反馈和进一步开发来完善用户体验。以下是主要变化：

显著的面向用户的变化

  • resize 子资源： 修改 Pod 资源现在必须通过 Pod 的 resize 子资源来完成 (kubectl patch pod <name> --subresource resize ...)。kubectl v1.32+ 版本支持此参数。
  • 通过 Conditions 反映调整状态： 旧的 status.resize 字段已被弃用。调整大小操作的状态现在通过两个 Pod Conditions 公开：
    • PodResizePending：表示 Kubelet 无法立即批准调整大小（例如，reason: Deferred 表示暂时无法，reason: Infeasible 表示在节点上不可能）。
    • PodResizeInProgress：表示调整大小已被接受并正在应用。在此阶段遇到的错误现在会在此 Condition 的消息中报告，并带有 reason: Error。
  • Sidecar 支持： 现在支持原地调整 Sidecar 容器。

稳定性和可靠性增强

  • 精炼的已分配资源管理： Kubelet 的分配管理逻辑进行了重大重构，使其更加一致和健壮。这些更改消除了整类的错误，并大大提高了 Pod 原地调整大小的可靠性。
  • 改进的检查点和状态跟踪： 实现了一个更强大的系统来跟踪“已分配（allocated）”和“已驱动（actuated）”的资源，使用新的检查点文件（allocated_pods_state, actuated_pods_state）来可靠地管理跨 Kubelet 重启的调整大小状态，并处理运行时报告的资源与请求资源不符的边缘情况。修复了与检查点和状态恢复相关的几个错误。检查点的效率也得到了提高。
  • 更快的调整大小检测： Kubelet 的 Pod 生命周期事件生成器（PLEG）的增强功能使 Kubelet 能够更快地响应和完成调整大小操作。
  • 增强的 CRI 集成： 新增了 UpdatePodSandboxResources CRI 调用，以便更好地通知运行时和插件（如 NRI）关于 Pod 级资源的变化。
  • 大量的 Bug 修复： 解决了与 systemd cgroup 驱动程序、无限制容器的处理、CPU 最小份额计算、容器重启退避、错误传播、测试稳定性等相关的问题。

接下来是什么？

进入 Beta 阶段意味着该功能已准备好进行更广泛的采用，但开发并未就此停止！以下是社区下一步关注的重点：

  • 稳定性和生产化： 继续专注于加固功能，提高性能，并确保其在生产环境中足够健壮。
  • 解决限制： 努力放宽文档中提到的一些当前限制，例如允许减少内存限制。
  • VerticalPodAutoscaler (VPA) 集成： 使 VPA 能够利用 Pod 原地调整大小的工作已经在进行中。一个新的 InPlaceOrRecreate 更新模式将允许它首先尝试非破坏性的调整大小，如果需要，则回退到重新创建。这将使用户能够从 VPA 的建议中受益，同时显著减少中断。
  • 用户反馈： 收集采用 Beta 功能的用户的反馈对于优先考虑进一步的增强和解决任何发现的问题或错误至关重要。

开始使用并提供反馈

由于 InPlacePodVerticalScaling 特性门控在 v1.33 中默认启用，你可以立即开始体验 Pod 原地调整大小！

请参阅文档以获取详细的指南和示例。

随着此功能进入 Beta 阶段，你的反馈非常宝贵。请通过标准的 Kubernetes 沟通渠道（GitHub issues、邮件列表、Slack）报告任何问题或分享你的经验。你也可以查阅 KEP-1287：原地更新 Pod 资源以了解完整深入的设计细节。

我们期待看到社区如何利用 Pod 原地调整大小来在 Kubernetes 上构建更高效、更有弹性的应用程序！