📚 课程目录第3章 KEDA架构与核心组件

3. KEDA 架构与核心组件：ScaledObject、ScaledJob、TriggerAuthentication、ClusterTriggerAuthentication

KEDA（Kubernetes Event-Driven Autoscaling）的架构围绕四个核心 CRD（Custom Resource Definition）构建：ScaledObject、ScaledJob、TriggerAuthentication 和 ClusterTriggerAuthentication。理解这些组件的关系与职责，是进行触发器调优的前提。

  核心原则：ScaledObject/ScaledJob 定义“扩缩什么”和“何时扩缩”，TriggerAuthentication 定义“如何安全地获取指标”。

3.1 整体架构与数据流

下图展示了 KEDA 在 Kubernetes 集群中的核心组件交互关系。KEDA Operator 作为控制面，监听 ScaledObject/ScaledJob 的创建，并通过 TriggerAuthentication 获取凭证，从 Prometheus 等外部源拉取指标，最终驱动 HPA 或 Job 的扩缩容决策。

3.2 核心组件详解

3.2.1 ScaledObject

ScaledObject 是 KEDA 中最常用的 CRD，用于定义如何基于外部事件源（如 Prometheus）自动扩缩容 Deployment、StatefulSet 或 Custom Resource。它内部封装了 HPA 的创建逻辑，但提供了比原生 HPA 更丰富的指标源和扩缩容策略。

调优要点：ScaledObject 的 pollingInterval（默认 30s）和 cooldownPeriod（默认 300s）直接影响 Prometheus 查询频率和缩容延迟。对于高波动业务，建议将 pollingInterval 缩短至 10-15s，同时适当降低 cooldownPeriod 至 120s。

关键字段对比：

字段	类型	默认值	说明
`scaleTargetRef`	Object	—	指定要扩缩容的目标资源（name、kind、apiVersion）
`triggers`	Array	—	定义事件源列表，每个 trigger 包含 type 和 metadata
`pollingInterval`	int	30	KEDA 从事件源拉取指标的间隔（秒）
`cooldownPeriod`	int	300	最后一次指标满足缩容条件后，等待多久才缩容（秒）
`minReplicaCount`	int	1	最小副本数
`maxReplicaCount`	int	100	最大副本数
`advanced`	Object	—	高级扩缩容策略，如恢复行为、分片策略等

3.2.2 ScaledJob

ScaledJob 专为 Job 类型的工作负载设计。与 ScaledObject 不同，它不通过 HPA 工作，而是直接根据事件源指标创建 Kubernetes Job。每个 Job 通常处理一个独立的工作单元，处理完成后自动退出。

注意：ScaledJob 不适合长时间运行的服务。如果 Job 执行时间过长，可能导致 Job 堆积。建议设置 maxFailedJobs 和 failedJobsHistoryLimit 来防止失控。

ScaledJob 特有字段：

字段	说明
`jobTargetRef`	定义 Job 模板，与原生 Job spec 一致
`maxFailedJobs`	允许的最大失败 Job 数，超过后停止创建新 Job
`failedJobsHistoryLimit`	保留的失败 Job 历史记录数
`successfulJobsHistoryLimit`	保留的成功 Job 历史记录数
`scalingStrategy`	扩缩策略：`default`（基于指标值）、`custom`（自定义逻辑）

3.2.3 TriggerAuthentication 与 ClusterTriggerAuthentication

这两个 CRD 用于向 KEDA 提供访问事件源（如 Prometheus、Kafka、AWS SQS）所需的凭证。它们将敏感信息（如 API 、密码、证书）与 ScaledObject/ScaledJob 解耦，提升安全性。

TriggerAuthentication：命名空间级别，只能被同一命名空间下的 ScaledObject/ScaledJob 引用。
ClusterTriggerAuthentication：集群级别，可被所有命名空间引用，适用于全局共享的凭证（如集群级 Prometheus）。

凭证来源支持：

Secret：引用 Kubernetes Secret 中的键值对。
Env：从 KEDA Operator 的环境变量读取。
Vault：集成 HashiCorp Vault 动态获取凭证。
Pod Identity：使用 Azure AD Pod Identity、AWS IAM 等云原生身份。

  最佳实践：对于 Prometheus 触发器，如果 Prometheus 无需认证（如内网部署），可以省略 TriggerAuthentication。但生产环境建议始终使用 TriggerAuthentication 管理 Prometheus Basic Auth 或 Bearer ，避免在 ScaledObject 中硬编码凭证。

3.3 组件关系与选择决策

以下表格帮助快速判断使用哪个组件：

场景	推荐组件	原因
扩缩容 Web 服务/API	ScaledObject	基于 HPA，支持 Deployment/StatefulSet，适合长运行服务
处理消息队列中的批处理任务	ScaledJob	每个消息/事件触发一个 Job，处理完即销毁
数据 ETL 或定时报表生成	ScaledJob	按需创建 Job，避免常驻 Pod 浪费资源
跨命名空间共享 Prometheus 凭证	ClusterTriggerAuthentication	一次配置，全局生效，减少重复
不同团队使用不同的 Prometheus 实例	TriggerAuthentication（命名空间级）	隔离凭证，避免权限越界

3.4 典型配置示例：Prometheus 触发器

以下是一个完整的 ScaledObject 示例，使用 Prometheus 触发器并引用 TriggerAuthentication：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-app
    kind: Deployment
  pollingInterval: 15
  cooldownPeriod: 120
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring.svc:9090
      metricName: http_requests_per_second
      query: sum(rate(http_requests_total{app="my-app"}[2m]))
      threshold: "100"
      activationThreshold: "10"
    authenticationRef:
      name: prometheus-auth
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: prometheus-auth
  namespace: default
spec:
  secretTargetRef:
  - parameter: bearerToken
    name: prometheus-secret
    key: 
  - parameter: caCert
    name: prometheus-secret
    key: ca.crt

调优提示：示例中的 activationThreshold 用于设置激活阈值，只有当指标值超过此阈值时，KEDA 才开始扩缩容。这可以避免在指标接近零时产生不必要的 Pod 创建，特别适合夜间低流量场景。

3.5 组件交互流程

用户创建 ScaledObject：指定目标 Deployment、Prometheus 查询和认证引用。
KEDA Operator 检测到 ScaledObject：解析 triggers 配置，根据 authenticationRef 查找对应的 TriggerAuthentication。
获取凭证：从 Secret/Env/Vault 中读取 Prometheus 的 Bearer 或 Basic Auth。
周期性拉取指标：按 pollingInterval 向 Prometheus 发起 HTTP 查询，执行 PromQL。
计算期望副本数：将查询结果与 threshold 比较，计算目标副本数。
创建/更新 HPA：KEDA 在后台创建 HPA 对象，HPA 负责调整 Deployment 的副本数。
持续监控：当指标下降并超过 cooldownPeriod 后，HPA 执行缩容。

常见陷阱：如果 Prometheus 查询返回多个时间序列（例如按 instance 分组），KEDA 会取所有序列的 最大值 作为决策依据。务必确保 PromQL 返回单一聚合值，或使用 average 等聚合函数。

3.6 本章小结

ScaledObject 是服务扩缩容的主力，适合 Deployment/StatefulSet。
ScaledJob 是批处理场景的利器，直接管理 Job 生命周期。
TriggerAuthentication 和 ClusterTriggerAuthentication 提供安全的凭证管理，生产环境必须使用。
合理设置 pollingInterval、cooldownPeriod、activationThreshold 是调优的核心。
PromQL 查询必须返回单一标量值，避免多序列导致的意外扩缩。