Kubernetes VPA 的设计和实现

Thu, 23 Jul 2026 00:00:00 +0800

requests 决定 Pod 能否被调度，也影响节点的装箱密度和资源抢占时的保障。它写进 PodSpec 后通常不会自行变化，工作负载却会随着业务迭代、流量起伏、缓存预热和依赖延迟不断改变。完全靠人工维护一组固定值，很快就会出现偏差，进而影响集群的资源利用率和稳定性。

如果团队内无预算控制～那么恭喜你，已经解决了这个问题 🎉

VPA（Vertical Pod Autoscaler）会持续观察工作负载，为容器生成 CPU 和内存 recommendation，并根据策略决定是否应用到 Pod。本文关注 recommendation 怎样产生并作用到 Pod，以及生产接入前需要确认哪些限制。常用配置放在前面，便于后文说明各组件的行为。

版本说明

本文基于 VPA vertical-pod-autoscaler-1.7.0，对应源码 commit 6a616ea0c5ea0cb6111240073a9273b3467c064e。字段、默认值、更新模式和源码路径均以该版本为准。

1. VPA 解决什么问题#

Kubernetes 调度器根据 Pod 的 requests 判断节点是否有足够资源，它不会预测容器之后的真实用量。requests 因此会影响调度位置、节点装箱密度，以及资源抢占时的保障。

requests 过低时，节点可能被调度进过多 Pod，CPU 抢占和内存压力会在运行时才暴露；requests 过高时，Pod 会占用过多可调度容量，造成节点利用率下降、Pod Pending，甚至触发不必要的节点扩容。固定值还会随工作负载变化逐渐偏离实际需求。

假设一个订单服务最初为每个 Pod 配置了 200m CPU / 512Mi 的 requests。当时这个值能够覆盖日常用量；后来版本升级并启用了本地缓存，单副本的稳定用量升到约 600m CPU / 900Mi，requests 却没有同步调整。调度器仍按旧值为 Pod 选择节点，多个副本被放到同一节点后，实际总用量可能超过节点能够提供的资源，最终出现 CPU 争用和节点内存压力。配置本身没有变化，但它已经不再代表应用的真实需求。

如果单个 Pod 的 CPU、内存需求经常变化，人工又很难长期维护准确的 requests，就可以考虑 VPA。Recommender 根据历史用量和策略限制计算建议；Updater 与 Admission Controller 再按 updateMode 处理存量或新建 Pod。

资源管理 on Yeqown

Kubernetes VPA 的设计和实现

1. VPA 解决什么问题#