3. KEDA 架构总览：核心组件、数据流与事件驱动模型
KEDA（Kubernetes Event-Driven Autoscaling）并非简单地替代 Horizontal Pod Autoscaler（HPA），而是在 Kubernetes 原生水平弹性之上，构建了一层事件驱动的感知与触发层。理解其架构，是掌握触发器与协同机制的基础。本章将拆解 KEDA 的三大核心组件，并梳理从事件发生到 Pod 副本数变化的关键数据流。
3.1 核心组件：Operator、Scaler、Metric Adapter
KEDA 由三个紧密协作的组件构成，它们各自承担不同的职责，共同将外部事件源的状态转化为 Kubernetes 可理解的伸缩指令。
| 组件 | 职责 | 部署形态 | 关键行为 |
|---|---|---|---|
| Operator | 生命周期管理与协调 | Deployment（通常 2 副本） | 监听 ScaledObject / ScaledJob CRD，管理 HPA 的创建、更新与删除。 |
| Scaler | 事件源数据采集与指标计算 | Operator 内部模块（或 gRPC 插件） | 连接外部系统（Kafka、Prometheus、RabbitMQ 等），获取指标值并返回给 Metric Adapter。 |
| Metric Adapter | 指标暴露与 HPA 对接 | Deployment（通常 2 副本） | 实现 Kubernetes 的 custom.metrics.k8s.io API，将 Scaler 计算的指标值暴露给 HPA。 |
架构要点： Operator 是“大脑”，负责策略与编排；Scaler 是“感官”，负责感知外部世界；Metric Adapter 是“翻译官”，负责将感知结果翻译成 HPA 能读懂的指标格式。
3.2 核心数据流：从事件到伸缩
一个完整的事件驱动伸缩周期，遵循以下 6 个步骤。理解这个数据流，是排查伸缩异常和优化触发器配置的前提。
- 用户定义：运维人员创建
ScaledObject或ScaledJob自定义资源，声明目标工作负载、触发器类型（如 Kafka Lag）、阈值等参数。 - Operator 监听与协调：KEDA Operator 通过 Informer 机制监听到 CRD 的创建/更新事件，开始协调循环。
- 创建/更新 HPA：Operator 根据
ScaledObject的配置，动态生成一个指向 KEDA Metric Adapter 的 HPA 资源。 - HPA 轮询指标：Kubernetes HPA 按照默认（或自定义）的间隔（通常 15s），通过
custom.metrics.k8s.ioAPI 向 KEDA Metric Adapter 请求指标值。 - Scaler 采集与计算：Metric Adapter 收到请求后，调用对应的 Scaler（如 Kafka Scaler）。Scaler 连接外部事件源，获取当前指标（如消费者组 Lag），并根据
ScaledObject中的targetValue或targetAverageValue计算出期望的副本数。 - HPA 执行伸缩：Metric Adapter 将计算后的指标值返回给 HPA。HPA 根据当前指标值与目标值的比值，计算出期望的 Pod 副本数，并调整 Deployment 或 StatefulSet 的
replicas字段。
关键延迟点： 从事件发生到 Pod 扩容，主要延迟来自 HPA 的轮询周期（默认 15s）和 Scaler 的查询耗时。对于延迟敏感的场景，可以通过调整 HPA 的
--horizontal-pod-autoscaler-sync-period 参数来缩短轮询间隔。
3.3 事件驱动模型与组件协同
KEDA 的事件驱动模型并非简单的“事件-动作”直连，而是一种基于控制循环的“感知-决策-执行”模型。下图展示了核心组件之间的协同关系与数据流向。
3.4 ScaledObject 与 ScaledJob：事件驱动的入口
KEDA 通过两个核心 CRD 来定义伸缩规则。它们是用户与 KEDA 交互的主要接口，也是 Operator 协调循环的输入源。
- ScaledObject：用于无状态或有状态服务的持续伸缩。它管理一个 HPA，并根据实时指标动态调整 Deployment、StatefulSet 或任何实现了
/scale子资源的自定义资源的副本数。 - ScaledJob：专为批处理任务设计。它不创建 HPA，而是根据事件（如 Kafka 消息积压）直接创建 Kubernetes Job。每个事件单元（如一个分区的一个消息批次）可以触发一个 Job 实例，任务完成后 Pod 自动退出。
选择依据： 如果工作负载需要持续运行并处理请求（如 Web 服务、API 网关），使用
ScaledObject。如果工作负载是离散的、可并行处理的批处理任务（如数据清洗、图片转码），使用 ScaledJob。错误的选择会导致资源浪费或任务处理延迟。
3.5 组件部署拓扑与高可用
在生产环境中，KEDA 的 Operator 和 Metric Adapter 通常以多副本 Deployment 的形式部署，以确保控制面的高可用。Scaler 作为 Operator 进程内的模块或独立的 gRPC 插件运行，其可用性依赖于 Operator 的可用性。
| 组件 | 推荐副本数 | 高可用策略 | 故障影响 |
|---|---|---|---|
| Operator | 2 | Leader Election（基于 ConfigMap 或 Lease） | Leader 故障时，Follower 接管，期间 CRD 协调暂停。 |
| Metric Adapter | 2 | 无状态水平扩展，前端 Service 负载均衡 | 单个实例故障不影响指标查询，HPA 请求被路由到健康实例。 |
| Scaler | 随 Operator | Operator 内部模块，依赖 Operator 高可用 | Operator 故障时，Scaler 无法被调用，指标查询失败。 |
生产建议： 将 KEDA 组件部署在独立的命名空间（如
keda）中，并配置资源请求与限制（Request/Limit），避免被业务 Pod 挤占资源。同时，为 Metric Adapter 配置 PodDisruptionBudget（PDB），确保滚动更新期间至少有一个副本可用。