Kubernetes HPA 水平自动伸缩配置

可视化演示

展示Kubernetes HPA控制器的指标采集、期望副本数计算和Pod伸缩调整全流程，以及GPU自定义指标与伸缩策略调优。切换模式查看不同环节。

1. HPA基础概念：餐厅经理的“动态排班”

想象你是一家热门餐厅的经理。你手下有一队服务员，客流高峰时忙得脚不沾地，客流低谷时闲得刷手机。你的直觉告诉你：不能固定排班，得看客流动态调人。但具体怎么调？你需要一个稳定的规则：门口排队超过 20 人就加一个人，排队少于 5 人就让一个人先下班。这个规则，就是 HPA 的雏形。

在 Kubernetes 中，运行 AI 推理服务的应用通常打包成一个或多个 Pod。Pod 就像餐厅的服务员，同一个 Deployment 里可以有多个完全一致的 Pod 副本，共同分担用户请求。而 HPA（Horizontal Pod Autoscaler，水平 Pod 自动伸缩器） 就是那位聪明的餐厅经理——它周期性检查 Pod 的运行指标，发现“忙不过来”就自动增加副本，“太清闲”就自动减少副本。整个过程全自动，无需人工干预。

HPA 的核心是一个内置控制器（kube-controller-manager 的一部分），它通过 Kubernetes 的 Metrics API 读取指标数据，再用一个简单的公式算出期望副本数。它管理的对象非常明确：Deployment、StatefulSet、ReplicaSet 这类带有“副本”概念的控制器。与之相对的是 VPA（Vertical Pod Autoscaler）——如果说 HPA 是“加人或减人”，VPA 就是“给每个人发更大份的活儿”（调大 CPU/内存资源配额）。

你看，HPA 的工作方式并不神秘——就是经理盯着客流（指标），按照既定规则算人头，然后淡定地调整排班表。但这位经理从不休假，7×24 小时盯着，一分钟都不松懈。

2. 指标来源：经理的“客流情报网”

餐厅经理要准确排班，光靠感觉不行，得有数据。看什么数据？门口排队人数是最直观的，但还不够——还要看入座率、翻台率、外卖订单量。不同的数据源从不同角度反映客流态势。HPA 也一样，它有一张“指标情报网”。

CPU 利用率是 HPA 最常用的指标，也是默认指标。它计算的是 Pod 实际使用的 CPU 相对于 requests（资源请求量）的百分比。为什么强调 requests？因为 Kubernetes 的调度器以 requests 为 Pod 分配节点资源，HPA 以它为分母计算利用率，两者口径一致才公平。

内存消耗是第二个内置指标。内存不像 CPU 那样可以被“压缩”，用满了就可能触发 OOM 被杀，所以内存指标对某些应用至关重要。不过 HPA 对内存偏高的响应是“扩容”，它无法通过限制来压低内存占用，使用时需要格外注意。

自定义指标是 HPA 的“万能接口”。如果 CPU 和内存都无法反映业务真实负载（比如队列积压、响应延迟、GPU 利用率），你可以通过 Kubernetes 的 custom.metrics.k8s.io API 暴露任意指标。对 LLM 推理服务来说，GPU 利用率就是典型场景——GPU 是稀缺且昂贵的资源，只有 GPU 利用率能真实反映推理服务的繁忙程度。

有了这些“情报”，HPA 就能像经理一样做到心中有数。但情报再多，最终都要落到排班计算上——我们下一节看看经理怎么用公式决定人手。

3. 伸缩算法：从客流到人手的“排班公式”

经理拿到客流数据后，开始心算：现在有 20 桌客人在等位，每位服务员最多同时照顾 5 桌，那至少需要 4 个人。HPA 的伸缩算法也是这个道理，只不过它算得更精细，还有上下限保护，避免忙时无人可用、闲时人浮于事。

HPA 的完整算法公式融合了上下限约束：

其中 avgMetric 是所有 Pod 的平均指标值。公式的核心思想是比例缩放：平均负载越高，副本数越多，但结果必须落在最小副本数和最大副本数之间。

实际配置中，minReplicas 通常设为 1 或 2（保证基础可用性），maxReplicas 根据集群资源估算。比如你的 GPU 集群最多能同时跑 8 个推理实例，max 就设为 8。

除了上下限，HPA 还有单次调整限制，防止副本数“大起大落”。默认策略下，扩容一轮最多翻倍（每 15 秒评估一次），缩容一轮最多减半（每 5 分钟评估一次）。这就像经理不会因为瞬间涌入 100 个客人就立刻招 50 个新人——先让在班的人顶上，确认客流持续增长再逐步加人。

4. 自定义指标适配器：给餐厅装“外卖订单统计器”

普通餐厅看排队和入座就够了，但如果你开的是“外卖为主”的网红店，线下客流根本不能反映真实订单量。你得装一个外卖平台的数据统计器。对 LLM 推理服务来说，CPU 和内存常常不能反映 GPU 的繁忙程度——GPU 利用率才是决定服务质量的关键指标，而它需要一个专门的“统计器”。

这个统计器就是 prometheus-adapter（Prometheus 适配器）。它的工作流程是：先由 Prometheus 监控系统采集集群中的各种指标（包括 GPU 利用率），再由 prometheus-adapter 把这些指标通过 Kubernetes 的 custom.metrics.k8s.io API 暴露给 HPA。有了这个适配器，HPA 就能读取“自定义指标”并做出伸缩决策了。

在 GPU 场景中，通常还需要 DCGM exporter（NVIDIA 官方 GPU 监控工具）来采集 GPU 利用率，把数据喂给 Prometheus。整个链路是：GPU → DCGM exporter → Prometheus → prometheus-adapter → HPA → Deployment。这条链上的每一环都缺一不可。

prometheus-adapter 的核心是配置发现规则（discovery rules），告诉它“哪些指标可以用、怎么把 Prometheus 的查询结果转换成 HPA 能读的格式”。常用的 GPU 指标表达式类似这样：

装了这套“外卖统计器”，HPA 就能在 GPU 跑满时及时扩容、GPU 空闲时及时缩容。对于大模型推理服务来说，这一步是成本优化的关键——毕竟 GPU 按小时计费，空转一秒都是钱。

5. 冷却与调优：经理的“稳一稳”决策

新人经理最常犯的错是什么？看到门口排队人数刚多起来，立刻抓起电话叫所有休班员工回来；十分钟后队伍短了，又让刚到的员工回去。结果员工来回折腾，怨声载道，排班表乱成一团。成熟经理的做法是：先观察几分钟，确认客流是持续上升还是偶然波动，再动手。

HPA 也有同样的“冷静机制”，称为冷却时间（cooldown）。核心参数是 stabilizationWindowSeconds（稳定窗口期）——它决定 HPA 在改变副本数之前，需要持续观察多长时间。默认缩容的稳定窗口是 300 秒（5 分钟），意味着“负载偏低”这个信号要持续 5 分钟才会触发缩容；扩容的窗口通常较短或为 0，因为缺人是紧急事件，越快响应越好。

除了稳定窗口，Kubernetes 从 v1.18+ 还引入了速率限制，进一步防止副本数剧烈波动。默认的扩容策略是“每 15 秒最多翻倍”，缩容策略是“每 5 分钟最多减半”。也就是说，即使负载暴增，HPA 也不会一次从 2 个 Pod 跳到 100 个——它会先到 4，再到 8，每步留出缓冲，避免压垮集群调度器。

这些参数在 HPA 的 behavior 字段中可以灵活配置。对于 LLM 推理服务，建议扩容窗口短（快速响应突增请求）、缩容窗口长（避免 GPU 实例频繁启停）。调优的核心思想是：响应要快，变化要稳——像经验丰富的经理一样，看到趋势再行动。

6. 实战配置：把排班制度写成正式手册

餐厅经理有了成熟的排班规则，会把它写成正式的员工手册，让每个值班经理都能按章执行。HPA 也一样，Kubernetes 用声明式配置（YAML 文件）来定义伸缩规则——写清楚指标、目标值、副本上下限、冷却行为，然后提交给集群，控制器自动执行。

一个完整的 HPA 配置（基于 autoscaling/v2 API）长这样：

这个配置表示：管理 llm-inference Deployment，副本数保持在 2 到 8 之间；当 CPU 平均利用率超过 60% 或 GPU 利用率超过 70 时扩容；扩容观察 30 秒，缩容观察 300 秒。

配置好之后，用这些命令验证：

get 看当前状态（副本数、目标/当前指标），describe 看详细事件和条件。排查问题时，重点关注 Events 段——HPA 会把“无法读取指标”“超出最大副本数”等异常记录在这里。另外，用 kubectl top pods 确认指标采集是否正常，一旦发现 unknown 状态，多半是 metrics-server 或 Prometheus 适配器没就绪。

YAML 手册写得越清晰，HPA 执行得越稳定。把排班规则固化下来之后，你的推理服务就真正实现了“随客流自动调人”的弹性能力。

apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata:  name: llm-inference-hpaspec:  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: llm-inference  minReplicas: 2  maxReplicas: 8  metrics:    - type: Resource      resource:        name: cpu        target:          type: Utilization          averageUtilization: 60    - type: Pods      pods:        metric:          name: gpu_utilization        target:          type: AverageValue          averageValue: "70"  behavior:    scaleUp:      stabilizationWindowSeconds: 30    scaleDown:      stabilizationWindowSeconds: 300

kubectl get hpakubectl describe hpa llm-inference-hpa

AI 应用场景

Python 演示

import mathimport randomimport time  def hpa_desired_replicas(current_replicas, total_load, target_load):    """HPA 核心算法：计算期望副本数"""    if current_replicas == 0:        return 1    avg_load = total_load / current_replicas    ratio = avg_load / target_load    return math.ceil(current_replicas * ratio)  def clamp_replicas(desired, min_replicas, max_replicas):    """将期望副本数限制在 min/max 范围内"""    return max(min_replicas, min(max_replicas, desired))  def simulate_hpa(seconds=60, min_replicas=2, max_replicas=8, target_load=50):    """模拟负载变化下 HPA 的扩缩容全过程"""    replicas = min_replicas    cooldown = 0    print("时间(s) | 总负载 | 平均负载 | 期望副本 | 实际副本")    print("-" * 60)    for t in range(seconds):        total_load = 30 + 25 * math.sin(t * 0.1) + random.uniform(-5, 5)        total_load = max(5, total_load)        if cooldown > 0:            cooldown -= 1            desired = replicas        else:            desired = hpa_desired_replicas(replicas, total_load, target_load)            desired = clamp_replicas(desired, min_replicas, max_replicas)            if desired != replicas:                cooldown = 5        avg_load = total_load / replicas        if t % 5 == 0:            print(f"{t:7d} | {total_load:6.1f} | {avg_load:8.1f} | {desired:6d} | {replicas:6d}")        replicas = desired        time.sleep(0.05)    return replicas  if __name__ == "__main__":    simulate_hpa(seconds=80)

1. avg_load = total_load / current_replicas计算每个 Pod 的平均负载，这是 HPA 判断“忙不忙”的依据。
2. ratio = avg_load / target_load平均负载与目标值的比值，大于 1 说明需要扩容，小于 1 说明可以缩容。
3. return math.ceil(current_replicas * ratio)按比例缩放并向上取整，得到期望副本数。
4. clamp_replicas(desired, min_replicas, max_replicas)把期望副本数限制在 min 和 max 之间，对应 HPA 的上下限保护。
5. cooldown = 5每次调整副本数后进入 5 个时间步的冷却期，模拟 HPA 的稳定窗口。
6. if t % 5 == 0:每 5 个时间步打印一次状态，方便观察整个过程。

常见误区

面试题