⚔️KEDA

KEDA 架构总结

从 Pod 层面架构总结

• 核心 Pod 组件：
• keda-operator Pod（Deployment: keda-operator）：
• 功能：这是 KEDA 的主控制器（基于 operator-sdk 和 controller-runtime 构建）。它监控自定义资源（CRD）如 ScaledObject、ScaledJob 和 TriggerAuthentication。检测到新资源时，会实例化 Scaler（触发器逻辑），管理 scale-to-zero/from-zero，创建并维护 HPA 对象。
• 内部细节：Scaler 不是独立的 Pod，而是 Operator 进程内的内存实例（Go 代码）。每个 ScaledObject 的 trigger 会创建一个独立的 Scaler 实例，这些实例定期轮询外部事件源获取指标。Operator 支持 leader election（领导者选举），允许多副本高可用（HA）。
• 资源消耗：无状态，低开销。默认 replicas=1，可扩展到 3+ 以分担负载（例如，大量 ScaledObject 时）。
• 日志/监控：暴露 Prometheus 指标，用于自监控。
• keda-operator-metrics-apiserver Pod（Deployment: keda-operator-metrics-apiserver，或旧版本为 keda-metrics-apiserver）：
• 功能：作为 Kubernetes 外部指标适配器（external metrics API），将 Scaler 获取的指标暴露给 API Server。HPA 通过 API Server 查询这些指标进行缩放决策。
• 内部细节：无状态，支持缓存指标（useCachedMetrics）以减少外部查询负载。注册为 APIService（/apis/external.metrics.k8s.io/v1beta1），API Server 会代理查询到此 Pod。
• 资源消耗：低开销，默认 replicas=1，可扩展。

• 可选 Pod：
• Admission Webhook Pod（如果启用）：用于验证 ScaledObject 配置的 webhook 服务，通常一个 Deployment。
• External Scalers：如果使用自定义 external scaler（GRPC 服务），可能需要额外 Pod，但内置 Scaler（如 Kafka、RabbitMQ）都在 Operator 内运行。

• 整体 Pod 视图： 在 keda namespace 下，典型输出（kubectl get pods -n keda）：
• 无 per-ScaledObject Pod：所有 Scaler 共享 Operator Pod 的资源，避免资源浪费。
• 高可用扩展：通过设置 Deployment replicas >1，实现 HA。Operator 使用 leader election，只有一个活跃实例处理 reconciliation。
• 安装方式：Helm chart 或 YAML manifest，默认在 keda namespace 部署。

从使用层面简单说明

• 基本步骤：
1. 安装 KEDA：使用 Helm（helm install keda kedacore/keda --namespace keda）或 Operator Hub。
2. 创建 ScaledObject 或 ScaledJob：
• ScaledObject：针对 Deployment/StatefulSet/CustomResource，支持 scale-to-zero。
• ScaledJob：针对 Job，支持并发执行。 示例 YAML（RabbitMQ trigger）：
3. 配置 TriggerAuthentication（可选）：存储敏感信息如 API 密钥。
4. 监控：KEDA 自动创建 HPA 对象（kubectl get hpa）。使用 Prometheus 监控 KEDA 自身指标。

• 关键特性：
• Trigger 类型：内置 50+ Scaler（如 Kafka、AWS SQS、Prometheus、Azure Monitor），支持自定义。
• 多 Trigger 支持：一个 ScaledObject 可有多个 trigger，取最大缩放值。
• Fallback/Cooldown：指标不可用时回退到默认 replicas；冷却期避免抖动。
• 兼容性：与 HPA、VPA（Vertical Pod Autoscaler）无缝集成，支持 AKS、EKS 等托管 K8s。

• 使用场景：事件驱动应用（如处理消息队列）、批处理 Job、监控驱动缩放。简单上手，但需了解外部事件源配置。

从 Serverless 能力实现层面说明

• Serverless 实现机制：
• Scale-to-Zero/From-Zero：
• 当无事件时（指标为 0），KEDA Operator 检测到后更新 HPA，将 replicas 设为 0，并“暂停” Deployment（通过 annotation 标记，避免直接删除）。
• 有事件时，Scaler 轮询检测（pollingInterval，默认 30s），激活 Deployment，HPA 快速扩容到所需 replicas。
• 实现细节：Operator 维护一个“激活状态”，并使用 Kubernetes finalizers 确保安全缩放。Metrics Server 确保 HPA 查询到实时指标。
• 事件驱动缩放：
• Scaler 连接外部源（如队列），拉取指标（pull 模式为主，部分支持 push）。
• HPA 使用这些指标计算 replicas：desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]。
• 支持 Job：ScaledJob 可基于事件创建多个 Job 实例，实现并行 serverless 执行。
• 资源优化：
• 无需常驻 Pod，节省 CPU/Memory（尤其云环境，按需付费）。
• 与 Karpenter/Cluster Autoscaler 结合，实现节点级缩放（Pod 级 + 节点级 serverless）。
• 示例实现：在 Azure Functions on K8s 中，KEDA 驱动 Function 容器缩放，模拟 serverless 函数调用。

• 优势在 Serverless：KEDA 使任何容器化工作负载（如 Java、Python app）具备 serverless 特性，而无需迁移到特定 runtime。支持自定义事件源，灵活性高。

KEDA 相比于 Knative 的劣势说明

• 总体劣势总结：KEDA 更轻量、易集成现有 K8s，但缺乏 Knative 的完整 serverless 生态（如 HTTP 代理、事件 broker）。如果你的应用是 HTTP 重或需复杂事件流，Knative 更优；KEDA 适合纯事件/指标驱动缩放。社区建议：KEDA 可与 Knative 结合使用（Knative 支持 KEDA 作为 autoscaler）。