1. 为什么非要用HPA不可从一次凌晨扩容事故说起先讲一段往事。某天凌晨两点半电话响了是值班同事打来的语气里压着焦虑线上某个核心服务的P99延迟已经从80ms飙到了2秒副本扛不住了。我睡眼惺忪地打开电脑看一眼监控CPU使用率接近饱和QPS还在涨。那个服务部署了6个副本请求量大概翻了一倍。手动扩容kubectl scale deployment一把梭3分钟内把副本拉到12流量分摊之后指标慢慢回落服务恢复了。人是醒了觉是没了这事却在我脑子里转了很久如果扩容这件事可以提前被规则发现、自动执行我们根本不需要在大半夜爬起来敲命令行。这就是HPAHorizontal Pod Autoscaler存在的意义。它的全称是水平Pod自动伸缩器隶属于Kubernetes的自动伸缩体系。它监控工作负载一般是Deployment或StatefulSet的资源使用指标当指标越过你设定的阈值时自动增加或减少Pod副本数。不需要你半夜爬起来不需要你盯着监控面板不需要你预判流量——只要你把规则配好它就在那个控制循环里安静地干活。这篇内容适合正在用Kubernetes跑业务、但还在靠手动kubectl scale撑场面的人。如果你已经用上了HPA但还是偶尔被抖动的副本数坑过后面第5和第6节里的调优思路和踩坑记录应该对你有用。这篇文章会从原理讲到配置再讲到生产环境里的真实教训尽量让你读完能直接上手也能避开那些文档里不写、但线上一定会遇到的大坑。2. HPA的工作逻辑一个30秒循环加上一道小学算术题HPA不是玄学它是一个非常朴素的控制器。理解它只需要搞明白两件事它多久检查一次以及它怎么决定副本数。2.1 控制循环每30秒做一次“体检”HPA控制器运行在Kubernetes的控制平面上默认每30秒执行一次完整的“体检”流程。这个流程大致是读取你定义的HPA对象找到目标工作负载比如某个Deployment。向metrics接口发起请求拉取当前副本数的实时指标CPU、内存等。把拉到的指标和你设定的目标值做对比。代入公式算出期望副本数。如果期望副本数跟当前副本数不一致执行扩缩容操作如果一致什么都不做等下个周期。这个30秒的周期可以通过--horizontal-pod-autoscaler-sync-period参数调整但生产环境基本不需要动它。30秒一轮的检查节奏配合后面会说的冷却机制已经能在“反应及时”和“避免抖动”之间取得一个比较平衡的状态。2.2 副本数计算公式核心就一条HPA决定副本数的公式用一句话就能说清期望副本数 ceil(当前副本数 × (当前指标值 / 目标指标值))看起来是不是像小学算术题但这个公式里藏着很多值得琢磨的细节。假设你的Deployment当前有10个副本每个Pod的CPU使用率平均是60%你设定的目标值是50%。代入公式10 × (60% / 50%) 10 × 1.2 12。期望副本数是12HPA就把副本从10扩到12。反过来如果当前平均CPU是30%目标50%10 × (30% / 50%) 10 × 0.6 6。期望副本数是6HPA就缩到6个。注意这里有个关键点HPA计算的是“当前副本数”的平均指标不是单个Pod的。也就是说系统把所有Pod的CPU使用率取平均再拿这个平均值去和目标比。这个“平均”的语义很重要它意味着少数几个高负载Pod不会单独触发扩容但整体水位一旦越过阈值扩容会立刻发生。2.3 为什么一个Pod的指标那么关键requests是基准线还有一个容易忽略的前提HPA计算CPU使用率的“分母”不是节点的物理CPU而是你在Pod里设置的CPU requests值。举个例子你的Pod请求了500m CPU半个核实际用了300mHPA认为的使用率是60%。如果你不设置requestsHPA根本拿不到这个分母整个自动伸缩直接失效。这可能是HPA使用中最大的“隐形坑”——后面第6节我会专门讲这个事。2.4 伸缩不是一步到位冷却与容忍度如果HPA每秒都在算、每秒都在变你的Pod数量会疯狂抖动。所以HPA有一套机制来“稳住”节奏容忍度Tolerance默认情况下只有当指标偏离目标值超过10%时HPA才会触发伸缩。这个“10%的缓冲区间”防止了指标在阈值附近小幅震荡时频繁扩容缩容。冷却机制扩容和缩容之间有时间间隔。扩容的默认冷却时间是15秒可配置缩容则是300秒。你没看错缩容默认要等5分钟。这是Kubernetes的刻意设计扩容要快缩容要慢避免流量刚降下来就把副本砍掉结果下一秒流量又上来造成伸缩震荡。HPA的“快扩慢缩”这个设计理念贯穿了整个自动伸缩策略包括后面要讲的生产调优本质上都是在这两个方向上做更精细的控制。3. 落地前必须准备的两件事metrics-server与requests配置理论搞明白了下一步就是动手。但在你执行kubectl apply -f hpa.yaml之前有两个前置条件必须确认少一个HPA就是摆设。3.1 metrics-serverHPA的数据来源HPA要读取Pod的CPU和内存指标这些数据从哪来答案是metrics-server。metrics-server是Kubernetes集群里的一个组件它从每个节点的kubelet上采集资源使用数据然后通过Metrics API对外提供。kubectl top node和kubectl top pod这两个常用命令背后就是它。检查你的集群是否已经部署了metrics-server执行kubectl top node如果返回了每个节点的CPU和内存使用情况说明metrics-server已经在工作了。如果报错提示Metrics API不可用你需要先安装。绝大多数Kubernetes发行版都支持用下面的方式一键部署kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml如果你是自建集群还要确认kubelet的证书配置metrics-server默认是用HTTPS去访问kubelet的。有些场景需要给metrics-server加--kubelet-insecure-tls参数这个属于安装细节不同发行版略有差异这里不展开。3.2 给工作负载设置合理的requests这一步是很多新手栽跟头的地方。我给个反例你就明白了。假设你的Deployment YAML长这样apiVersion: apps/v1 kind: Deployment metadata: name: demo-api spec: replicas: 3 selector: matchLabels: app: demo-api template: metadata: labels: app: demo-api spec: containers: - name: app image: demo-api:v1.0注意resources.requests一点都没写。这时候HPA的CPU目标还能用吗不能。因为HPA拿到的CPU使用率是“实际使用量除以requests值”算出来的百分比。没有requests这个除法的分母就不存在HPA会一直报错或者干脆不工作。正确的姿势是在容器配置里加上resources: requests: cpu: 500m memory: 512Mi这个500m不是随便拍的。它应该是你根据“单个Pod在正常负载下需要多少CPU”评估出来的一个基准值。HPA的整个扩缩容逻辑都围绕着它展开requests设得太高HPA会过早扩容设得太低则会延迟扩容。我见过不少团队为了省事给所有服务统一设cpu: 100m结果HPA表现得极其迟钝——服务已经明显过载了副本还是一个都不加。原因很简单每个Pod只请求100m100%的使用率也才100m而实际负载早就把节点CPU吃满了HPA从自己那个“小分母”里看不出危险。3.3 用kubectl验证指标采集链路前置条件都确认完之后建议先手动拉一下指标确认数据链路是通的kubectl top pod -l appdemo-api如果你能看到类似这样的输出NAME CPU(cores) MEMORY(bytes) demo-api-7d8f9c4b6b-abc12 300m 245Mi demo-api-7d8f9c4b6b-def34 280m 230Mi demo-api-7d8f9c4b6b-ghi56 320m 260Mi说明指标采集正常可以进入下一步配置HPA了。如果这里就已经报错或者数据为空强烈建议先解决数据链路的问题再往下走不要带着问题去配HPA否则后面排查起来会非常痛苦。4. 从零配置一个能用的HPA完整示例与压测验证前置工作做完现在开始配置HPA本身。我会用一个完整的例子带你过一遍先创建一个带requests的Deployment再创建HPA最后通过压测观察自动扩缩容效果。4.1 一个配置了requests的Deployment示例apiVersion: apps/v1 kind: Deployment metadata: name: demo-api namespace: default spec: replicas: 2 selector: matchLabels: app: demo-api template: metadata: labels: app: demo-api spec: containers: - name: app image: demo-api:v1.0 ports: - containerPort: 8080 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 500m memory: 512Mi这里我设置了requests.cpu: 200m意思是每个Pod的基准CPU是0.2核。limits设成500m是给单个Pod设了硬上限防止某个Pod把节点CPU吃光。注意在配置HPA时requests是决定伸缩的“标尺”limits是保护机制两者都很重要但角色完全不同。4.2 创建HPA的两种方式HPA的创建方式有两种命令行一把梭或者YAML文件管理。方式一命令行快速创建这条命令的意思是当demo-api所有Pod的平均CPU使用率达到70%时开始扩容副本数范围是2到10kubectl autoscale deployment demo-api --cpu-percent70 --min2 --max10方式二YAML文件这种更推荐特别是生产环境里HPA配置应该跟Deployment一起入库管理apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: demo-api-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: demo-api minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70注意我用的是autoscaling/v2这个API版本它支持多指标和更丰富的策略配置。旧版本的autoscaling/v1只支持CPU能力有限建议直接上v2。执行kubectl apply -f hpa.yaml查看HPA状态kubectl get hpa demo-api-hpa你会看到一行类似于下面这样的输出NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE demo-api-hpa Deployment/demo-api 7%/70% 2 10 2 5mTARGETS列里的7%/70%意思是当前Pod平均CPU使用率7%目标70%。当前副本数2在范围内HPA判断不需要伸缩。4.3 用压测制造一次真实的扩缩容配置好了不敢压测验证就等于没做。我用一个最简单的压测方法起一个临时Pod往你的服务上打流量。先确认服务已经暴露然后执行kubectl run -it --rm load-generator --imagebusybox -- /bin/sh进入容器后跑一个循环请求while true; do wget -q -O- http://demo-api-svc.default.svc.cluster.local:8080/health; done如果服务端处理请求时需要消耗CPU比如做点计算、查点数据这个循环会在几秒内把Pod的CPU打上去。这时候另开一个终端持续观察kubectl get hpa demo-api-hpa -w你会看到类似下面的演变过程NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE demo-api-hpa Deployment/demo-api 120%/70% 2 10 2 10m demo-api-hpa Deployment/demo-api 120%/70% 2 10 3 10m demo-api-hpa Deployment/demo-api 85%/70% 2 10 4 11mTARGETS超过70%后HPA开始干活了。它先算期望副本数2 × (120% / 70%) ≈ 3.4向上取整到4。但注意HPA不是一次直接扩到4而是先扩到3等下一轮检查发现CPU还是高再继续扩。这个“逐步扩容”的节奏其实就是HPA控制循环每30秒跑一次的自然结果。压测停止后指标慢慢回落HPA开始缩容。这个过程会慢很多因为默认的缩容冷却时间是5分钟。你可能会看到副本数在几分钟后才逐步从4降到2。这是正常现象不是HPA坏了。5. 生产环境必备的伸缩策略调优从冷静期到行为控制基础配置能用但离“生产可用”还有一段距离。真实场景里你不仅要让HPA能扩能缩还要让它在合适的时机、以合适的步调去扩缩。这一节讲几个我实战中觉得必须掌握的调优点。5.1 缩容冷静期为什么是300秒以及怎么改前面提到缩容默认要等5分钟这个是Kubernetes故意的。原因是生产环境里流量往往有短时波动如果HPA在3分钟内因为流量小降就缩掉一批Pod紧跟着的流量高峰会让刚缩掉的Pod又重新扩回来——不但没省资源反而制造了一堆Pod的创建销毁甚至引发更严重的连锁问题。但是5分钟这个值不是所有场景都合适。有些业务有明显的周期性波峰波谷比如每天固定时间点的流量高峰高峰过后需要尽快缩容省钱。这时候可以把缩容冷静期调短。通过HPA的behavior字段控制behavior: scaleDown: stabilizationWindowSeconds: 120stabilizationWindowSeconds就是缩容冷静期默认值300秒。这里设成120秒表示指标低于目标之后的2分钟内缩容操作会被“压制”2分钟过后如果指标还是低才开始缩。调这个值要谨慎太短容易抖动太长浪费资源。5.2 控制扩缩容的“步幅”别一次扩一群默认情况下HPA一次性可以创建多少Pod答案是“不受限”的——它可能一次从2个扩到10个。这在流量突增时是好事但在某些场景下比如下游数据库扛不住瞬间流量反而是坏事。如果你希望HPA每次最多只扩2个Pod可以通过behavior配置behavior: scaleUp: selectPolicy: Max policies: - type: Pods value: 2 periodSeconds: 60意思是在60秒内最多新增2个Pod。如果同时有多个策略被触发selectPolicy: Max表示取其中计算结果最大的那个值。你还可以用type: Percent按比例扩容比如每次最多扩当前副本数的50%。这个“步幅控制”在对接有状态服务、或者下游有数据库连接池限制的场景里特别有用。我曾经把一个批处理服务的HPA从“一次扩到最大”改成“每分钟最多扩4个”下游数据库的告警立刻就消停了。5.3 用多个指标做更合理的伸缩决策只靠CPU有些场景会误判。一个典型的例子是内存密集型服务CPU使用率一直很低但内存快满了随时可能OOM。这种服务只配CPU目标HPA会一直无动于衷。autoscaling/v2支持在同一份HPA里配置多个指标。比如spec: metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80这时的规则是任何一个指标达到目标值就触发扩容。CPU没过载、内存过载了同样会扩容反过来也一样。多指标的好处是覆盖了更多过载场景坏处是扩容会更敏感所以目标值要结合实际资源画像来定不要照搬别人的配置。5.4 配合Cluster Autoscaler从Pod扩缩到节点扩缩HPA解决的是“现有节点能不能塞下更多Pod”的问题。但如果集群本身没有空余节点——比如所有节点的资源都被Pod占满了——HPA扩出来的Pod会一直处于Pending状态副本数显示增加了但实际服务能力没有提升。这种场景需要的是Cluster Autoscaler它监控Pending状态的Pod自动为集群增加节点。这两个组件的分工很清楚HPA决定“需要多少个Pod”Cluster Autoscaler决定“需要多少台节点”。生产环境的容量管理一般是两者配合使用。HPA保证业务层面的副本数Cluster Autoscaler保证底层资源的整体容量。缺了任何一个自动伸缩都不完整。6. 我在实践中踩过的坑三起三落的排查实录理论、配置、调优都讲完了最后分享几个我在真实环境里踩过的坑。这些都是文档里不会提醒你但线上一定会让你头疼的问题。我尽量把排查思路也写清楚授人以渔比授人以鱼更有价值。6.1 坑一TARGETS列显示unknownHPA完全不工作现象kubectl get hpa看不到任何数据UUID显示TARGETS列是unknown。排查链路先看HPA的事件kubectl describe hpa demo-api-hpa一般能看到明确报错。一种常见报错是“failed to get cpu utilization”这时候直接测Metrics API是否正常kubectl top pod。如果kubectl top pod有数据但HPA读不到多半是HPA跟目标Deployment不在同一个namespace或者scaleTargetRef里的name写错了仔细核对一下。如果kubectl top pod也报错那就是metrics-server的问题。检查metrics-server的Pod是否正常Running看它的日志里有没有连接kubelet失败的记录。我遇到过最隐蔽的一次集群和metrics-server版本不匹配metrics-server升级后旧集群的aggregator discovery信息没有刷新导致Metrics API注册失败。重启kube-apiserver的aggregator组件之后恢复正常。6.2 坑二requests没设扩容永远晚一步这是最典型的“配置看起来没什么问题但就是不对劲”的场景。我的一个同事把所有服务的requests都从YAML里去掉了他以为limits就够了然后HPA的TARGETS列显示的CPU使用率永远是0%。原因是HPA算百分比时分母是requests值没有requests它只能把使用量当作百分比直接显示而这个数字因为缺少基准根本没意义。排查方式很简单kubectl get pod -o yaml看Pod的resources字段是不是空的。如果是空的给Deployment补上requests滚动重启TARGETS列立刻恢复正常。6.3 坑三压测时副本数疯狂波动服务反而更不稳定有一阵子我在做某个网关服务的HPA压测现象很奇怪HPA在几分钟内反复扩容缩容Pod频繁创建销毁服务P99延迟不降反升。最后定位到两个原因叠加第一我的压测请求速率不够稳定时高时低导致Pod CPU使用率在目标值上下剧烈摆动。第二我没有配置容忍度默认10%也没有配置behavior的冷静期HPA对轻微的指标变化过于敏感。解决办法给HPA加了behavior配置把扩容冷静期调成15秒默认就是缩容冷静期从300秒调成180秒。压测时用固定的QPS而不是while true猛打保持指标的稳定性。这里要强调一个原则自动伸缩解决的是“长期负载变化”不是“瞬时抖动”。如果一个服务的CPU使用率本身就在40%-90%之间反复横跳你需要优化的不是HPA而是这个服务自身的资源使用稳定性。6.4 压测时观察HPA的侧面提示顺带提一个压测经验压测时不要只看HPA的副本数还要看Pod的启动速度和调度情况。如果Pod镜像很大比如几个GB扩容后Pod要几分钟才能Ready这段时间内新流量还是会打到老Pod上延迟依然高。这时候要考虑的是镜像预热、增加最小副本数或者把HPA的目标值调低一点让扩容提前发生。我的习惯做法是给每个核心服务设置一个“安全垫”——比如目标CPU使用率是50%而不是70%。这样HPA会在负载还没冲到临界值之前就开始扩容虽然会多跑几个Pod但换来了更平滑的用户体验。成本可控的话这个“安全垫”非常值。写在最后HPA只是开始玩明白HPA之后你会发现自动伸缩的下一步是工作负载的弹性设计——你的服务能不能在副本数变化时保持连接不闪断、缓存不击穿、任务不重复执行才是真正决定“自动伸缩好不好用”的关键。HPA帮你解决了“有多少个Pod”的问题但“每个Pod是否做好了随时被杀掉、随时被拉起”的准备是你自己写的代码和配置决定的。最后分享一个小建议每次调整完HPA配置在测试环境完整压测一次再上生产压测的范围不仅要覆盖扩容方向还要覆盖缩容方向——缩容引发的连接中断、优雅下线、任务重放这些坑往往比扩容更难排查。