HPA 按负载缩放 Deployment 的副本

Wed, 11 Aug 2027 00:00:00 +0000

HorizontalPodAutoscaler 是反馈控制器，不是容量规划器，默认同步间隔为十五秒。根据配置，它读取资源、自定义或外部指标，再更新工作负载的 scale 子资源。基本计算为 desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)，之后还要考虑缺失数据、就绪状态、容忍度、稳定窗口及上下界，不能只靠这一行公式预测全部实际行为。

一份看起来正确的 HPA 对象，不证明容量必然及时到位。指标可用性、请求、副本上限、调度及应用启动都会影响结果。应分别查看建议副本数与真实就绪容量；提高期望数量不会制造新节点，也不能自动修好受阻发布。判断伸缩是否有效，必须跟踪从指标到应用接流量的整段过程。

原文算术示意，不是观察到的伸缩事件。保留的 Kubernetes 只读诊断仍为受阻，本次未重跑。建议四个副本不证明四个 Pod 已就绪或应用容量充足。

比值与死区

CPU 利用率目标把实际 CPU 用量与相关请求比较，得到百分比，目标本身也是百分比。如果每个 Pod 只有一个容器，都请求 200m，目标为百分之六十，那么每 Pod 120m 是便于理解的简化等价值。它不是异构 Pod 或所有指标类型通用的分母；多个容器和不同请求会改变聚合结果。

集群默认容忍度为一附近的 0.1。Kubernetes 1.34 的分方向容忍度仍为默认关闭的 alpha 功能；不能假定每个 HPA 都能覆盖它，要先检查特性开关和控制器配置。应把它理解为控制死区，而不是承诺 132m 永不伸缩、133m 必然动作。指标聚合、整数利用率、就绪状态及实现中的算术都会影响边界。忽略其他修正时，三个副本以 160m 对比 120m 目标，会建议四个副本；舍入、速率策略与最终能否调度仍需分别观察，不能从一个毫核数字直接推出真实扩容时刻。

缺失指标与一票否决

缺失 Pod 指标采用保守处理。Kubernetes 1.34.0 的 GetResourceReplicas 在缩容时，把缺失样本补为该 Pod 的资源请求乘以 max(100%, 目标利用率)；普通逐 Pod 指标分支 calcPlainMetricReplicas 则使用目标量。两者扩容时都补零。因此，请求 200m、目标利用率 60% 时，缩容替代值是 200m，而不是 120m。重新计算可能取消动作；状态中显示的利用率仍基于原有可用样本，不包含这些保守假定。CPU 对尚未就绪的 Pod 还有额外处理，涉及可配置的就绪延迟与初始化窗口。这些规则围绕启动采样及就绪变化，不表示所有 Pod 都一律被忽略整整五分钟。诊断时应查看实际采样和状态时间，不能把默认窗口当成一个简单倒计时。

CPU 利用率计算需要相关资源请求；即使 kubectl top 能报告用量，缺失 request 仍可能让该指标不可计算。配置多个指标时，HPA 选择最大的建议副本数；一个不可用指标可能阻止缩容，另一个有效指标却仍能支持扩容。因此，缺一个来源不代表整个控制器必然停止，必须结合每个指标的结果和状态条件解释。

稳定窗口与速率限制

默认缩容会考虑五分钟建议窗口，并选取其中仍相关的最高建议，以减轻振荡。这不是从外部负载曲线回落开始严格等待五分钟的保证。建议记录、当前副本、上下界和行为配置共同决定何时缩减。默认扩容稳定窗口为零，但用户可以修改行为；没有稳定窗口也不表示完全没有同步、采样和启动延迟。

默认扩容速率策略允许十五秒内增加四个 Pod 或当前数量的一倍，取允许变化较大的策略。默认缩容策略可允许在其周期内全部减少，但仍受到稳定窗口和最小副本数限制。这是允许速率，不是自动按一、五、十不断增长的命令。指标必须要求相应扩容，maxReplicas 仍会封顶，新增副本还要经过实际调度与就绪过程。

坏掉的样子

利用率 unknown 可能来自缺失请求、指标不可用、授权问题或其他获取与计算错误。应读取 ScalingActive 及其原因，不能把 unknown 直接当作没有 CPU 样本的证明。需要检查所有相关容器，只查第一个容器不能确定整份 Pod 的分母；同时还要核对准入默认值与实际 HPA 指标类型。

达到 maxReplicas 的工作负载，即使控制器正确执行配置，也可能继续过载。ScalingLimited 能说明数量受限，但容量规划还需要节点空间、启动延迟和下游承载能力。提高上限可能只制造更多 Pending Pod，或压垮共享依赖。宣布自动伸缩成功前，应比较期望副本、可用副本与服务延迟，不能只看到 desired 数字增加就认为问题解决。

快速验证

以下保留的只读诊断本轮没有重新执行。请明确选择获准测试集群和命名空间，并把简略输出与完整 HPA、所有相关容器一起核对。

确认指标存在、分母存在，以及控制器到底决定了什么：

kubectl get hpa web -o wide
kubectl top pods -l app=web
kubectl get deploy web -o jsonpath='{.spec.template.spec.containers[0].resources.requests.cpu}{"\n"}'
kubectl get hpa web -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'
kubectl describe hpa web | sed -n '/Events/,$p'

第一行给出当前利用率对目标利用率；这一列显示 <unknown>，说明所需值未能建立，并不必然表示原始用量样本缺失。第三条在没有 CPU request 时什么都不打印，而这正是第二条能跑通、HPA 却仍拒绝伸缩的常见原因。最后两条给出状况原因和 FailedGetResourceMetric 事件，真正的解释在那里。

来源

Horizontal Pod Autoscaling，算法、容忍度、缺失指标处理、稳定窗口与默认策略，已核验 2026-10-15。
HPA walkthrough，对 metrics-server 与 requests 的依赖，已核验 2026-10-15。
metrics-server，HPA 读取的 resource metrics API 实现，已核验 2026-10-15。
Kubernetes 1.34 HPA，按版本限定的容忍度与缺失指标保守处理，已核验 2026-10-18。
Kubernetes v1.34.0 副本计算实现，区分资源利用率与普通逐 Pod 指标的缺失样本替代，已核验 2026-10-18。