1. 为什么需要HPA从手动扩缩容到弹性伸缩做 Kubernetes 运维的人迟早要面对 HPA——HorizontalPodAutoscaler 这套机制。HPA 解决的问题其实很朴素业务流量涨上去了副本数就得跟着涨流量下去了多余副本也不能继续白白占着资源。过去手工kubectl scale deployment web-demo --replicas10也能做但凌晨三点被告警叫起来手动扩容的滋味经历过的人都不想再有第二次。HPA 就是把这套“看指标、定副本、执行扩缩容”的判断逻辑自动化让副本数始终贴合实际压力。HPA 的官方名称很难念HorizontalPodAutoscaler它只负责“水平扩容”多做几份副本把流量分摊到更多 Pod 上。与之相对的是“垂直扩容”也就是给单个 Pod 增加 CPU、内存配额这套机制叫 VPA。两者适用场景不同HPA 更常见因为互联网应用绝大多数是无状态服务都适合用多副本扛流量。HPA 能自动调整 Deployment、StatefulSet 等工作负载的副本数也可以配合 ClusterAutoscaler 让整个节点池跟着弹性伸缩形成从“Pod 层”到“Node 层”的完整弹性链路。这篇文章我会从 HPA 的底层算法讲起再给出一套可以直接抄走的 YAML 配置然后用实际压测场景说明观测方法最后整理我在生产环境里踩过的坑。不管你是刚接触 Kubernetes 的新手还是已经被“副本抖动”“指标采集不到”折磨过的运维老手都能从这篇文章里找到可以直接用的东西。文章里的所有配置我都尽量贴近官方默认行为同时说明每个字段背后的必要性这样你才能知道哪些可以删哪些必须留。2. HPA 到底怎么工作控制回路与目标副本数算法2.1 控制回路谁在循环执行这件事HPA 不是独立的 Pod也不是单独的二进制服务它是 kube-controller-manager 里的一个控制回路。控制器默认每隔一段时间就执行一次完整的“采集指标 - 计算期望副本数 - 调整副本数”流程。官方文档里把这个间隔称为 horizontal-pod-autoscaler-sync-period默认是 15 秒。了解这个时间间隔很重要因为 HPA 不是实时的你要看到的扩容动作通常带有 15 秒左右的延迟。如果再加上指标数据自身的采集间隔从流量突增到新 Pod 被创建中间隔二三十秒是完全正常的。控制回路读取的指标来自 metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io 这三类 API。CPU、内存这类基础资源指标走 metrics.k8s.io一般由 metrics-server 提供应用自定义指标比如 QPS、队列长度、gRPC 并发连接数走 custom.metrics.k8s.io一般由 Prometheus Adapter 这类组件提供外部指标比如云厂商消息队列堆积量走 external.metrics.k8s.io。HPA 的通用逻辑是先向这些 API 发起请求拿到当前副本数对应的 Pod 指标集合再计算当前平均值最后和目标值做比较。这套机制里最容易被忽略的一点是HPA 的目标值不是“当前总指标要小于目标值”而是“当前每个 Pod 的平均值要靠近目标值”。以 CPU 为例假设目标利用率 50%如果当前 Pod 的平均利用率 80%HPA 就会扩容如果当前平均值只有 30%HPA 就会缩容。它管理的粒度始终是“平均每 Pod”而不是整个 Deployment 的总量。理解这一点后面很多配置困惑都会迎刃而解。2.2 期望副本数公式所有扩容决策的数学基础HPA 的期望副本数计算公式在官方文档里有明确说明可以写成期望副本数 ceil(当前副本数 * 当前指标平均值 / 目标指标平均值)这里的 ceil 是向上取整。假设当前有 3 个副本每个 Pod 平均 CPU 使用量为 500m目标平均使用量为 200m那么根据公式期望副本数 ceil(3 * 500 / 200) ceil(7.5) 8HPA 会把 Deployment 的副本数从 3 调整到 8。这个过程是“按比例推测”的如果每 Pod 用量是目标的 2.5 倍那就大约需要 2.5 倍数量的 Pod才能把平均值压回目标线附近。但公式并不是直接算出多少就立刻设置多少控制器代码里还存在一个“数量级限制”。官方为了平滑伸缩在 v1 和 v2 的实现里每次扩容最多把副本数翻倍如果没有现成的 Pod首次扩容可以到 maxReplicas。缩容也有限制每次缩容最大只会缩掉一半副本。这是为了保护系统避免指标波动时副本数像过山车一样大起大落。尤其对于有突发流量但持续时间很短的业务一次从 3 副本直接扩到 100 副本会造成巨大浪费而“最多翻倍”的策略相当于给扩容加了一层节流阀。需要注意公式里“当前指标平均值”的采集窗口并不是实时瞬时值而是控制器在--horizontal-pod-autoscaler-tolerance范围内做比较。默认 tolerance 是 0.1也就是当期望副本数与当前副本数的比例为 0.9 到 1.1 之间时HPA 认为“当前副本数基本满足需求”不会做任何调整。这就是为什么很多场景下 CPU 已经 55% 了HPA 却依然没有反应——因为目标 50%偏差 10% 以内属于死区。想更敏感可以调整 kube-controller-manager 启动参数但生产环境建议不要轻易调小否则极易抖动。2.3 两种度量方式直接值与利用率HPA v2 的配置里目标指标可以写成两类。第一类是“直接值”比如 target.averageValue 或 target.value目标是一个绝对数字。对于 Pod 内上报的自定义指标比如“每个 Pod 当前有 20 个请求在排队”target 就可以设为 10 或 3 这类绝对值。控制器的计算方式很简单当前所有 Pod 的指标值求和后再除以 Pod 数然后和 target 的平均值比较。第二类是“利用率”主要用于 CPU 和内存配置为 target.averageUtilization。利用率是“当前使用量 / 当前 Pod 的资源请求量”的百分比。比如 Pod 的 CPU request 是 100m实际使用 80m那么当前利用率就是 80%。HPA 对这种指标计算期望副本数时公式不变只需要把“当前指标平均值 / 目标平均值”替换成“当前平均利用率 / 目标平均利用率”。为什么利用率一定要基于 request 而不是 limit因为 request 是调度器用来保证 Pod 可获得最小资源的依据也是 Kubernetes 给 Pod 承诺的“起步配额”。limit 只是容器不能超过的上限拿 limit 算利用率会让结果失真一个 Pod limit 很大但实际用量很小算出来的利用率和它真实压力完全不成正比。所以配置 HPA 的 CPU/内存指标之前先确认你的 Deployment 里每个容器的 resources.requests 都写得清清楚楚否则 HPA 八九不离十会报“no metrics returned”。这一点我在后面“常见问题”里还会反复强调。3. 从零配置一个 HPA 实例3.1 准备 metrics-server 或对应的指标采集层在配置 HPA 之前先确认集群里有没有安装指标采集组件。对于 CPU 和内存这类资源指标最常用的是 metrics-server。它不是 Prometheus不做长期存储只提供当前节点和 Pod 的瞬时资源数据。把 metrics-server 装进集群后API Server 才会出现 metrics.k8s.io 这个聚合 APIkubectl top nodes和kubectl top pods也才能正常使用。验证方法很简单执行两条命令kubectl top nodes kubectl top pods -A如果都能返回 CPU 和内存数据说明 metrics-server 工作正常。如果你用的是云厂商托管 Kubernetes 集群大部分都已经默认集成了 metrics-server这时候可以跳过这一步。如果你的业务指标是 QPS、队列深度、gRPC 连接数这类自定义数据就需要额外部署 Prometheus并配置 Prometheus Adapter让它把 Prometheus 里的指标通过 custom.metrics.k8s.io API 暴露出来。这个链路比 metrics-server 复杂很多我后面会单独说配置要点。3.2 创建带资源请求的 Deployment 和服务很多新手把 HPA 配置得漂漂亮亮但 Deployment 里的容器没有写 resources.requests结果 HPA 一直无法获取 CPU 利用率。所以我建议你先在测试环境里把一个最简单的 Deployment 跑起来并且把 request 写好。下面这个配置是一个标准的无状态 Web 服务apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: default spec: replicas: 1 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: web image: registry.example.com/web-demo:latest ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi这里我特意给容器设置了requests.cpu: 100m。HPA 在计算 CPU 利用率时会把 Pod 实际用量除以 100m 再乘 100%得到当前的利用率百分比。如果没有任何 requestHPA 就缺少计算分母cached 数据也找不到有效的指标来源事件里就会出现failed to get cpu utilization或missing request for cpu这类报错。为了便于测试再创建一个 Service否则你只能从集群外部或通过临时 Pod 压测。你可以用最简单的 ClusterIP 类型apiVersion: v1 kind: Service metadata: name: web-demo-svc spec: selector: app: web-demo ports: - port: 80 targetPort: 80803.3 创建 HPA 并理解每个字段现在创建 HPA 对象。这里我给出的是 autoscaling/v2 版本这是当前 HPA 功能的完整版本支持多指标、自定义指标、行为控制等高级特性。v1 只支持 CPU不要在新环境里使用了。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-demo-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-demo minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 selectPolicy: Max scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 60拆开解释一下scaleTargetRef指向要扩缩容的工作负载。我这里的kind是 Deployment所以 HPA 只会修改这个 Deployment 的.spec.replicas字段。minReplicas和maxReplicas划定副本数边界。生产建议 minReplicas 至少 2保证高可用如果成本敏感测试环境可以 1。metrics数组里的type: Resource表示这是资源指标name: cpu指定指标名target.type: Utilization表示按利用率算averageUtilization: 50表示目标是所有 Pod 的平均 CPU 利用率 50%。behavior里我定义了扩容策略和缩容策略。扩容时type: Percent, value: 100表示每次最多扩容当前副本数的 100%比如当前 4 个副本最多扩展到 8 个type: Pods, value: 4表示每次最多增加 4 个 Pod。两条策略同时给出selectPolicy: Max表示选二者中允许值更大的那次操作。stabilizationWindowSeconds是稳定窗口缩容我保留 300 秒也就是 5 分钟内连续满足缩容条件才会真正缩容。这个值对防止抖动很关键。创建命令kubectl apply -f hpa.yaml kubectl get hpa web-demo-hpa如果能正常运行kubectl get hpa的TARGETS列会显示类似5%/50%的信息前面是当前值后面是目标值。3.4 压测与观察确认扩容真的会发生要验证 HPA 是否正常工作必须人为制造压力。我更推荐用专门的压力测试工具比如hey、wrk、ab或者直接在集群内跑一个临时 Pod循环请求 Service。以hey为例kubectl run load-generator --imageregistry.example.com/hey --restartNever -- \ -z 5m -c 20 -q 500 http://web-demo-svc这里重点不是工具本身而是你要注意观察。用另一个终端持续查看kubectl get hpa web-demo-hpa -w kubectl get deploy web-demo -w kubectl top pods -l appweb-demo正常情况下流量拉起来后CPU 利用率会迅速超过 50%然后 HPA 开始逐步增加副本数。因为我在 behavior 里把稳定窗口设为 0、每次扩容最多增加 4 个 Pod你会发现副本数像台阶一样往上爬而不是瞬间跳到最大。流量结束后缩容需要等 5 分钟稳定窗口这期间副本数保持不变之后逐渐回落到 minReplicas。3.5 kubectl 命令行方式能省则省的手工场景如果想快速测试或临时调整也可以用kubectl autoscale创建 HPAkubectl autoscale deployment web-demo \ --min2 \ --max10 \ --cpu-percent50这个命令只创建 CPU 利用率 50% 的 HPA自动使用 autoscaling/v2 API。它生成的 metric 配置和你手写的averageUtilization: 50是一样的。命令行方式适合临时测试但生产环境建议把 YAML 文件提交到 Git方便 review 和回滚。我自己的习惯是集群里的 HPA 全部由 GitOps 管理任何人不得手工kubectl autoscale避免线上配置漂移。4. 核心细节与配置项拆解4.1 autoscaling/v2 与 v1 的差异Kubernetes 1.18 之后HPA 的稳定版本就是 autoscaling/v2v2beta2 已经废弃。v1 的 HorizontalPodAutoscaler 只支持 CPU 这一个指标且不能配置 behavior。如果你在网上找到的教程还是apiVersion: autoscaling/v1、字段里写着minReplicas/maxReplicas/targetCPUUtilizationPercentage那大概率是旧资料别直接抄。v2 统一了指标结构把 CPU、内存、自定义指标、外部指标都放在metrics数组里结构更清晰。迁移也不难把 v1 改造成 v2 的 CPU 指标写法只需要把targetCPUUtilizationPercentage替换成 metrics 数组中的 Resource 类型。4.2 目标指标类型Resource、Pods、Object、ExternalHPA v2 的metrics数组里可以配置四种类型每种类型对应不同的指标来源Resource对应 metrics.k8s.io主要就是 CPU 和内存。target 支持Utilization和AverageValue。内存不能用 Utilization 吗实际上averageUtilization也支持内存但内存利用率容易出现“回收后回落”的问题生产里用内存作为唯一扩缩容指标要格外小心。Pods对应 custom.metrics.k8s.io指标必须来自 Pod 本身而且每个 Pod 上报的指标是独立的。target 只支持AverageValue。比如每个 Pod 的当前任务队列长度为 10希望平均不超过 3就配置为target.averageValue: 3。Object对应 custom.metrics.k8s.io它描述某个自定义对象的指标比如 Ingress 的 QPS、Service 的请求延迟不直接挂在 Pod 上。配置里要同时写describedObject来指定对象类型和名称。External对应 external.metrics.k8s.io适合从集群外部读取指标比如云厂商的消息队列堆积量、SLO 监控指标等。它们在 API 对象上的写法差异比较大我贴一个Object类型的示例metrics: - type: Object object: describedObject: apiVersion: networking.k8s.io/v1 kind: Ingress name: web-ingress metric: name: nginx_ingress_controller_requests_per_second target: type: Value value: 1000这是让 HPA 根据 Ingress 上的总 QPS 来决定副本数目标 1000 QPS。注意这里的指标名必须是你注入到 Kubernetes 自定义指标 API 里的真实 metric 名称不是 Prometheus 里的原始指标名。Adapter 层需要做一次映射。4.3 多指标组合HPA 如何决定最终副本数一个 HPA 对象可以在metrics数组里写多个指标。比如同时配置 CPU 利用率和自定义 QPS。控制器会对每个指标分别计算“期望副本数”最后取所有结果里的最大值。这个设计很符合业务直觉只要其中一个指标已经“喊渴”就应该扩容否则单看 CPU 可能掩盖了请求积压。举个例子Deployment 当前副本数是 4。按 CPU 利用率计算期望副本数是 6按 QPS 平均值算期望副本数是 9。那么 HPA 最终会把副本数调整到 9。缩容时也是一样必须所有指标的期望副本数都低于当前副本数才可能触发缩容。这可能导致某些场景下副本数“下不来”——比如 CPU 已经很低了但自定义指标仍然偏高。遇到这种情况不能靠调 HPA 的 minReplicas 硬压应该先查业务指标为什么居高不下。4.4 behavior 字段缩容保护与扩容限速的正确写法behavior是 v2 引入的一等公民字段它分scaleUp和scaleDown两个子块。每块都由stabilizationWindowSeconds、policies和selectPolicy组成。很多人看见这三个属性就晕我用一句大白话总结稳定窗口是“观望多久”policies 是“一次最多动多少”selectPolicy 是“多个策略同时生效时听谁的”。稳定窗口的作用非常直观。默认缩容稳定窗口是 300 秒扩容稳定窗口是 0 秒。为什么缩容要观望 5 分钟因为流量波峰过去后指标下降往往是缓慢且波动的立刻缩容会导致副本数跟着流量一起震荡结果就是集群资源利用率很低但 Pod 一直在反复创建和删除。设置了稳定窗口后控制器会记住这段时间内所有“期望副本数”在窗口内只倾向于选择最小合理值或最大合理值。具体行为可以在官方 behavior API 文档里看到但普通使用只需要记结果scaleDown.stabilizationWindowSeconds: 300表示 5 分钟内不会被马上缩到低水位。scaleUp.stabilizationWindowSeconds: 0表示指标一上来扩容不等待。policies是策略列表。每条策略有type和value。type 可以是Pods或Percent。periodSeconds表示“在一个周期内最多执行多少次”。比如type: Percent, value: 100, periodSeconds: 15意思是每 15 秒允许增加 100% 当前副本数也就是每次最多翻番。如果你把value: 4, type: Pods写成一个 Pods 策略它和 Percent 策略并存HPA 会按selectPolicy决定。selectPolicy有三个候选值Max选较大操作、Min选较小操作、Disabled表示这种方向上的伸缩被完全禁止。Disabled很不常用但有些团队为了“只扩容不缩容”会这么配我不建议因为那是掩耳盗铃还不如直接把 minReplicas 调到期望值。4.5 和其他控制器协同PDB、ClusterAutoscaler 与资源配额HPA 不是 Kubernetes 里唯一的伸缩机制它需要和几个“邻居”配合好。PodDisruptionBudgetPDB用于控制自愿驱逐时最多能中断多少 Pod。当你缩容时HPA 不会直接删除 Pod而是修改 Deployment 的 replicas随后 ReplicaSet 控制器按一定顺序终止多余的 Pod。如果集群里有节点维护、Spot 实例回收、蓝绿发布这类操作PDB 会约束“最多允许几个 Pod 同时不可用”。假如 HPA 想把副本从 10 缩到 2但 PDB 限制最多只能有 1 个 Pod 同时中断那么缩容过程会变得很慢甚至长时间停在中间副本数。这不是故障而是保护机制在起作用。生产上你要预期到这种互相折衷。ClusterAutoscaler 是节点层弹性的关键。HPA 扩容出来的 Pod 如果当前节点资源不足会卡在 Pending 状态。ClusterAutoscaler 会观察 Pending Pod触发节点池扩容。反过来说HPA 缩容之后节点负载下降ClusterAutoscaler 也可能缩容节点。二者配合得好整个集群就是“应用压测涨 Pod节点不够涨机器”的完整弹性链路配合得不好会出现“HPA 想扩容但节点资源不够Pod 一直Pending越挤压越严重”的尴尬。我见过很多私有云环境没装好 ClusterAutoscalerHPA 扩容到接近资源上限后就卡死所有新 Pod 都在 Pending这时候先排查节点可用资源而不是怀疑 HPA 配置有误。资源配额ResourceQuota也能拦住 HPA 的扩容。如果 namespace 里设置了 CPU request 总配额HPA 把 replicas 调上去但 Pod 创建时配额不足ReplicaSet 会反复创建失败。这种问题非常隐蔽因为 HPA 的状态还是正常的副本数也显示已更新但实际可用副本数根本不够。排查时一定要看 ReplicaSet 的事件或者kubectl get events里的FailedCreate记录。5. 实战遇到的坑和排查技巧实录5.1 指标没数据HPA 报 no metrics returned我在测试环境最常遇见的 HPA 问题是kubectl describe hpa的 Events 里出现failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from the metrics API。这几乎都是因为 metrics-server 没正常工作或者容器没有 resources.requests。先按这个顺序排查kubectl get apiservice v1beta1.metrics.k8s.io kubectl top nodes kubectl top pods如果kubectl top nodes正常说明 metrics-server 向 API Server 注册成功数据链路没问题。接着看 Deployment 里的 Pod 是否所有容器都写了 resources.requests。注意如果一个 Pod 里有多个容器HPA 的 CPU 利用率会按所有容器 request 之和作为分母所有容器当前用量之和作为分子。有一个容器没写 request都会导致整个 Pod 的利用率无法计算。5.2 指标值波动导致副本抖动HPA 的默认 tolerance 是 0.1也就是目标值和当前值差距在 10% 以内时不动。但即使有 tolerance指标峰谷交替明显时copy 还是可能出现“扩 2 个、缩 1 个、再扩 2 个”的抖动。这个问题的解法不是把 sync-period 调大而是把缩容稳定窗口调大。我给生产环境定的经验值是scaleDown.stabilizationWindowSeconds: 600也就是流量下降后至少观望 10 分钟再缩容。如果你是 CPAU 类型的高延迟应用还可以把扩容稳定窗口也设置成 60 秒避免一次性扩容太过激进。5.3 单副本无法扩容有一种现场Deployment 副本数是 1HPA 的目标是 CPU 50%当前 CPU 已经 90%但 HPA 就是不扩容TARGETS 里显示unknown/50%或90%/50%事件里也没有任何 action。原因可能是 HPA 控制器第一次同步的时候拿不到 Pod 的指标Pod 处于启动过程中而 controller-manager 有--horizontal-pod-autoscaler-initial-readiness-delay参数默认 30 秒。在这 30 秒内Pod 即使已经 ReadyHPA 也不会用它的指标作为计算依据。另外还有一个常见原因你的 Deployment 的 Pod 被某种控制器比如另外一个人工kubectl scale操作改过副本数导致 HPA 认为当前副本数已经不是它期望的数值暂时收敛到新的基线。这个问题不容易一眼看出但只要等待下一次 sync 周期HPA 会自己修正。5.4 利用率计算与你预期不一致我见过很多次业务方说 CPU 用了 200%但 HPA 显示 50%。这类问题几乎都出在 request 设置上。HPA 是拿“当前 CPU 使用量 / 当前 CPU request”算利用率的。如果你的容器 request 是 1 核实际使用 2 核利用率就是 200%。如果你的容器 request 是 2 核实际使用 2 核利用率就是 100%。业务觉得“CPU 很高”是因为只看了容器实际使用量和 limit 的关系而 HPA 看的是 request。想对齐认知要么统一以 request 作为资源成本口径要么干脆改用target.averageValue而不是averageUtilization。用 averageValue 的话公式直接变成“当前每 Pod 平均使用量 / 目标平均使用量”不再受 request 影响。比如你想让每 Pod 平均 CPU 不超过 250m就可以写metrics: - type: Resource resource: name: cpu target: type: AverageValue averageValue: 250m这招非常实用尤其适合团队里对“利用率”概念理解不一致的场景。5.5 与资源 limit 的关系limit 不参与计算但会影响调度上面的公式我说了很多次 request 是分母接下来要说 limit 的作用。limit 虽然不参与 HPA 计算但影响运行稳定性。如果 Pod 里没设置 limit或者 limit 设得很大而业务压力又一直上涨HPA 扩容速度可能跟不上 CPU 爆掉的速度。尤其很多 Java 类应用内存压力上来后开始 Full GCCPU 飙升HPA 还没来得及扩容Pod 已经被 OOMKilled 或宿主机压垮。所以我的建议是request 尽量贴近真实日常使用不要拍脑袋。limit 至少留 30% 到 50% 冗余。针对 CPU 密集型业务最好同时配置 CPU 和内存两类 HPA 指标避免只看 CPU 忽略了内存维度。5.6 快速定位命令合集如果你手里的 HPA 表现诡异我推荐按下面顺序执行kubectl get hpa -A kubectl describe hpa web-demo-hpa kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods | head kubectl get --raw /apis/autoscaling/v2/namespaces/default/horizontalpodautoscalers/web-demo-hpa/status | jq . kubectl get events -n default --sort-by.lastTimestamp | grep -i hpa kubectl logs -n kube-system -l k8s-appmetrics-server --tail200第一条看状态第二条看事件第三条确认 Pod 级 metrics API 有没有返回数据第四条直接看 HPA 的 status 子资源里保存的最近一次计算记录第五条找集群事件最后一条看 metrics-server 自己的日志。这套命令在大多数疑难杂症里都能定位到七七八八。5.7 常见问题速查表现象常见原因快速解法HPA 显示unknown/50%metrics-server 不可用kubectl top nodes验证检查 apiservice一直无法扩容Deployment 容器缺 resources.requests补全 requests.cpu扩容过慢扩容策略限速调整 behavior.scaleUp.policies缩容过快导致抖动稳定窗口太小设置 scaleDown.stabilizationWindowSeconds副本停在中间数不缩PDB 限制中断数量查看 PDB 状态和 maxUnavailable新 Pod 一直 Pending节点资源不足或配额限制kubectl describe pod看事件HPA 状态但无生效副本数ReplicaSet 创建失败kubectl get rs -o yaml看条件这张表没办法覆盖所有情况但能覆盖我实际运维里 80% 的 HPA 问题。剩下那 20%大多和你的自定义指标采集链路有关得从 Prometheus Adapter 的日志和 custom.metrics API 返回结果里一层层往下查。做 Kubernetes 弹性伸缩这几年我自己最大的体会是HPA 本身不是一个“配置完就万事大吉”的组件它像是一个精密的控制系统你给它什么数据它就给你什么行为。指标不准确、request 设置不合理、稳定窗口配置过短都会让它“看起来不太聪明的样子”。如果你能先把 CPU 指标跑通理解期望副本数公式再一步步加上自定义指标和 behavior 控制HPA 就会变成一个非常可靠的自动运维帮手。最后再分享一个小建议任何 HPA 改动上线前都要像改业务代码一样做一次小流量压测毕竟副本数背后都是真金白银的资源账单。