4. KEDA 核心概念：ScaledObject 与 ScaledJob、事件驱动伸缩模型、Scaling 触发器种类概述

KEDA（Kubernetes Event-Driven Autoscaling）的核心价值在于将 Kubernetes 原生的 水平 Pod 自动伸缩（HPA） 从基于 CPU/内存的指标扩展为基于任意事件源的弹性伸缩。本章将深入剖析 KEDA 的两大核心抽象——ScaledObject 与 ScaledJob，并梳理其事件驱动伸缩模型与丰富的触发器生态。

4.1 事件驱动伸缩模型

KEDA 的伸缩模型遵循“事件源 → Scaler → KEDA Operator → HPA / Job”的闭环路径。与传统的周期性指标采集不同，KEDA 通过专用的 Scaler 组件直接监听外部事件源（如 Kafka 分区偏移量、RabbitMQ 队列深度、Prometheus 查询结果），将事件负载量化为期望的副本数。

4.2 ScaledObject：面向持续运行工作负载的伸缩

ScaledObject 是 KEDA 中最常用的自定义资源，用于管理 Deployment、StatefulSet 或 Custom Resource 的自动伸缩。它定义了事件源、伸缩边界和行为策略。

4.2.1 ScaledObject 核心字段

4.2.2 ScaledObject 示例：基于 Kafka 偏移量的自动伸缩

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
  namespace: default
spec:
  scaleTargetRef:
    name: my-kafka-consumer
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-cluster:9092
        consumerGroup: my-group
        topic: orders
        lagThreshold: "100"
        offsetResetPolicy: latest
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 60
          policies:
            - type: Percent
              value: 50
              periodSeconds: 30

4.3 ScaledJob：面向批处理任务的弹性伸缩

ScaledJob 专为 批处理 和 队列驱动型任务 设计。与 ScaledObject 管理长期运行的 Pod 不同，ScaledJob 根据事件源负载动态创建 Kubernetes Job 实例，每个 Job 处理一个工作单元后自动退出。

4.3.1 ScaledJob 与 ScaledObject 对比

4.3.2 ScaledJob 示例：基于 RabbitMQ 队列的任务分发

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: rabbitmq-job-scaler
  namespace: default
spec:
  jobTargetRef:
    template:
      spec:
        containers:
          - name: worker
            image: my-worker:latest
            command: ["process-message"]
        restartPolicy: Never
  triggers:
    - type: rabbitmq
      metadata:
        host: amqp://guest:guest@rabbitmq:5672
        queueName: task-queue
        queueLength: "10"
  scalingStrategy:
    strategy: "default"
    maxScale: 50

4.4 Scaling 触发器种类概述

KEDA 提供了超过 50 种内置 Scaler（触发器），覆盖主流消息队列、数据库、监控系统和云服务。根据数据源类型可分为以下六大类：

4.5 触发器元数据与认证机制

每个触发器通过 metadata 字段传递连接参数和伸缩阈值。对于需要敏感信息的触发器（如数据库密码、云服务密钥），KEDA 支持通过 TriggerAuthentication 或 ClusterTriggerAuthentication 资源进行安全引用。

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: kafka-auth
  namespace: default
spec:
  secretTargetRef:
    - parameter: saslPassword
      name: kafka-secret
      key: password
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: secure-scaler
spec:
  scaleTargetRef:
    name: my-app
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-cluster:9092
        topic: secure-topic
        lagThreshold: "50"
      authenticationRef:
        name: kafka-auth

4.6 多触发器组合与伸缩策略

一个 ScaledObject 可以同时配置 多个触发器，KEDA 会取所有触发器中计算出的最大期望副本数作为最终值。这种模式适用于需要同时监听多个事件源的复杂场景。

spec:
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: sum(rate(http_requests_total[1m]))
        threshold: "100"
    - type: kafka
      metadata:
        bootstrapServers: kafka-cluster:9092
        topic: orders
        lagThreshold: "200"

当 Prometheus 查询结果和 Kafka 滞后指标同时生效时，KEDA 会选择两者中要求更高副本数的那个，确保系统能够应对最极端的负载情况。