Kubernetes 自动扩缩容常被讲成 CPU 与内存的故事，但许多生产系统最先失守的位置并不在这条轴线上。Kafka consumer 可以在 CPU 很低时保持平静，lag 却持续增长。Queue worker 在突发流量之间看起来空闲，却决定着用户是否要等待。由 GPU 支撑的 inference service，也会需要依据内存压力或加速器利用率来扩缩，而不能只看容器 CPU。KEDA 的重要性正在这里：它给 Kubernetes 提供了一条原生路径，使系统可以依据这些外部信号扩缩，而不要求每个团队各自开发一套 autoscaling controller。

它的核心形态很窄，也很有用。KEDA 将自身描述为一个基于 Kubernetes 的 event-driven autoscaling 组件，支持细粒度 scale to and from zero，充当 Kubernetes Metrics Server，并让用户通过专门的 custom resource definition 定义自动扩缩容规则。[1] 截至 2026-05-27T22:31:35Z UTC，当前 KEDA 文档把 v2.19 标为 ScaledObject、scaling、authentication 与 external-scaler 文档的最新 release line。[2][3][4] 本文把 KEDA 作为架构边界来读，功能清单只是次要表层：当团队希望 HPA 继续负责副本决策，同时希望信号来自 queue depth、lag、request backlog、schedule windows 或自定义领域指标，而不只是 pod resource use 时，KEDA 的形状最清楚。

The control point is the ScaledObject

KEDA 最主要的设计动作，是把自动扩缩容意图转成 Kubernetes object。ScaledObject specification 定义目标 workload、polling 与 cooldown 行为、副本限制、可选 fallback 行为、可选 HPA 行为，以及触发扩缩容的 triggers。[2] 其中的重要字段并不奇特。scaleTargetRef.name 指向 workload，pollingInterval 默认是 30 seconds，cooldownPeriod 默认是 300 seconds，minReplicaCount 默认是 0，maxReplicaCount 默认是 100。[2]

这使 KEDA 更像 workload reality 与 Kubernetes 现有扩缩容机制之间的 adapter，而不像另一套独立 scheduler。平台团队可以像审查其他 cluster policy 一样审查一个 ScaledObject：哪一个 workload 会被扩缩，哪一个 event source 被信任，允许的副本范围是多少，metric source 失败时发生什么，以及 scale-down 被允许以多快速度发生。[2]

失败模式也会显现在这个 object 里。若 trigger 错了，authentication 范围过宽，polling interval 太慢，或者 maxReplicaCount 被当成愿望而不是 capacity budget 来设置，KEDA 会忠实放大这类建模错误。这个项目没有消除理解 workload math 的需要。它给这些计算提供了一个 Kubernetes 原生位置。

KEDA keeps HPA in the loop

扩缩路径被有意拆开。KEDA 监控 event source，在工作出现时激活 workload，并把 metric data 送给 Kubernetes 与 Horizontal Pod Autoscaler，让 HPA 在已有副本之后推动 scale-out。[3] 官方 deployment-scaling 文档直接描述了常见 queue pattern：没有 pending messages 时，KEDA 可以把 deployment 缩到零；message 到来时，KEDA 激活 deployment；更多 messages 到来后，KEDA 把这些数据送给 HPA；随后 replicas 从 event source 中处理 items。[3]

这个拆分在运维上很重要。HPA 仍是 one-to-many scaling phase 中熟悉的 controller。KEDA 负责 zero-to-one activation，也负责把外部信号转译成 HPA 可以消费的 metrics。[3] 一篇独立 KEDA walkthrough 也把同一点概括为 two-phase model：KEDA 处理 activation，HPA 根据收到的 metrics 承担持续扩缩工作。[7]

这正是 KEDA 往往比 bespoke autoscaler 更适合 queue 与 event workloads 的原因。团队真正需要的是一座纪律化桥梁，把“还有多少工作在等待？”连接到“应该存在多少 replicas？”；Kubernetes control loop 继续保留。

External scalers are the escape hatch

Built-in scalers 覆盖了许多常见系统，但更强的架构能力在 external scaler interface。KEDA v2.19 文档说明，external scalers 是单独管理的 gRPC servers，实现与 built-in scalers 同一概念接口，而 KEDA 充当 gRPC client。[4] External scaler contract 包含 IsActive、StreamIsActive、GetMetricSpec 与 GetMetrics；KEDA 调用这些方法时会传入 ScaledObjectRef，其中包括 ScaledObject name、namespace 与 trigger metadata。[4]

在这里，KEDA 超出了“按 Kafka lag 自动扩缩”的范围。团队可以把领域专属 metric collection 放在一个小型 gRPC service 后面，再让 KEDA 把这项服务接入同一条 HPA path。2026 年 5 月 27 日 CNCF community post 中的 GPU autoscaling 是一个当前例子：一个 custom DaemonSet 通过 NVML 读取本地 GPU data，经由 KEDA 的 ExternalScaler interface 提供这些 metrics，并让 KEDA 驱动 HPA decisions。[6] 这个 scaler 暴露 GPU utilization、memory utilization、VRAM-used percentage、temperature 与 power draw 等信号，也为 multi-GPU nodes 提供 aggregation options。[6]

即便你不运行 GPU inference，这个例子依然有用。它展示的是一般模式：把 metric collector 放在最了解真实状态的系统旁边，暴露一份窄的 scaler contract，再把其余扩缩行为留在 Kubernetes 之内。结果并非魔法，而是一条清楚的所有权边界：signal production 与 replica control 各归其位。

Governance and maturity are part of the adoption case

KEDA 不是一个 steward 不清的小型旁支项目。CNCF 在 2023 年 8 月宣布 KEDA graduation，并指出该项目最初是 Microsoft 与 Red Hat 在 2019 年的合作成果，2020 年进入 CNCF Sandbox，2021 年进入 Incubating，graduation 时已有超过 45 家组织在生产中使用。[5] 同一公告还称，当时 KEDA 已增加超过 60 个 scalers，并支持 nine 个 authentication providers。[5]

这些数字不能替代 pilot。它们仍然重要，因为 autoscaling 属于 reliability path。采用 KEDA 的团队添加的是一条 controller 与 metrics path，范围远超装饰性 dashboard；配置不当时，它会制造成本尖峰，掩盖 backlog，或者让 workers 饥饿。Graduation、公开文档、security review references、可见 adoption 与广泛 scaler ecosystem，使这个项目更容易被那些需要的不止是演示效果的平台团队接受。[1][5]

采用边界仍然很清晰。当扩缩信号位于外部、可测量，并且与工作量有直接因果距离时，KEDA 很合适。Queue depth、consumer lag、job backlog、external metric APIs，以及自定义硬件或服务 counters，都符合这一模型。[2][3][4][6] 当团队解释不清 metric 如何映射到 replica demand，当 startup time 主导 response time，当 downstream capacity 才是真正 bottleneck，或者当一个 scaler 为了观察 event source 需要过宽 secrets 时，KEDA 的适配度就会明显下降。

The practical architecture rule

最好的 KEDA 部署从一个问题开始：“什么信号能证明更多 replicas 会减少等待中的工作？”答案清楚时，KEDA 会把这个信号以 Kubernetes 原生方式送入 HPA。答案含混时，KEDA 只会让含混变成系统行为。

对平台团队而言，持久的模式很简单。保持 ScaledObjects 小而可审查。把 credentials 放进 TriggerAuthentication 或 ClusterTriggerAuthentication，避免把 secrets 散落在 workload manifests 里。[2] 使用保守的 maxReplicaCount，并让它与 downstream capacity 绑定。把 fallback behavior 当作 reliability decision，而不是一个 checkbox。对于 custom signals，优先采用带窄 gRPC contract 的 external scaler，少把临时 polling code 嵌进各个 applications。[4]

KEDA 的真正价值，不在“它能扩缩一切”这个宽泛说法里。它的价值在于，当 CPU 与内存是错误信号时，KEDA 让 Kubernetes 可以按真正相关的东西扩缩。这个主张更安静，架构上也更有力量。

来源

1. kedacore/keda README —— 项目目的、scale-to-zero 表述、metrics-server 角色、CRD 模型、CNCF 状态与仓库元数据。
2. KEDA docs，《ScaledObject specification》v2.19 —— target reference、polling 与 cooldown 默认值、副本限制、fallback、HPA 配置与 trigger 字段。
3. KEDA docs，《Scaling Deployments, StatefulSets & Custom Resources》v2.19 —— deployment scaling flow、scale-to-zero 行为与 HPA 交互。
4. KEDA docs，《External Scalers》v2.19 —— external gRPC scaler model、scaler interface、RPC contract 与 ScaledObject metadata flow。
5. Cloud Native Computing Foundation，《Cloud Native Computing Foundation Announces Graduation of Kubernetes Autoscaler KEDA》—— graduation timeline、adoption examples、scaler count、authentication-provider count，以及 governance/security signals。
6. CNCF Community Post，《GPU autoscaling on Kubernetes with KEDA: Building an external scaler》—— 2026 年 5 月 27 日关于面向 GPU workloads 的 custom KEDA external scaler 示例。
7. Jorijn Schrijvershof，《KEDA: event-driven autoscaling for Kubernetes》—— 解释 KEDA activation 与 HPA handoff model 的独立技术 walkthrough。