kedacore/keda

解决什么问题

Kubernetes 自带的 HPA 只能按 CPU 和内存伸缩，但队列型负载的瓶颈通常不在这里：消费者可能 CPU 空闲而消息堆积，也可能消息已清空却仍在占用资源。团队往往要自己写控制器或用 cron 兜底。KEDA 在 HPA 之外加了一层事件驱动的伸缩逻辑，从队列、流等事件源采集指标喂给 HPA，并支持在没有待处理工作时把工作负载缩到零。

有什么不同

与单独使用 HPA 相比，区别在于指标来源：KEDA 通过各类 scaler 读取队列深度、消费延迟等信号，而不是资源利用率。与 Knative 这类 Serverless 平台相比，KEDA 不替换你的运行时，它包裹普通的 Deployment 和 Job，侵入性小得多。真正改变架构的是缩容到零和面向批处理的 ScaledJob。README 内容偏薄，具体能力需要看官方文档。

适合谁

适合在 Kubernetes 上跑队列消费者、流处理或批处理任务的平台团队和 SRE，尤其是希望空闲服务缩到零、按积压而非 CPU 扩容的场景，云端和边缘集群都适用。只需要 CPU 伸缩的团队继续用原生 HPA 即可，没必要多维护一个控制器；已经重度使用 Knative 或托管 Serverless 的团队也要评估功能重叠是否值得。

上手成本

需要安装集群级 Operator，涉及 CRD、RBAC 和 metrics server 角色，变更通常要走集群管理员。每个事件源都要单独配置 scaler 和凭据。KEDA 采用 Apache-2.0 协议，是 CNCF 毕业项目，2019 年创建，成熟度较高。主要风险在运维侧：轮询间隔和伸缩阈值的调优，以及零副本与入口、就绪探针之间如何配合。

点评

这是一个成熟的 CNCF 毕业项目，不是新项目：2019 年至今积累 10.6k star，近期单月 +124 star 说明关注度稳定而非短期爆发。Hacker News 上几乎没有讨论，符合基础设施工具靠运维团队口口相传的传播方式。README 大多是链接，决策前应直接看 keda.sh 文档。事件驱动的负载能省掉自研伸缩管线；纯请求型服务用 HPA 就够了。