3. 架构总览：KEDA核心组件及其交互流程

KEDA（Kubernetes Event-Driven Autoscaling）的架构设计遵循“事件驱动、解耦控制”的原则。整个控制面由三个核心组件构成：Operator、Metrics Server 和 Admission Webhooks。它们各司其职，通过标准 Kubernetes API 扩展机制协同工作，将外部事件指标转化为 HPA 可消费的指标数据，实现从“被动轮询”到“事件触发”的弹性伸缩范式转变。

3.1 核心组件职责与定位

3.2 组件交互流程：从事件到伸缩

下图展示了 KEDA 控制面在收到外部事件后，各组件之间的完整交互链路：

3.3 交互流程分步详解

1. 配置提交与准入控制：用户通过 kubectl apply 提交 ScaledObject 或 ScaledJob 资源。请求到达 API Server 后，Admission Webhooks 拦截请求，执行校验逻辑（如检查触发器类型是否合法、命名空间是否存在）并注入默认值（如默认 pollingInterval、cooldownPeriod）。
2. Operator 协调循环：校验通过后，资源持久化到 etcd。Operator 通过 Informer 机制监听到资源变化，进入 Reconcile 循环。Operator 根据 ScaledObject 的触发器定义，创建或更新对应的 HPA 资源，并将 ScaledObject 的状态同步到 Status 字段。
3. HPA 指标查询：Kubernetes 内置的 HPA Controller 定期（默认 15 秒）向 Metrics Server 查询指标。Metrics Server 实现了 custom.metrics.k8s.io 和 external.metrics.k8s.io API，通过 Kubernetes API Aggregation Layer 注册。
4. Scaler 指标拉取：Metrics Server 收到查询请求后，根据指标名称找到对应的 Scaler 连接器（如 Kafka Scaler、Prometheus Scaler），调用其 GetMetrics() 方法从外部事件源拉取实时指标值，并缓存结果。
5. 伸缩决策与执行：HPA Controller 获取到指标值后，计算期望副本数，并更新目标 Deployment / StatefulSet 的 replicas 字段。Kubernetes 控制面随后执行实际的 Pod 扩缩容操作。

3.4 组件间通信协议与端口

3.5 高可用与故障隔离设计

KEDA 控制面在生产环境中通常以多副本部署，并利用 Kubernetes 原生能力实现高可用：

• Operator 多副本：通过 leader election（基于 ConfigMap 或 Lease）确保同一时刻只有一个活跃的 Reconcile 循环，避免资源竞争。故障时备用副本自动接管。
• Metrics Server 无状态设计：所有指标缓存存储在内存中，多副本之间不共享状态。HPA 查询会随机路由到任意副本，单副本故障仅影响缓存命中率，不会导致伸缩中断。
• Admission Webhooks 故障模式：Webhooks 配置了 failurePolicy: Fail 或 failurePolicy: Ignore。关键校验场景使用 Fail 模式确保配置正确性；非关键场景使用 Ignore 模式避免 Webhooks 故障阻塞整个集群的资源创建。