把队列积压量变成扩容信号：KEDA 事件驱动弹性在 Kubernetes 上的成本账

把队列积压量变成扩容信号：KEDA 事件驱动弹性在 Kubernetes 上的成本账

很多做异步消费的系统都有一个反直觉的现象：消费者组总是在大促或者凌晨批量任务到来的时候「欠账」，队列深度一路往上飙，处理跟不上；可到了白天业务平淡的时候，那几个写死的消费者副本又在那儿空转，CPU 几乎为零，却在实打实地烧钱。这不是个别团队的配置失误，而是「把副本数写死」这种朴素做法绕不过去的矛盾——你要么为峰值预留一堆平时用不上的算力，要么为了省钱压低副本数，结果一遇到突发行情就处理不过来，消息堆积、消费滞后、最终超时回滚。

KEDA 的思路很直接：别再盯着 CPU 和内存这种「滞后指标」去猜要扩多少，直接拿队列里还没消费的消息量、Kafka 的消费滞后（consumer lag）、或者 Redis Stream 里待处理条目数，当作扩容信号。队列越深，副本越多；队列空了，副本可以缩到零。这套逻辑把「积压量」和「算力」绑在同一条因果链上，于是弹性伸缩第一次真正贴近了消息中间件的真实负载，而不是去猜容器资源够不够。

但把积压量变成扩容信号这件事，表面看只是改几个配置，背后其实是一笔要算清楚的账：KEDA 能省下多少空转成本、又会因为冷启动和抖动带来多少隐性开销、以及它和原生 HPA、Knative、云函数之间到底把钱花在了哪一刀。这篇文章就沿着这条成本链，把选型、字段、触发器、坑和预算天花板一件件拆开讲。

为什么写死的副本数既撑不住峰值也省不下钱

先说写死副本数为什么两头不讨好。假设你给一个订单消费者固定开 10 个副本，平时队列是空的，这 10 个 Pod 除了占着调度名额和内存什么活都不干，按量计费的集群里这其实就是纯浪费；可一旦大促来了，瞬时涌入几万条消息，10 个副本的处理能力如果跟不上入队速度，滞后只会越积越多，你又得临时手动调大，等你想起来调的时候超时已经发生了。

更隐蔽的问题是：队列消费者是典型的 I/O 密集型角色。一个消费者在等消息、拉取、落库的时候，CPU 经常是躺平的。于是你用 CPU 利用率去判断该不该扩容，会看到一张「很健康」的监控图——CPU 才用了 5%，一切正常——可实际上队列后面已经排了上万条消息没人处理。指标很漂亮，业务在崩。这就是「用错误的信号做伸缩，比不伸缩更危险」的真实写照：图看起来没事，账在背后烂掉了。

所以真正该被监控的，是「还差多少活没干完」，也就是队列深度或者消费滞后，而不是「现在忙不忙」。把副本数和这个差值挂钩，才能做到峰值来了一秒拉起、谷值来了自动归零。这恰好是原生 HPA 默认能力够不着的地方，也是 KEDA 存在的根本理由。

KEDA 到底解决了 HPA 管不到的那块：事件源与扩缩依据

要讲清楚 KEDA 的价值，得先划清它和原生 HPA 的边界。Kubernetes 自带的 Horizontal Pod Autoscaler 是个纯粹的控制循环，稳定 API 是 autoscaling/v2，它能基于 CPU、内存这类资源指标，或者你额外接好的自定义指标、对象指标、外部指标来做扩缩。问题在于：想让它「看懂」Kafka 的消费滞后、RabbitMQ 的队列长度、AWS SQS 的待处理消息，你得自己先搭一套 metrics adapter（最常见的就是 Prometheus Adapter），把外部系统的状态翻译成 HPA 能消费的指标。每个事件源都要单独接，工程量和维护负担都不小。

另一个硬限制是缩容下限。原生 HPA 默认最小副本数是 1，换句话说，只要这个工作负载还存在，它就永远至少占着一个 Pod，哪怕连续几天队列都是空的。Kubernetes 文档里提到通过 HPAScaleToZero 这个特性开关、并且配合至少一个对象或外部指标，才有可能把 HPA 缩到零，但这个前提条件本身就说明：缩到零不是 HPA 开箱即用的能力。

KEDA 做的事，是站在 HPA 外面再包一层。它本身不重新发明扩缩算法，而是充当「事件源翻译官」：它内置了 60 多个 scaler，知道怎么去问 Kafka「你滞后多少」、去问 RabbitMQ「你队列里几条」、去问 Redis Stream「你消费组还有多少待处理」；然后把这些信号喂给一个由它自己创建并管理的 HPA。官方文档里反复强调的分工是：KEDA 负责从零到一的「激活」（也就是缩到零、来活了再拉起来），HPA 继续负责从一到 N 的常规扩缩。KEDA 给这个工作负载生成的 HPA 名字默认是 keda-hpa-。

这里有个必须记牢的红线：千万不要在同一个 Deployment 上既手写一个 HPA、又挂一个 KEDA 的 ScaledObject。两个控制器会抢着改 replica 数，结果就是无休止的反复横跳。KEDA 自己会建 HPA，把这一层交给它管就好。另外从反应速度看，HPA 默认的控制循环同步周期是 15 秒，而 KEDA 默认轮询间隔是 30 秒——对于纯 CPU 类指标，HPA 裸用其实反应更快，所以别为了「看起来高级」而硬上 KEDA，这是后面会反复提到的一条取舍原则。 还有一个原生 HPA 的隐性约束值得一提：Kubernetes 一个集群里通常只允许注册一个 Custom Metrics API（以及对应的 adapter），这意味着如果你想让 HPA 直接吃多个外部事件源，adapter 之间很容易打架；KEDA 则自己充当 metrics provider，把外部指标通过 external.metrics.k8s.io 暴露给由它管理的 HPA，相当于把冲突点收敛到了一处。顺带说一句，KEDA 已经是 CNCF 的 graduated（毕业）项目，生产成熟度本身不是问题，真正要花心思的是配置和凭据，而不是「它靠不靠谱」。这也解释了为什么很多团队把 KEDA 当成事件驱动伸缩的默认底座——它不是玩具，而是一层已经被大规模验证过的、薄薄的翻译层。

ScaledObject 里真正要拍板的几个字段：min/max、轮询、冷却窗口

KEDA 的核心配置对象叫 ScaledObject，apiVersion 是 keda.sh/v1alpha1。它字段不少，但日常真正需要你拍板的就那么几个。先把最常用的一列出来：scaleTargetRef 告诉 KEDA 要伸缩谁（name 必填，且必须和 ScaledObject 同命名空间，可选指定 apiVersion 和 kind，默认是 Deployment）；pollingInterval 是 KEDA 去轮询事件源的频率，默认 30 秒；cooldownPeriod 是「最后一个触发信号消失后，等多久才缩回零」，默认 300 秒（5 分钟），而且这个冷却期只作用于「缩到零」这一步，从一到 N 的缩放由 HPA 接管；minReplicaCount 默认 0，设成 0 就打开了 scale-to-zero；maxReplicaCount 默认 100，是副本上限；triggers 是触发器列表，一个 ScaledObject 可以挂多个触发器，KEDA 会取所有触发器算出的最大推荐副本数。

除了这几个，还有几个值得留意的可选字段。initialCooldownPeriod 控制 ScaledObject 刚创建时多久才开始走冷却逻辑，默认 0，对于启动阶段不想立刻被缩零的场景很有用。idleReplicaCount 是「空闲副本数」，比 minReplicaCount 更低的保底值，适合白天有流量、深夜想压到极低的场景。fallback 段用来应对「事件源连不上了怎么办」：你可以设定 failureThreshold（连续失败几次触发）和 replicas（失败时固定钉在多少副本），避免指标源挂掉后 KEDA 直接冻结在当前副本数不动。advanced 段里的 restoreToOriginalReplicaCount 决定删掉 ScaledObject 后是否还原原始副本数。

horizontalPodAutoscalerConfig 是最容易被忽略、却最能影响账单的一段。它允许你直接改写 KEDA 生成的那个 HPA 的行为，比如设置 scaleDown 的 stabilizationWindowSeconds（稳定窗口，默认 300 秒）和 policies（比如一次最多缩多少百分比）。这个字段和 cooldownPeriod 配合，决定了你的副本在「缩」这件事上有多「黏」——黏得不够，队列一抖副本就跳；黏得太狠，又可能该缩不缩、空转烧钱。还有几个 annotation 值得知道：scaledobject.keda.sh/transfer-hpa-ownership 可以把已有 HPA 的所有权转交给 ScaledObject；autoscaling.keda.sh/paused 能让你在不删配置的情况下暂停自动伸缩，排障时很实用。 还有一组和伸缩本身无关、却直接决定生产稳不稳的字段：TriggerAuthentication 和集群级的 ClusterTriggerAuthentication。它们把事件源的凭据从 ScaledObject 里解耦出来——你不必把 broker 的账号密码写死在触发器 metadata 里，而是引用一个指向 Kubernetes Secret、环境变量、或者云厂商工作负载身份（AWS IRSA、Azure Workload Identity、GCP Workload Identity）乃至 HashiCorp Vault 的认证对象。ClusterTriggerAuthentication 更进一层，允许跨命名空间复用同一套凭据，对多团队共享一套 Kafka 或 RabbitMQ 的场景非常省事。再补一个很多人不知道的点：一个 ScaledObject 可以挂多个触发器，KEDA 会分别算出每个触发器推荐的副本数、然后取最大值——所以你完全可以把「队列深度」和「CPU 利用率」同时作为伸缩依据，让事件驱动和资源利用两条信号互为补充，而不是二选一。这也意味着多触发器并非免费，每多一个触发器就多一份轮询和指标计算开销，触发器数量要克制。

常见触发器怎么选：Kafka、RabbitMQ、Redis Streams 各自适合什么负载

触发器选型直接决定了你这套弹性伸缩在生产里稳不稳。下面这张表把最常见的几个触发器放在一起对比，扩容依据、冷启动代价和配置注意点都列出来，方便照着对号入座。

落到选型判断上：Kafka 触发器是生产里最成熟、被引用最多的那一类，它会按每个分区的消费滞后来算副本，哪怕 12 个分区滞后分布极不均匀也能正确分摊，用纯 HPA 加自定义指标去复刻这套逻辑工作量很大。RabbitMQ 触发器同样是一等公民，按队列长度伸缩，支持 value 和 activationValue 两个阈值，配置语义清晰，适合绝大多数任务队列场景。Redis Streams 触发器相对「年轻」一些——公开资料显示它大约随 KEDA v2.12（2025 年 10 月）引入，并且支持 Redis Cluster 与 Sentinel 拓扑，目前已经可用于生产，但部署时务必确认你的 KEDA 版本包含该 scaler，避免字段不识别。

HTTP 触发器走的是 KEDA 的 HTTP Add-on，这是个独立的子项目，不随核心 operator 默认装上，需要单独部署，适合请求驱动的 Web 服务；Cron 触发器则完全不依赖事件源状态，按时间表把副本钉到指定数量，特别适合「我知道每天上午九点必有一波高峰」这种可预测负载，而且它能和事件触发器叠加使用，比如白天用 Cron 保底、深夜交给队列深度来决定。需要提醒的是，具体版本里某个 scaler 的字段细节会有差异，配置前以你实际部署版本的官方文档为准。 补充两个触发器层面的真实成本细节，这直接关系到你设的阈值合不合理。Kafka 按消费滞后伸缩时，每加一个消费者 Pod，往往会触发一次分区再均衡（partition rebalance），这个过程中相关分区会短暂停止消费，频繁横跳的副本数等于在不断制造再均衡开销；所以 Kafka 场景下的副本抖动代价比 RabbitMQ 更高，cooldown 和稳定窗口要设得更「黏」，别像 HTTP 服务那样追求秒级响应。Redis Streams 则依赖消费组（XREADGROUP）来追踪待处理条目，如果消费者异常退出、消息没被确认（ACK），那些条目会一直挂在 pending 里，KEDA 看到的「待处理数」下不去，副本也就不会缩——这和消息有没有真正被处理是两件事，监控时要把 pending 条目数和实际吞吐量分开看，否则你会误以为「还有活干」而一直养着一堆副本。

冷启动代价被很多人算漏了：从零拉起消费者要多久

scale-to-zero 看起来很美——队列空了就一个 Pod 都不留，账单直接归零。但很少有人把「从零拉起」的成本算进这笔账。一个 Pod 从调度、拉镜像、到应用真正连上 broker 开始消费，公开经验数据普遍在 30 到 90 秒这个区间；如果你的消费者镜像很大、启动还要做连接池预热或者加载本地缓存，这个时间只会更长。这意味着：每一次缩到零之后再被唤醒，第一批消息都要等这几十秒才能真正开始被处理。

这就引出一个很现实的条件判断。如果你的业务对首条消息的延迟不敏感（比如离线的报表汇总、图片转码、日志归档），那 scale-to-zero 省下的空闲成本远大于偶尔的冷启动等待，闭眼开 minReplicaCount: 0 没问题。但如果你的消费者服务于同步体验——比如用户下单后期望秒级收到处理结果——那么把 minReplicaCount 设成 0 就是在拿 SLA 换账单，这时候更稳妥的做法是保留 minReplicaCount: 1 甚至更高，用「永远有一个热副本」去消掉冷启动那一刀，代价只是多养一个常驻 Pod。

冷启动还和 KEDA 的轮询节奏叠加。KEDA 默认 30 秒才去问一次事件源有没有活，再加上 Pod 拉起本身的几十秒，极端情况下一条消息从入队到被处理可能要等上一分多钟。想要更灵敏，可以把 pollingInterval 调小到 15 秒，代价是 KEDA 控制面的轮询开销上升；集群里 ScaledObject 特别多的时候，这部分开销也不能忽略。 冷启动的实际耗时还和两个容易被忽视的因素有关。一是镜像是否已在节点本地缓存：如果目标节点上已经有该消费者镜像，省掉拉取这一步能砍掉一大截启动时间；反之跨节点调度到一个干净节点，光拉镜像就可能十几秒到几十秒。二是就绪探针（readinessProbe）和启动探针（startupProbe）的阈值——KEDA 和 HPA 只认「Ready 的 Pod 数」，如果你的探针要等连接池预热、本地缓存加载完成才返回健康，那么即便 Pod 已经调度起来，也要等探针通过才被计入有效副本，实际生效的扩容比理想情况更慢。把启动依赖做轻、探针设合理，是压缩冷启动隐性成本最直接的手段，远比单纯调小 pollingInterval 来得实在。

和 Knative、云函数比，KEDA 把钱花在哪一刀

讲到事件驱动弹性，绕不开另两个常被拿来比的方案：Knative Serving 和各类云函数（FaaS）。它们都能缩到零，但把钱花在了完全不同的地方。KEDA 的本质是「在你的 Kubernetes 集群里，把你已有的 Deployment 或 StatefulSet 副本数，按事件源信号调大调小」——你全程保留自己的容器、自己的连接语义、自己的顺序处理/重试/死信/检查点逻辑，几乎不用为适配弹性去改业务代码。你付的钱，就是那些真正在跑的 Pod 的算力，以及运行 KEDA operator 本身极轻量的开销。

Knative Serving 也能缩到零，还顺带给了流量切分、版本（revision）管理这些能力，但它会在你的服务和流量之间插一层自己的 queue-proxy 来做排队和激活，更天然地服务于 HTTP 请求型服务；对于一个纯粹从 Kafka 拉消息的消费者来说，Knative 的模型反而不如 KEDA 贴合。云函数（比如 AWS Lambda 这类）则是把运行时完全交给厂商，按调用次数计费、扩缩对你透明，听起来最省心，但代价是你得把代码改写成它的运行时模型，而且 VPC 内访问、冷启动、有状态连接这些事都得重新设计，长期来看容易和特定云平台绑定。

所以这三者的取舍其实很清楚：你已经是容器化的消费者、只想让副本跟着队列深度走、不想重构代码，KEDA 是把复杂度留给自己配置、把控制权留给你的那把刀；你做的是 HTTP 服务、想要流量灰度，Knative 更对路；你愿意为免运维买单、业务也能函数化，云函数更省力。把它们放在「要不要自己养节点」这个维度上，差异更明显：KEDA 只管 Pod 层，节点层还得靠 Cluster Autoscaler 或 Karpenter；而云函数连节点都不用你管。如果你打算把这套事件驱动架构跑在自建 Kubernetes 上、用自营机房节点来承接，那么成本模型就变成了「Pod 算力 + 节点资源 + 跨境链路带宽」，这和托管 serverless 的账完全是两本。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。把 KEDA 跑在自营节点上，意味着事件源（Kafka/RabbitMQ/Redis）和消费者 Pod 之间的网络走的是你自己的 BGP 多线或独享带宽，跨可用区拉取 broker 的延迟和成本都更可控，这恰恰是云函数那种「按调用计费、网络走公网」模型算不进来的隐性优势。

一个踩过的坑：阈值抖动手抖到副本反复横跳

阈值设得太「贴脸」，是 KEDA 上线后最容易翻车的地方。假设你把 Kafka 的 lagThreshold 设成 100，而你的稳态业务流量就一直在每条 90 到 110 之间晃——这时候 KEDA 会觉得「超了，加副本」，加完副本消费速度上来、lag 掉到 90 以下，HPA 又觉得「可以缩」，缩完 lag 又弹回去。副本数就在 min 和 max 之间反复横跳，每一次伸缩都伴随着 Pod 调度、镜像拉取、连接重建，监控图上看着热闹，实际是纯内耗。

治这个问题的工具其实在前面字段里都出现过。第一道闸是 cooldownPeriod，它管的是「缩到零之前等多久」，对 1→N 的横跳管不到，所以真正压住抖动的是 horizontalPodAutoscalerConfig 里的 scaleDown.stabilizationWindowSeconds 和 policies——把稳定窗口拉长、把单次缩容的百分比限死，副本就不会一惊一乍。第二道闸是阈值本身要留「迟滞区间」：把 value（期望每副本承载量）和 activationValue（从零唤醒的激活阈值）拉开距离，让「唤醒」和「维持」用不同的门槛，副本就不会在临界线上来回踩。还有一条铁律：cooldownPeriod 千万别设成 0，否则队列一空立刻归零、下一条消息来了又立刻拉起，在突发流量下就是无休止的伸缩循环。

还有两个生产里真实踩过的关联坑。其一是 SQS 这类带可见性超时（visibility timeout）的队列：如果消费者处理一条消息的时间超过了可见性超时，这条消息会被重新投入队列，KEDA 一看「又有活了」又去加副本，结果新副本和处理中的副本抢同一批消息，越扩越乱。其二是凭据过期——TriggerAuthentication 引用的密钥一旦失效，scaler 连不上事件源，默认情况下 KEDA 会冻结在现有副本数而不是缩零，表面风平浪静，实际弹性已经死了，所以要么配好 fallback 兜底，要么对 KEDA 自身指标做告警。 再补一个规模化后才暴露的坑：ScaledObject 不是越多越便宜。每一个 ScaledObject 都会让 KEDA operator 周期性地去轮询它的事件源、做指标计算，集群里几十上百个 ScaledObject 时，这部分控制面开销和 API 调用量会肉眼可见地上升，某些 scaler 还会打到 broker 或数据库的查询配额上。公开的 KEDA 版本说明里就专门提到过针对 scaler 评估做了缓存和并发优化来缓解这个问题，但对于把几十个微服务每个都无脑挂一个 ScaledObject 的团队来说，依然会在控制面吃紧。所以当你发现 KEDA 自身开始吃 CPU、或者事件源被「轮询」出限流时，该合并的触发器合并、该调大 pollingInterval 的调大，把伸缩对象收敛到真正有弹性需求的负载上，别让自动伸缩本身变成新的资源黑洞。

预算有限时，最大副本数才是真正的成本天花板

很多团队算成本账的时候盯着 minReplicaCount，觉得「平时常驻几个副本」就是开销大头。其实在事件驱动场景里，真正决定你月底账单上限的，是 maxReplicaCount。min 只影响基线空闲成本，而 max 决定了一次队列风暴里你能被推到多高。设想一个促销活动把消息瞬间灌进来，如果没有上限，KEDA 可能一路把副本拉到几百个，每个都要调度、每个都要资源，紧接着把节点层也逼到自动扩容，账单指数级往上翻——而你的下游数据库或者 broker 根本处理不了这么高并发，纯属花了钱还救不了业务。

所以 maxReplicaCount 应该由「下游能扛住多少并发」来倒推，而不是由「队列现在有多深」来决定。一个务实的做法是：先压测出你的消费者 Pod 单实例能稳定处理多大吞吐、你的数据库/缓存/第三方接口能接住多少并发，再用这个数字去卡 max。KEDA 可以多个触发器并存、取最大值，但你得保证那个最大值不超过下游的承载，否则扩出来的副本只是在制造等待和超时。换句话说，KEDA 负责「该扩就扩」，而 maxReplicaCount 负责「别扩到破产」，两者缺一不可。

另一层容易被忽略的成本是节点层。KEDA 只伸 Pod、不伸节点；如果集群里没有配 Cluster Autoscaler 或 Karpenter，副本数虽然被 KEDA 推上去了，新 Pod 却会因为节点资源不够而一直 Pending，既没真正处理消息、又卡住了整个伸缩链路。所以完整的成本模型是「Pod 算力成本 + 节点资源成本 + 跨境链路带宽成本」三层叠加，只盯 Pod 那一层会算漏很大一块。对于预算有限的小团队，与其无上限地追求「峰值绝不丢消息」，不如把 max 卡在一个可控值、配合死信队列承接溢出，用确定的成本换可接受的延迟，往往更划算。

一万网络能给事件驱动架构接什么：从选型到落地

把前面这些算清楚之后，落地环节还有一个绕不开的问题：这套 Kubernetes 事件驱动架构，底座跑在哪、事件源和消费者之间的网络怎么走、突发时节点资源从哪来。这正是基础设施层要补上的那一块。无论是自建 Kafka/RabbitMQ/Redis 集群，还是把消费者 Pod 跑在自建 Kubernetes 上，底层的服务器、机柜、带宽和跨地域链路，直接决定了 KEDA 伸缩出来的那些 Pod 能不能真正吃到消息、缩回去的时候能不能省下真金白银。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对于打算把 KEDA 跑在自建集群上的团队，自营节点意味着你可以把事件源 broker 和消费者调度到同一组低延迟网络内，用 BGP 多线或独享带宽替代公网跨境链路，既压低了拉取消息的延迟，也避免了按公网流量计费带来的账单不确定性；中国香港及海外节点则适合需要就近接入境外消息源或做异地双活的事件驱动业务。

从选型到落地的顺序建议是这样：先确认你的事件源类型和对应 scaler 在你计划部署的 KEDA 版本里是否成熟（Kafka/RabbitMQ 最稳，Redis Streams 需核对版本）；再据此定 min/max、pollingInterval、cooldownPeriod 与 HPA 的 stabilizationWindowSeconds；接着把 TriggerAuthentication 的凭据管理和轮转方案定下来；最后才是把底座节点、机柜和带宽资源按峰值 max 倒推出来的算力需求一次性规划好。基础设施和 KEDA 配置是同一笔账的上下两端，只调上面不理下面，伸缩永远卡在节点或链路上。

一万网络能给事件驱动架构接什么：下单前要确认的清单

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在下单或正式开工前，建议对照下面这份清单逐条确认，避免把 KEDA 的成本账算在半空：

☐ 事件源类型已确认，且对应 scaler 在计划部署的 KEDA 版本中可用、字段匹配（Kafka/RabbitMQ 成熟；Redis Streams 需核对版本是否含该 scaler）。

☐ scale-to-zero 是否符合业务 SLA：对首条消息延迟敏感的服务，minReplicaCount 应保留 ≥1，不要盲目设 0。

☐ maxReplicaCount 已按下游（数据库/缓存/第三方接口）的真实承载上限倒推，而非按队列深度随便给。

☐ pollingInterval 与 cooldownPeriod 已设定：cooldownPeriod 不得为 0，避免队列一空即归零引发抖动。

☐ HPA 的 scaleDown.stabilizationWindowSeconds 与 policies 已配置，用于压住 1→N 的副本横跳。

☐ value 与 activationValue 之间留出迟滞区间，避免副本在阈值临界线上反复横跳。

☐ TriggerAuthentication 凭据来源、轮转与失效兜底（fallback 段）已规划，避免 scaler 连不上事件源导致弹性静默失效。

☐ 节点层已配 Cluster Autoscaler 或 Karpenter，确保 KEDA 推高的 Pod 不会因节点资源不足而长期 Pending。

☐ 事件源 broker 与消费者 Pod 的网络路径已规划（同组网低延迟 / BGP 多线 / 独享带宽），跨境链路成本已计入账单模型。

☐ 监控与告警已联动：KEDA 自身指标、Scaler 失败、副本数与队列堆积需能互相印证，而非只看 CPU 图。

数据来源

KEDA 官方文档 ScaledObject specification（keda.sh/docs，版本 v2.15 / v2.20 规格说明，含 apiVersion、scaleTargetRef、pollingInterval、cooldownPeriod、minReplicaCount、maxReplicaCount、fallback、horizontalPodAutoscalerConfig 等字段默认值）。

KEDA GitHub Releases（kedacore/keda，v2.18.2 发布于 2025-12-08，以及 v2.16–v2.18 系列补丁说明）。

KEDA 官方 Scalers 目录（keda.sh，列出 Kafka、RabbitMQ Queue、Redis Streams、HTTP Add-on、Cron 等 60+ 触发器的支持状态）。

StepScale《Kubernetes HPA vs KEDA – Which Autoscaler Should You Use?》（生产常用触发器分类、冷启动 30–90 秒、KEDA 默认轮询 30 秒 vs HPA 同步 15 秒等数据）。

Plural《KEDA vs. HPA: Which Kubernetes Autoscaler to Use》（HPA 默认最小副本 1、KEDA scale-to-zero、二者分工 0→1 与 1→N 的边界说明）。

UMA Technology《Kubernetes HPA vs. KEDA》（HPA autoscaling/v2、HPAScaleToZero 特性开关、KEDA 包裹 HPA 的架构分工）。

k8s.guru《KEDA 2.12 Autoscaling Enhancements》（Redis Streams scaler 随 v2.12 于 2025-10 引入等版本信息）。