跑过K8s集群的人大概率经历过这种场面：白天流量一上来，Pod扛不住直接OOM；凌晨没人访问，一堆Pod空转烧钱。手工扩缩容？根本来不及。这时候你就需要一个靠谱的HPA（Horizontal Pod Autoscaler）帮你自动搞定。
摩尔狮在云原生培训中发现，HPA是K8s运维工程师面试必考点，也是实际生产中最常用的弹性伸缩手段。今天我们把HPA的配置逻辑、3种指标类型和5个真实踩坑场景讲透。
一、HPA到底在干什么
简单说，HPA就是一个自动帮你增减Pod副本数的控制器。它会持续监控你设定的指标，当指标超过阈值就扩容，低于阈值就缩容。整个过程不需要你半夜爬起来敲kubectl。
它的工作链路是这样的：Metrics Server采集数据 → HPA定期轮询指标 → 计算期望副本数 → 调用Deployment的replicas字段。整个循环默认15秒一次。
二、3种指标类型你得门清
第一种，Resource CPU/Memory。这是最基础的用法，按CPU使用率或内存使用率来触发。比如设了targetCPUUtilizationPercentage为70，当前所有Pod平均CPU超过70%就扩容。大部分业务场景靠这个就能跑。
第二种，Custom Metrics。自定义指标，比如你的Go服务暴露了一个queue_depth的指标，HPA可以按这个来扩。需要你自己接Prometheus Adapter把指标暴露到K8s的custom.metrics.k8s.io API。
第三种，External Metrics。外部指标，比如来自云监控的SLB QPS数据。适合那种Pod内部看不到但业务又关心的指标。配置方式和Custom类似，数据源换成外部适配器就行。
想深入了解Kubernetes集群管理入门的同学，HPA是绕不开的核心组件。
三、5个真实踩坑场景
坑1：Metrics Server没装好。HPA依赖Metrics Server拿CPU/内存数据，如果kubectl top pods返回空，HPA根本不会触发扩容。很多人配了半天HPA不生效，问题出在这。
坑2：minReplicas设太低。你设了minReplicas=1，流量低谷缩到1个Pod，流量突然来了来不及扩就直接打爆。我们建议minReplicas至少设2，留一个冗余。
坑3：CPU请求值没设resources.requests。HPA按requests计算使用率百分比，如果你没设requests，默认值会导致计算完全跑偏。一个Pod用着90%CPU但HPA显示才10%，就是这原因。
坑4：扩容太激进导致震荡。刚扩完还没稳定又触发缩容，来回来去抖动。解决办法是加--horizontal-pod-autoscaler-downscale-stabilization参数，默认5分钟窗口内取最大值防止回弹。
坑5：Custom Metrics权限没配。RBAC的ClusterRole忘了绑，HPA读不到自定义指标直接报错。记得给HPA的ServiceAccount授权metrics.k8s.io的get和list权限。
四、一份生产级HPYAML长什么样
给你一个我们验证过的模板。apiVersion用autoscaling/v2（v1已经deprecated了），metrics里可以同时塞多种指标类型，maxReplicas根据你业务峰值QPS和单Pod承压能力来算。
有个小技巧：behavior字段可以分别控制scaleUp和scaleDown的策略。比如扩容快一点（30秒内加2个Pod），缩容慢一点（5分钟内最多减1个），这样既响应快又不会震荡。
五、HPA和VPA、Cluster Autoscaler怎么配合
HPA管的是Pod数量（水平扩缩），VPA管的是单个Pod的资源配额（垂直扩缩），Cluster Autoscaler管的是Node节点数量。三者可以叠加用，但注意HPA和VPA不能同时管同一个Resource指标，会打架。
推荐组合：HPA用CPU/自定义指标管副本数，Cluster Autoscaler兜底节点弹性。VPA只用在那些不适合水平扩展的有状态服务上。
关于Docker容器化部署的基础知识，建议先打牢再上K8s。
HPA这东西说简单也简单，说难也不难。关键是你得把指标链路、计算逻辑和边界条件搞明白，不然生产环境出问题排查起来很头疼。阿里云认证培训里这块是云原生方向的高频考点，备考的同学重点关注。
更多阿里云认证资讯，请关注公众号：摩尔狮云证通