详解K8s 1.33原地扩缩容功能：原理、实践、局限与发展

你是否有过这样的经历？
精心配置了 Kubernetes 的 Pod，设置了“刚刚好”的 CPU 和内存（至少你当时是这么想的），结果应用不是资源紧张喘不过气，就是像“双十一”抢购一样疯狂抢占资源。
过去，唯一的解决办法就是重启****整个 Pod ——这种破坏性的做法就像用黄油刀做开胸手术，而 SRE 团队正透过手术室的窗户盯着看，紧张但无能为力。
不过，近期发布的 Kubernetes 1.33 版本带来了我们梦寐以求的功能：原地 Pod 垂直伸缩（In-place Pod Vertical Scaling）。
在 Kubernetes 1.33 中该功能已升级为 Beta 版，并且默认启用。你不再需要手动启用特性，这使得它在生产环境中更加易用（可查阅 Kubernetes 官方文档：https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/）。
这意味着你可以调整正在运行的 Pod 的 CPU 和内存配置，而无需****重启。
如果你一直在琢磨垂直自动伸缩（VPA）的细节，那么这次更新会令人格外兴奋——虽然 VPA 的“重新创建”模式在理论上很美好，但实操过程中常常状况百出。
原地 Pod 垂直伸缩提供了一种更加优雅的资源调整方式，或许能让 VPA 的体验更加顺滑。
01/为什么这项更新如此重要？

对 Kubernetes 用户来说，这是一项革新式的重要更新。
假设当应用突然遇到流量激增的高峰期时，过去的做法是要么预留大量资源，但成本很高；要么触发 VPA 更新，导致 Pod 重启。而现在，通过这项更新可以直接实时增加 CPU 和内存配置，不会造成应用卡顿，用户侧几乎无感。
尤其对于那些有状态应用、数据库，或要求持续可用性的服务而言，原地扩缩容能大幅降低宕机时间，提供更加无缝的弹性伸缩体验。
为什么这项特性能实现这一效果？让我们来简单分析一下：

• 告别 Pod 重启 过去每次调整资源，服务是否宕机全看运气。VPA 会像一个过于热情的保安一样把 Pod 赶下线。现在呢？扩容丝滑得像咖啡师拉花。
  
• 成本优化魔法 不再需要为了“以防万一”的情况，而过度配置资源。
  

正如 Sysdig 团队指出的，这实现了真正的按需付费云经济。

• 拯救有状态工作负载 数据库不再需要在“性能”与“可用性”之间做选择了。这就像在行驶的汽车上换轮胎 ——虽然有风险，但现在已经可行！
  

02/实际应用场景

以下是一些具体的应用场景，从中可以窥见这一功能的实用性：

• 数据库工作负载 当你的 PostgreSQL 实例突然需要更多 RAM 来处理营销部门的数据分析的请求时，你可以在不中断正在进行的交易或清空连接池的情况下扩展资源。用户再也不会看到“请稍后再试”的消息了！
  
• Node.js API 服务 Node.js 应用可以在无需重启的情况下动态使用新增的 CPU 和内存。因此非常适合使用原地扩缩容来应对流量激增。
  
• 机器学习****推理服务 TensorFlow Serving 等服务在处理更大批量或更复杂模型时，可以实时扩容，无需中断正在进行的推理请求。
  
• 服务网格 Sidecar 在 Istio 之类的服务网格中， Envoy 代理现在可以根据流量模式动态调整资源，而不会干扰主应用容器的运行。
  

关于 Java 应用的提醒：
对于基于 JVM 的应用，仅仅调整 Pod 的内存配置并不会自动改变 JVM 的堆（heap）大小，后者通常是在启动时通过-Xmx等参数设置的。虽然原地 Pod 调整可以优化非堆内存和 CPU 资源的使用，但如果想要充分利用扩容后的内存限制，Java应用通常需要调整配置并重启。因此，对于不希望重启的场景来说，Java 应用并不适合进行内存扩容。

03/技术揭秘：Kubernetes 如何灵活调整资源

接下来，让我们深入探讨技术细节，下图展示了 K8s 资源调整的工作流程：

实际发生了什么

• 可变资源字段已支持动态更新 得益于这个 issue （https://github.com/kubernetes/enhancements/issues/1287），Pod 规范中的resources.requests 和 resources.limits 字段现在支持动态修改，无需再为 Spec 是否不可变而争论了。
  
• Kubelet 的评估机制 当你提交 patch 时，kubelet 会评估：
  

(节点可用资源总量) - (当前所有容器资源分配总和) ≥ (新请求资源)？
满足条件就允许变更，否则就返回 PodResizePending。

• CRI 协议握手 kubelet 会通过容器运行时接口 (CRI) 与 containerd 或 CRI-O 通信：“给这个容器加点资源”。运行时随后会调整对应的 cgroup，无需重启，轻松搞定。这是异步、非阻塞的流程，Kubelet 可以在处理资源调整的同时继续执行其他重要任务。
  
• 状态更新提示 在执行kubectl describe pod时，你会看到两个新状态：
  

• PodResizePending —— “节点当前资源不足，稍后再试。”
  
• PodResizeInProgress —— “正在处理，资源调整中。”
  

容器运行时兼容性

这一功能在不同的容器运行时中均可使用，但支持程度有差异，情况如下：

• containerd（v1.6+）：完全支持，可以平滑调整 CPU 和内存的 cgroup
  
• CRI-O（v1.24+）：完全支持原地扩缩容
  
• Docker：支持有限，因为它正在逐步退出 Kubernetes
  

注意：cgroup v2 在内存回收方面比 cgroup v1 更强大，特别是对于内存限制减少的情况下。

04/上手实践：安全地搞点事情
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！