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
bash
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 验证
kubectl get deployment metrics-server -n kube-system2. 完整 HPA 配置（autoscaling/v2）
yaml
# hpa-demo.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app-demo
minReplicas: 2 # 最小副本
maxReplicas: 10 # 最大副本
behavior: # 防抖动配置（生产必加）
scaleUp:
stabilizationWindowSeconds: 60 # 稳定窗口60秒
policies:
- type: Percent
value: 50
periodSeconds: 60 # 60秒内最多扩容50%
scaleDown:
stabilizationWindowSeconds: 300 # 缩容稳定窗口5分钟
policies:
- type: Percent
value: 20
periodSeconds: 60
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # CPU目标利用率70%
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80 # 内存目标利用率80%3. 应用与验证
bash
# 应用
kubectl apply -f hpa-demo.yaml
# 查看状态
kubectl get hpa app-hpa
# 观察扩容/缩容
kubectl get hpa app-hpa -w4. 高级：基于自定义指标（QPS/队列长度）
需部署 Prometheus + Prometheus Adapter，示例：
yaml
metrics:
- type: Pods
pods:
metric:
name: http_requests_per_second # 自定义QPS指标
target:
type: AverageValue
averageValue: 1000m # 单Pod平均QPS阈值1000三、VPA 实战：垂直伸缩（资源调优）
1. 部署 VPA 组件
bash
# 国内镜像加速版
kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/vertical-pod-autoscaler/hack/vpa-up.yaml
# 验证
kubectl get deployment -n kube-system | grep vpa2. VPA 四种更新模式（关键）
| 模式 | 行为 | 是否重启 Pod | 适用场景 |
|---|---|---|---|
| Auto | 自动调整 Requests/Limits，逐出重建 | 是 | 非核心服务、可容忍短暂中断 |
| Recreate | 同 Auto，但强制重建 Pod（不使用就地更新） | 是 | 依赖就地更新不生效的场景 |
| Initial | 仅在 Pod 启动时推荐初始资源，后续不调整 | 否（启动时） | 核心服务、避免重启影响可用性 |
| Off | 仅生成推荐值，不修改资源 | 否 | 资源调优观察、不自动干预 |
3. 完整 VPA 配置
yaml
# vpa-demo.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: app-vpa
namespace: default
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: app-demo
updatePolicy:
updateMode: "Initial" # 生产核心服务建议用Initial
resourcePolicy:
containerPolicies:
- containerName: '*'
minAllowed:
cpu: 100m
memory: 128Mi
maxAllowed:
cpu: 4
memory: 8Gi
controlledResources: ["cpu", "memory"]4. 查看推荐值与效果
bash
# 查看VPA状态
kubectl get vpa app-vpa -o yaml
# 查看Pod资源配置是否被更新
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'四、HPA + VPA 联合部署
1. 联合架构与顺序
VPA 先跑 → 校准单 Pod 资源 → HPA 再根据资源/自定义指标扩缩副本
⚠️ 冲突规避：VPA 用 Initial/Off 模式，避免与 HPA 同时修改资源导致抖动。
2. 联合配置示例
yaml
# 1. 先部署VPA（Initial模式）
kubectl apply -f vpa-demo.yaml
# 2. 再部署HPA
kubectl 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(扩容节点)六、常用命令速查
bash
# HPA
kubectl get hpa -A
kubectl delete hpa <hpa-name>
# VPA
kubectl get vpa -A
kubectl describe vpa <vpa-name>
kubectl delete vpa <vpa-name>
# 观察扩缩容
kubectl get deployment -w
kubectl get pods -w七、总结
- HPA：解决"流量洪峰"，保证服务可用，是弹性的"骨架"
- VPA：解决"资源浪费"，提升集群利用率，是弹性的"血肉"
- 生产组合：VPA Initial + HPA + Cluster Autoscaler，兼顾稳定与成本