hpa

定义

hpa 是 Kubernetes 中的一项水平扩缩能力，全称 Horizontal Pod Autoscaler，中文译为水平 Pod 自动扩缩器^[1]。它作用于 Deployment、ReplicaSet、StatefulSet 等由控制器管理的工作负载，通过修改其副本数量来应对负载变化^[2]。在 Kubernetes 的术语体系中，「水平扩缩」指增减副本个数，「垂直扩缩」指就地调整单个副本可用的资源，两者是并列的两类手段^[1]。

从实现角度看，hpa 同时是一个 API 资源和一个控制器：资源对象保存目标负载、指标类型、期望值以及副本数上下限等配置，控制器则负责周期性地执行比较和调整^[1]。在命令行工具 kubectl 中，该资源的名称缩写为 hpa，也可以写成 horizontalpodautoscaler。

原理

hpa 控制器按固定周期运行控制循环，每次循环先取得目标工作负载上各 Pod 的指标当前值，再与配置中的期望指标值相除，算出所需副本数^[3]。其基本关系可以写成 $desiredReplicas = \lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \rceil$，即当前副本数乘以「当前指标比期望指标」，结果向上取整^[4]。例如当前指标为 200m、期望值为 100m 时，比值是 2，副本数会翻倍；当前值为 50m 时比值是 0.5，副本数减半^[4]。

按利用率扩缩时，Kubernetes 用 Pod 的实际用量与它的资源 request 相比得出百分比，因此如果容器没有设置相应的 request，该指标的利用率就无法定义，控制器也不会据它采取动作^[5]。当配置了多个指标时，控制器对每个指标分别算出建议副本数，取其中最大的一个作为最终结果。

kubectl get hpa 的输出中会显示当前指标与目标值的对比、最小与最大副本数以及实际副本数，例如形如 0% / 50% 的 TARGET 列。为避免指标小幅波动就触发增删副本，系统引入了一种迟滞机制：只有当当前指标与期望指标的差异超过默认 10% 的容差时，才会真正改变副本数量^[3]。此外，缩容方向通常还保留一个稳定窗口，用较慢的速度回落，以抑制指标快速起伏造成的影响。

在计算平均值时，被删除中的 Pod、暂时取不到指标的 Pod、以及尚未进入 Ready 状态的 Pod 会被区别对待；对缺失指标的副本，系统会保守假设其在扩容时为期望值的 0%、在缩容时为期望值的 100%，从而抑制不必要的扩缩动作。

发展历程

Kubernetes 从 1.2 版起就提供了水平 Pod 自动扩缩功能，早期的实现依赖 Heapster 从监控代理中拉取用量指标，且只能依据 CPU 利用率作出决策^[6]。1.2 版还以特殊注解的方式引入了基于应用自定义指标的扩缩的 alpha 支持，该方法在 1.6 版中被放弃，改用 autoscaling/v2alpha1 API^[7]。

1.6 版起，HPA 可以通过自定义指标 API 获取自定义指标值，前提是在控制管理器上启用相应开关，并把资源指标 API 与自定义指标 API 注册到 API 聚合器^[7]。2016 年末，autoscaling 特别兴趣小组决定重新设计指标采集链路，使扩缩可以基于外部监控系统的任意指标，从而用指标服务器取代了 Heapster 的角色^[6]。

API 版本经历了多次演进：autoscaling/v1 只支持 CPU 一种扩缩指标，autoscaling/v2beta1 增加了自定义指标，autoscaling/v2beta2 增加了外部指标^[8]。v2beta2 于 1.12 版引入、1.23 版标记废弃、1.26 版被彻底删除；autoscaling/v2 自 1.23 版起提供，集群版本低于 1.23 时应继续使用 v2beta2^[9]。从 1.18 版开始，v2beta2 API 允许通过 behavior 字段配置扩容与缩容行为^[9]。

2025 年发布的 Kubernetes 1.33 引入了可配置容差的 alpha 特性，把此前集群范围固定为 10% 的容差改为可以调整，以缓解大规模部署中 10% 容差对应数十个 Pod 而显得过于粗糙的问题^[3]。

应用

hpa 适用于用户需求随时间明显波动的场景，例如 Web 应用、微服务和 API 服务^[2]。配置时通常需要给出目标工作负载、指标类型与期望值，以及 minReplicas 和 maxReplicas 两个副本数边界；以 CPU 利用率为例，可以把平均目标设为 50%，副本数限制在 1 到 10 之间^[10]。用 kubectl 的 autoscale 子命令可以快速创建这类配置。

除 CPU 与内存这类资源指标外，工作负载自身暴露的指标或可从集群外部查询的指标也可以用于扩缩^[10]。这类指标需要相应的适配器支持，例如 KEDA 和 Prometheus 适配器^[10]。当应用瓶颈出现在网络而非 CPU 或内存时，自定义指标往往比资源利用率更能反映真实压力。

在托管 Kubernetes 服务中，云端厂商还提供了基于负载均衡器流量的自动扩缩，把流量利用率信号接入 hpa，作为 CPU 与内存之外的补充信号^[10]。

局限

hpa 只调整 Pod 副本数量，不改变 GKE 等集群中的节点数量。当集群的节点容量已经耗尽时，新增的副本无法被调度，只能停留在 Pending 状态，因此通常需要配合集群层面的节点自动扩缩来补齐算力^[11]。此外，hpa 对本身难以水平拆分的工作负载效果有限，例如单副本的数据库或缓存，增加副本并不能分担负载^[12]。

以 CPU 为目标时，利用率是相对于 Pod 的 CPU request 计算的百分比，而不是相对于节点^[13]。如果 request 设置得远高于真实用量，利用率就始终达不到目标值，扩缩也就不会触发，因此 hpa 的正确运行依赖合理的资源 request^[13]。

hpa 与垂直 Pod 自动扩缩器不应针对同一 CPU 或内存指标同时启用：一方改变副本数、另一方改变 request，会形成反馈回路，导致指标震荡而两个控制器都难以收敛^[12]。可行的组合方式包括让 VPA 只负责内存而 hpa 负责 CPU，或让 VPA 仅输出建议、hpa 使用自定义指标^[12]。

hpa 自身的调节具有滞后性：副本数量的变化在下一个扩缩周期才生效，副本数会滞后于到达率的变动^[14]。同时，按延迟这类症状性指标扩容还可能放大故障，例如数据库变慢导致延迟升高、副本增多、连接数增加，反过来使数据库更慢^[13]。

参见

• Kubernetes —— hpa 是其内置的水平自动扩缩 API 资源与控制器。

• Pod —— hpa 调整的对象，即工作负载中的副本实例。

• Vertical Pod Autoscaler —— 负责垂直调整 Pod 资源 request 的对应组件。

• 集群自动扩缩器 —— 在节点容量不足时补充节点的集群级扩缩组件。

• KEDA —— 基于外部事件源的扩缩组件，在底层生成 hpa 对象。