2. KEDA 核心架构：四大组件详解

KEDA 的运行时架构围绕四个核心自定义资源（CRD）构建：ScaledObject、ScaledJob、TriggerAuthentication 和 ClusterTriggerAuthentication。这四个组件共同定义了“何时扩缩”、“扩缩什么”以及“如何安全访问指标源”的完整语义。理解它们之间的关系是掌握 KEDA 的关键。

2.1 组件全景与职责划分

下表从作用范围、目标负载类型和核心职责三个维度对四个组件进行对比：

2.2 ScaledObject：无状态工作负载的弹性引擎

ScaledObject 是 KEDA 最常用的资源，它定义了如何根据外部指标自动扩缩 Deployment 或 StatefulSet。KEDA 控制器会为每个 ScaledObject 自动生成一个对应的 HPA（Horizontal Pod Autoscaler）对象，并将外部指标源转换为 HPA 可消费的格式。

一个典型的 ScaledObject YAML 包含以下关键字段：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: consumer-scaler
  namespace: production
spec:
  scaleTargetRef:
    name: event-consumer          # 目标 Deployment 名称
    kind: Deployment              # 支持 Deployment / StatefulSet
  pollingInterval: 15             # 每 15 秒轮询一次指标源
  cooldownPeriod: 60              # 指标低于阈值后等待 60 秒再缩容
  minReplicaCount: 2              # 最小副本数（安全基线）
  maxReplicaCount: 50             # 最大副本数（削峰上限）
  triggers:
    - type: kafka                 # 触发器类型
      metadata:
        topic: orders
        bootstrapServers: kafka-cluster:9092
        lagThreshold: "100"       # 滞后超过 100 条时触发扩容
      authenticationRef:
        name: kafka-auth          # 引用 TriggerAuthentication

2.3 ScaledJob：事件驱动的批处理执行器

ScaledJob 专为 Job 类型负载设计。与 ScaledObject 持续维持副本数不同，ScaledJob 在检测到事件（如消息队列积压）时创建新的 Job 实例，任务完成后 Job 自动退出。这种模式非常适合非实时、可并行处理的批处理场景。

ScaledJob 与 ScaledObject 的关键区别：

• 生命周期： ScaledObject 保持 Pod 长期运行；ScaledJob 创建短期 Job，任务即结束。
• 扩缩方式： ScaledObject 通过 HPA 调整副本数；ScaledJob 直接控制 Job 的并发创建数量。
• 适用场景： ScaledObject 适合 API 服务、流处理；ScaledJob 适合数据迁移、日志处理、视频转码。

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: batch-processor
  namespace: data-pipeline
spec:
  jobTargetRef:
    template:
      spec:
        containers:
          - name: worker
            image: myrepo/batch-worker:1.2
            command: ["process", "--input", "/data/input"]
        restartPolicy: Never
  pollingInterval: 10
  maxScalingCount: 20              # 最大并发 Job 数
  scalingStrategy:
    strategy: "default"            # 可选：default / custom / accurate
  triggers:
    - type: rabbitmq
      metadata:
        queueName: tasks
        queueLength: "50"
        host: amqp://rabbitmq:5672
      authenticationRef:
        name: rabbitmq-creds

2.4 TriggerAuthentication 与 ClusterTriggerAuthentication：安全凭据管理

这两个组件专门用于管理访问外部指标源（如 Kafka、Prometheus、AWS CloudWatch）所需的认证信息。它们将敏感凭据从 ScaledObject/ScaledJob 中剥离，避免在触发器定义中硬编码密钥。

# TriggerAuthentication 示例
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: kafka-auth
  namespace: production
spec:
  secretTargetRef:
    - parameter: saslPassword     # KEDA 触发器参数名
      name: kafka-secrets         # Kubernetes Secret 名称
      key: sasl-password          # Secret 中的键

# ClusterTriggerAuthentication 示例
apiVersion: keda.sh/v1alpha1
kind: ClusterTriggerAuthentication
metadata:
  name: global-prometheus-auth
spec:
  secretTargetRef:
    - parameter: bearerToken
      name: prometheus-      # 可引用任意命名空间的 Secret
      key: 

2.5 组件协作流程

下图展示了 ScaledObject、TriggerAuthentication 与底层 Kubernetes 资源之间的完整协作链路：

2.6 组件关系总结

• ScaledObject ↔ ScaledJob： 二选一，根据负载类型选择。前者用于长期服务，后者用于批处理。
• ScaledObject/ScaledJob ↔ TriggerAuthentication： 通过 authenticationRef 字段建立引用关系，实现凭据与策略的解耦。
• TriggerAuthentication ↔ ClusterTriggerAuthentication： 作用域不同，但接口一致。集群级认证可以被子命名空间的 ScaledObject 引用。
• KEDA 控制器 ↔ HPA： KEDA 作为 HPA 的指标提供者，ScaledObject 的创建会触发 HPA 的自动生成与同步。