HPA 管“多少个 Pod”，VPA 管“每个 Pod 要多少资源”，二者互补可联合部署；核心是先 VPA 做资源校准，再 HPA 做副本弹性，配合 Cluster Autoscaler 实现从 Pod 到节点的全链路弹性。
一、核心对比：HPA vs VPA
| 维度 | HPA（水平伸缩） | VPA（垂直伸缩） |
|---|---|---|
| 伸缩对象 | Pod 副本数（增减实例） | 单 Pod 的 CPU/内存 Requests/Limits |
| 是否重启 Pod | 否 | Auto/Recreate 模式会重启；Initial/Off 不重启 |
| 核心指标 | CPU/内存、QPS、队列长度等自定义指标 | 历史资源使用量（推荐合理 Requests） |
| 适用场景 | 无状态、流量波动大（Web/API）、秒杀/直播 | 有状态、资源难预估、单体/数据库、降本增效 |
| 生产定位 | 应对流量洪峰，保证可用性 | 资源调优（Rightsizing），提升集群利用率 |
| 依赖组件 | Metrics Server / Prometheus Adapter | VPA Controller（需单独部署） |
二、HPA 实战：水平伸缩（应对流量）
1. 前置依赖：部署 Metrics Server
kubectl apply-fhttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml# 验证kubectl get deployment metrics-server-nkube-system2. 完整 HPA 配置（autoscaling/v2）
# hpa-demo.yamlapiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:app-hpanamespace:defaultspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:app-demominReplicas:2# 最小副本maxReplicas:10# 最大副本behavior:# 防抖动配置（生产必加）scaleUp:stabilizationWindowSeconds:60# 稳定窗口60秒policies:-type:Percentvalue:50periodSeconds:60# 60秒内最多扩容50%scaleDown:stabilizationWindowSeconds:300# 缩容稳定窗口5分钟policies:-type:Percentvalue:20periodSeconds:60metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70# CPU目标利用率70%-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80# 内存目标利用率80%3. 应用与验证
# 应用kubectl apply-fhpa-demo.yaml# 查看状态kubectl get hpa app-hpa# 观察扩容/缩容kubectl get hpa app-hpa-w4. 高级：基于自定义指标（QPS/队列长度）
需部署 Prometheus + Prometheus Adapter，示例：
metrics:-type:Podspods:metric:name:http_requests_per_second# 自定义QPS指标target:type:AverageValueaverageValue:1000m# 单Pod平均QPS阈值1000三、VPA 实战：垂直伸缩（资源调优）
1. 部署 VPA 组件
# 国内镜像加速版kubectl apply-fhttps://raw.githubusercontent.com/kubernetes/autoscaler/master/vertical-pod-autoscaler/hack/vpa-up.yaml# 验证kubectl get deployment-nkube-system|grepvpa2. VPA 四种更新模式（关键）
| 模式 | 行为 | 是否重启 Pod | 适用场景 |
|---|---|---|---|
| Auto | 自动调整 Requests/Limits，逐出重建 | 是 | 非核心服务、可容忍短暂中断 |
| Recreate | 同 Auto，但强制重建 Pod（不使用就地更新） | 是 | 依赖就地更新不生效的场景 |
| Initial | 仅在 Pod 启动时推荐初始资源，后续不调整 | 否（启动时） | 核心服务、避免重启影响可用性 |
| Off | 仅生成推荐值，不修改资源 | 否 | 资源调优观察、不自动干预 |
3. 完整 VPA 配置
# vpa-demo.yamlapiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:app-vpanamespace:defaultspec:targetRef:apiVersion:"apps/v1"kind:Deploymentname:app-demoupdatePolicy:updateMode:"Initial"# 生产核心服务建议用InitialresourcePolicy:containerPolicies:-containerName:'*'minAllowed:cpu:100mmemory:128MimaxAllowed:cpu:4memory:8GicontrolledResources:["cpu","memory"]4. 查看推荐值与效果
# 查看VPA状态kubectl get vpa app-vpa-oyaml# 查看Pod资源配置是否被更新kubectl get pod<pod-name>-ojsonpath='{.spec.containers[0].resources}'四、HPA + VPA 联合部署
1. 联合架构与顺序
VPA 先跑 → 校准单 Pod 资源 → HPA 再根据资源/自定义指标扩缩副本
⚠️ 冲突规避：VPA 用 Initial/Off 模式，避免与 HPA 同时修改资源导致抖动。
2. 联合配置示例
# 1. 先部署VPA（Initial模式）kubectl apply-f vpa-demo.yaml# 2. 再部署HPAkubectl apply-f hpa-demo.yaml3. 生产联合注意事项
- 核心服务用 VPA Initial 模式，仅启动时校准，避免重启
- 非核心服务用 VPA Auto 模式，自动调优
- HPA 务必配置 behavior 稳定窗口，防止频繁扩缩容
- 配合 Cluster Autoscaler：当 Pod 因资源不足无法调度时，自动扩容节点
五、生产避坑与最佳实践
1. HPA 避坑
- ❌ 不要只看 CPU：内存密集型服务必须加内存指标
- ❌ 避免阈值过低：70%~80% 是合理区间，过低导致频繁扩容
- ✅ 必加 behavior 稳定窗口：解决“抖动”问题
- ✅ 结合 Cluster Autoscaler：解决节点资源不足导致的 Pending
2. VPA 避坑
- ❌ 生产不要用 Auto 模式改核心服务：避免意外重启
- ❌ 不要限制 minAllowed 过低：可能导致 OOM
- ✅ 先观察 1~2 天推荐值：再固定资源配置，提升稳定性
- ✅ 结合监控：跟踪 VPA 推荐值与实际使用的差距
3. 全链路弹性组合
业务流量 → HPA(扩缩Pod) → VPA(校准单Pod资源) → Cluster Autoscaler(扩容节点)六、常用命令速查
# HPAkubectl get hpa-Akubectl delete hpa<hpa-name># VPAkubectl get vpa-Akubectl describe vpa<vpa-name>kubectl delete vpa<vpa-name># 观察扩缩容kubectl get deployment-wkubectl get pods-w七、总结
- HPA：解决“流量洪峰”，保证服务可用，是弹性的“骨架”
- VPA：解决“资源浪费”，提升集群利用率，是弹性的“血肉”
- 生产组合：VPA Initial + HPA + Cluster Autoscaler，兼顾稳定与成本
