两套伸缩怎么配合
HPA 调副本数，VPA 调单个副本的资源请求，两者作用方向互相垂直，所以可以组队，但必须分工明确。常见做法是：HPA 按业务指标或 CPU 扩副本，VPA 用「只出建议」的模式产出 requests 参考值，交由人工或流水线修订清单。如果让两者都自动调整，就会出现请求变化影响利用率百分比、进而牵动副本数的连锁反应，扩缩动作很难解释。
基本信息
| 适用场景 | 同时具备横向与纵向自动伸缩能力的集群 |
|---|---|
| HPA 维度 | 副本数，按指标计算期望值 |
| VPA 维度 | 单副本的 requests 与 limits |
| 推荐组合 | HPA 自动扩副本，VPA 只输出建议 |
| 冲突根源 | 请求变化会改变利用率的分母口径 |
典型使用场景
- 流量波动明显的服务：副本随负载横向伸缩，资源请求保持稳定
- 资源画像不清的服务：先用 VPA 建议校准 requests，再决定副本策略
- 容量治理：定期根据建议值修订声明，避免长期超配
- 成本优化：结合两者数据判断该扩副本还是该加资源
- 故障复盘：同时查看两套对象状态，判断扩缩动作是否互相干扰
推荐组合（说明性配置）
推荐组合（说明性配置）
# HPA：按业务指标扩副本（例如每秒请求数）
# metrics: 使用 Pods 或 External 类型指标
# VPA：updateMode 设为 Off，只产出 requests 建议
# 建议值经评审后写回清单，由发布流程生效
# 不推荐：自动 VPA 与按 CPU 的 HPA 同时开启
# 请求变化会改变利用率口径，扩缩动作随之被动漂移核对两边状态
核对两边状态
kubectl get vpa,hpa -n prod
kubectl describe hpa web-hpa -n prod | grep -i current
kubectl get vpa api-vpa -n prod -o jsonpath='{.status.recommendation.containerRecommendations}'
kubectl top pod -l app=web -n prod --containers组合方式与建议
| 组合方式 | 行为 | 建议 |
|---|---|---|
| HPA 自动 + VPA 建议模式 | 副本按负载变化，请求按建议人工调整 | 推荐做法 |
| HPA 自动 + VPA 自动 | 请求与副本互相牵动 | 一般不推荐 |
| 仅 HPA | 副本弹性、请求固定 | 资源画像稳定时够用 |
| 仅 VPA | 请求随用量调整 | 无并发弹性需求时适用 |
两套机制一起上线前先在非生产环境观察一段时间：联动关系需要真实负载数据才能看清，靠推断容易得出错误结论。
分别看两个对象都可能显示正常，问题往往出在口径交互上，因此排障时要同时查看两侧的状态与历史变化。