HPA与VPA自动伸缩实战（应对流量洪峰的弹性方案）

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 AdapterVPA Controller需单独部署二、HPA 实战水平伸缩应对流量1. 前置依赖部署 Metrics Serverkubectl 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/v1kind: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 podpod-name-ojsonpath{.spec.containers[0].resources}四、HPA VPA 联合部署1. 联合架构与顺序VPA 先跑 → 校准单 Pod 资源 → HPA 再根据资源/自定义指标扩缩副本⚠️ 冲突规避VPA 用 Initial/Off 模式避免与 HPA 同时修改资源导致抖动。2. 联合配置示例# 1. 先部署VPAInitial模式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解决节点资源不足导致的 Pending2. VPA 避坑❌ 生产不要用 Auto 模式改核心服务避免意外重启❌ 不要限制 minAllowed 过低可能导致 OOM✅ 先观察 1~2 天推荐值再固定资源配置提升稳定性✅ 结合监控跟踪 VPA 推荐值与实际使用的差距3. 全链路弹性组合业务流量 → HPA(扩缩Pod) → VPA(校准单Pod资源) → Cluster Autoscaler(扩容节点)六、常用命令速查# HPAkubectl get hpa-Akubectl delete hpahpa-name# VPAkubectl get vpa-Akubectl describe vpavpa-namekubectl delete vpavpa-name# 观察扩缩容kubectl get deployment-wkubectl get pods-w七、总结HPA解决“流量洪峰”保证服务可用是弹性的“骨架”VPA解决“资源浪费”提升集群利用率是弹性的“血肉”生产组合VPA Initial HPA Cluster Autoscaler兼顾稳定与成本