KEDA还是HPA：扩容快慢往往由指标源决定

事件驱动工作负载该直接使用 HPA，还是引入 KEDA，先看队列等负载指标能否在没有运行中 Pod 时持续提供。已有可靠的外部指标接入，就可以考虑直接使用 HPA；需要 KEDA 的事件触发器和激活阈值，则可以引入 KEDA。KEDA 的扩缩容机制将零副本激活交给 KEDA，工作负载运行后的多副本调节交给它创建的 HPA。

两种方案的速度都受指标何时可见制约。Kubernetes 的 HPA 文档说明，v1.37 起默认启用的 Beta 功能允许使用对象或外部指标的 HPA 缩到零并重新扩容，HPA 控制循环的默认间隔为 15 秒。这个间隔只描述控制器多久查询一次指标；任务到达后，指标发布、Pod 调度、镜像拉取和应用就绪还各自需要时间。

先判断零副本时能否取得指标

如果队列长度已经通过指标适配器稳定提供给 Kubernetes，消费者全部停机后仍能查到队列积压，直接配置 HPA 是一条可行路径。这里的前提不仅是指标源保存了数据，还包括适配器能够返回正确的指标名称、对象范围和新数值。指标在监控系统里可见，却没有通过 Kubernetes 指标 API 返回给 HPA，扩容仍不会发生。

KEDA 适合希望使用现成队列、消息系统或其他事件触发器的团队。ScaledObject 把目标工作负载、触发条件、激活阈值和后续 HPA 所需的扩缩容参数放在同一配置中，减少自行搭建指标适配路径的工作；它并不会让消息系统更早产生指标。若触发器查询的也是更新较慢的上游数据，增加一层控制器不会消除等待。

零副本场景还要区分指标类型。CPU 和内存利用率来自运行中的 Pod；Pod 全部停止后，这类指标无法独自提供唤醒信号。队列积压等对象或外部指标则可以独立于消费者存在。对于较早版本的集群，还需要核实零副本功能门的状态，而不能仅凭 HPA 对象已创建就认定它能自动唤醒工作负载。

零到一：指标出现后，还有激活与启动

KEDA 的零到一过程始于事件源发生变化，而不是始于控制器执行扩容。任务进入队列后，队列或监控系统先要呈现可查询的新值；KEDA 随后查询触发器，判断是否达到激活条件，再修改工作负载的期望副本数。调度器为新 Pod 选择节点，节点取得所需镜像，容器启动并通过就绪检查，消费者才真正能够处理任务。

ScaledObject 参数说明给出的默认触发器轮询间隔为 30 秒，默认回零冷却期为 300 秒；前者影响零副本时 KEDA 发现激活信号的机会，后者用于触发器停止活跃后等待缩回零副本。它们都是配置间隔，不能直接当成任务进入队列至 Pod Ready 的耗时。任务恰好在一次轮询之后到达，与恰好在轮询之前到达，等待下一次查询的时间也不同。

直接使用具备零副本能力的 HPA 时，事件源仍须先通过对象或外部指标 API 提供新值，HPA 才能在控制循环中计算期望副本数。KEDA 的触发器可能直接查询事件源，HPA 的适配器也可能直接取得同一数据；究竟哪条路径先作出决定，取决于实际查询链路和指标更新方式。两条路径修改副本数之后，都要经历调度与应用启动，因而“开始创建 Pod”和“Pod 已可处理任务”应分别计时。

一到多：决定副本数的仍是 HPA

已有运行中的副本时，KEDA 向它创建的 HPA 提供指标和目标值，由 HPA 根据取得的指标计算需要多少副本。KEDA Metrics Server 默认在收到 HPA 的指标请求后查询相应触发器；启用指标缓存会改变取值路径，使 HPA 的查询可能读到缓存值。缓存能减轻对指标服务的查询压力，也意味着必须检查缓存更新间隔是否适合业务对响应速度的要求。

因此，单纯缩短 ScaledObject 的触发器轮询间隔，不能推断一到多的扩容决定会同样提前。这个阶段要看事件源的新值何时形成、指标服务何时返回它，以及 HPA 下一次查询何时到来。如果期望副本数迟迟不变，应先对照指标 API 的返回值和 HPA 状态；如果期望副本数已经上升、可用副本却没有跟上，重点便转向调度、节点容量、镜像拉取和就绪检查。

还要区分“指标值正确”和“指标适合扩容”。队列长度能表示待处理工作量，但每条任务的处理时间可能不同；只按条数设目标值，未必能准确反映消费者的实际负担。这是阈值与工作负载模型的问题，调整控制器的查询频率不能代替它。比较两种方案时，应保持工作负载和扩容目标一致，否则副本增长幅度的差异也会混进速度结果。

指标源的时间粒度不能算在控制器头上

以 CloudWatch 为例，AWS 的指标分辨率说明把标准分辨率定义为一分钟粒度，并允许高分辨率自定义指标达到一秒粒度。分辨率描述数据点的时间粒度，不等同于某条队列指标的固定发布延迟，也不能单独推出一次扩容要等多久。发布频率、聚合周期、查询设置和指标适配器都会影响新负载何时被控制器看见。

例如，若一条路径直接查询队列状态，另一条路径先等待监控系统发布并聚合队列指标，再交给适配器，两条路径比较到的就是完整指标链路。较慢路径中的等待不能全部归因于 HPA；同样，直接查询队列的路径较快，也不足以证明 KEDA 的控制循环在相同输入下更快。只有让两种配置读取同一指标源，才较容易单独观察控制器与适配器带来的差别。

排查时，把“消息已入队”“指标源首次返回新值”“Kubernetes 指标 API 首次返回新值”分开记录，能看出等待发生在发布、适配还是控制阶段。若三者被合并成一个开始时间，调低轮询间隔后即使结果没有变化，也难以判断是控制器设置无效，还是上游指标始终没有更新。

缩容：多副本稳定窗口与回零冷却期各管一段

负载回落时，已有多个副本缩到较少副本，仍由 HPA 调节。HPA 的缩容稳定窗口会参考此前的副本建议，避免指标短暂下降就立即删除工作副本。使用 KEDA 且允许缩到零时，最后回到零副本还要经过 KEDA 的触发器失活判断及回零冷却期。这些设置作用于不同阶段，修改回零冷却期不会改变 HPA 对多副本阶段的全部缩容行为。

对队列消费者，副本减少还涉及正在处理的任务。控制器可以决定减少副本，却不能保证被终止的 Pod 恰好没有进行中的任务。应用仍需正确处理终止信号、任务确认和必要的重试。测量缩容时，分别记录队列清空、指标回落、期望副本数下降以及最后一个 Pod 退出的时刻，才能看清稳定窗口、冷却期和应用退出过程各占多久。

在自己的集群复测两条扩容时序

可复现的比较应固定工作负载镜像、资源请求、就绪检查、节点容量、触发阈值和任务投放方式，再分别测零到一与一到多。若目的是比较控制路径，尽量让两种方案读取同一来源、同一含义的指标；若目的是在两套实际部署方案中选型，就保留各自真实的指标链路，并在结果中写明差异。不要把控制器设定的轮询间隔直接当作实验结果。

1. 让空闲工作负载由自动扩缩容机制降到零，再投放可重复的任务负载。Kubernetes 的零副本配置说明指出，手动把目标工作负载设为零与 HPA 自行缩到零的状态不同；前者可能使 HPA 停止自动调节，因此不能用来代替正常的回零过程。
2. 记录任务进入事件源、源指标首次可查询、Kubernetes 指标 API 首次返回新值、期望副本数改变、Pod 获得调度、镜像拉取完成和 Pod 进入 Ready 的时间。记录查询失败与重试，不只保留成功且最快的一次。
3. 让工作负载保持一个运行副本，重复相同的负载增长过程，单独观察一到多。负载回落后，再记录多副本缩容与最后回零的时刻，避免把扩容和缩容的控制规则混为同一段延迟。

整理结果时，至少分出“任务出现至指标可见”“指标可见至期望副本数变化”“期望副本数变化至 Pod Ready”三段。第一段指向事件源发布、聚合或适配；第二段指向触发器、指标查询与控制循环；第三段指向调度、镜像和应用启动。这样得到的数字才能回答选型问题：现有 HPA 指标链路是否已经足够及时，以及引入 KEDA 后究竟改变了哪一段等待。

相关阅读：

• MySQL还是PostgreSQL：跑分差距不该替你做架构决定
• OpenTofu还是Terraform：速度几乎打平，状态加密才拉开差距
• TubeBuddy还是vidIQ：搜索量都是估算，分数差距未必有意义