GKE预览VPA与HPA协同调优：副本数和CPU请求一起调整，先观察完整流量周期
2026年10月2日，Google Cloud宣布GKE的HPA rightsizing with VPA进入公开预览。在1.36.3-gke.1630000及以上版本的集群中，Vertical Pod Autoscaler（VPA）可以配合基于CPU利用率的Horizontal Pod Autoscaler（HPA），自动优化容器CPU请求，同时由HPA调整副本数量。
配图为AI生成的概念插图，表现容器副本数量与单个容器CPU资源的协同调整，不是真实监控界面。
为什么两个伸缩器需要专门协同
HPA关心要运行多少份Pod，VPA关心每份Pod应申请多少资源。困难在于，基于CPU利用率的HPA使用CPU请求量作为计算基线；如果VPA独立修改这个基线，HPA读到的利用率也会变化，即使实际CPU消耗并未同步改变。
举一个仅用于解释的例子：容器使用100m CPU、请求200m时，利用率为50%；若请求降为100m而实际使用保持不变，利用率就变成100%。这不代表流量翻倍，却可能影响HPA的副本判断。因此，把两个控制器都打开，不等于自然形成稳定的联合优化。
此次GKE逻辑让HPA继续应对短期流量变化，VPA则结合整体历史资源需求，并考虑HPA的最小副本数、最大副本数及目标CPU利用率来调整请求。它解决的是长期容量基线与短期副本变化之间的协调，而非给所有工作负载统一套上更小的CPU配置。
开启前需要满足的范围
官方指南同时覆盖Autopilot与Standard。Autopilot默认启用垂直自动伸缩，Standard需要显式启用；两者都要满足本次功能要求的版本。新的rightsizing计算只适用于CPU，如果VPA同时管理内存，内存仍按标准VPA逻辑调整。
当前限制为单集群所有工作负载合计最多60000个容器，单个VPA对象最多面向1000个容器。这里计数的是容器，包含多容器Pod带来的数量差异，不能简单用Pod数代替。大规模平台在试点前应先按真实模板与最大副本规模统计。
配置还需要专门的rightsizing策略注解，而不是仅创建一个普通VPA对象。官方使用gke.io/autoscaling-hpa-rightsizing-mode，值为gke-hpa-rightsizing-mode-policy。建议把版本、集群开关、对象注解和目标工作负载四项一起核对，避免“已有VPA”被误认为“已启用协同”。
先观察，再允许自动更新
官方建议生产工作负载先将VPA的updateMode设为Off，只生成建议，不修改运行中的Pod。初始建议可在几分钟内出现，但为了覆盖流量周期，应观察至少24小时到数天，再评估是否转为InPlaceOrRecreate或Recreate。
这段观察期应包括业务的低峰、高峰和批处理时间。如果服务周末几乎空闲，只凭周末数据就降低工作日资源基线，验收证据会不完整。建议同时比较尾延迟、错误率、CPU节流、期望副本数和实际就绪副本数，不把“请求总量下降”当作唯一成功指标。
容器策略中的minAllowed与maxAllowed可以设置资源边界。对关键服务，应结合已知的最低处理能力和节点容量设定上下限，并审查Uncapped Target与最终Target的差异。若原始建议长期超出限制，说明限制正在约束结果，需要理解原因，而不是只看最终数字似乎稳定。
原地调整也有需要重建的情况
InPlaceOrRecreate会尝试原地调整资源，减少重启带来的扰动；它的名称已经保留了重建路径。GKE的VPA说明列出节点容量不足、QoS类别变化、指定RestartContainer策略或调整长时间挂起等回退情况。因此，业务仍需要可接受的中断策略和容量余量。
如果同时调整内存，还要核对应用运行时是否需要重启才能采用新内存配置。官方允许通过容器resizePolicy指定相关行为。对缓存、连接池或启动较慢的服务，资源更新的影响不仅是一个CPU数字，也包括更新期间能否维持足够的就绪实例。
多容器Pod还有一个容易忽略的问题：边车的CPU使用可能干扰对主业务容器的判断。官方建议使用ContainerResource指标，让HPA根据主容器CPU利用率伸缩，使两个控制器基于同一个容器观察需求。上线前应确认容器名称和监控口径一致。
降低资源请求，怎样才会降低费用
GKE定价区分不同运行方式。通用Autopilot工作负载按Pod请求的CPU、内存与临时存储计费，因此合理降低请求量可能直接影响计算费用，但仍受最低资源和CPU内存比例要求约束。选择特定硬件的Autopilot工作负载则采用节点计费，需要另行评估。
Standard节点池按底层Compute Engine实例计费，直到节点被删除。由此可以推导出：VPA减少请求但节点数量和规格未变时，释放的是调度容量，账单未必立即下降；只有结合实际节点利用和扩缩结果，才能确认节省是否落地。此次公告没有给出适用于所有集群的节省比例。
适合怎样开始试点
优先选择CPU指标能反映业务负载、流量有规律、回滚方便的服务，从Off模式积累证据，再逐步开放自动调整。此次功能针对持续运行阶段的资源匹配，与启动时临时提高CPU的startup boost是不同问题。把两类需求分开测量，才能判断改进来自更快启动、更多副本，还是更合理的长期请求量。
官方资料
资料核对：2026年10月3日。版本、开放范围与费用以官方后续更新为准。
