4. ScaledJob 基础：YAML 结构、触发器配置与并行控制

ScaledJob 是 KEDA 中专门用于管理 批处理任务 的核心 CRD。与 ScaledObject 持续运行 Pod 不同，ScaledJob 根据事件源驱动创建 Kubernetes Job 对象，每个 Job 执行一次后即完成。本章将深入解析 ScaledJob 的 YAML 结构、触发器配置、失败重试策略以及并行度控制机制。

4.1 ScaledJob YAML 结构解析

一个完整的 ScaledJob 定义包含四个核心部分：jobTargetRef（Job 模板）、triggers（事件源）、scalingStrategy（扩缩策略）和 failedJobsHistoryLimit（历史记录）。以下是一个基于 RabbitMQ 队列深度的典型示例：

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: rabbitmq-consumer-sj
  namespace: default
spec:
  # 1. Job 模板 —— 定义要运行的批处理任务
  jobTargetRef:
    template:
      spec:
        containers:
        - name: consumer
          image: myregistry/consumer:1.2
          command: ["python", "consume.py"]
          env:
          - name: QUEUE_NAME
            value: "orders"
        restartPolicy: Never
    backoffLimit: 3          # 失败重试次数
    ttlSecondsAfterFinished: 600  # Job 完成后保留 10 分钟

  # 2. 事件源触发器
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      queueLength: "10"      # 触发阈值：队列长度 >= 10
      host: amqp://guest:password@rabbitmq-svc:5672

  # 3. 扩缩策略
  scalingStrategy:
    strategy: "default"      # 可选：default / custom / accurate
    multipleScalersCalculation: "max"  # 多触发器时取最大值

  # 4. 历史记录与清理
  failedJobsHistoryLimit: 5
  successfulJobsHistoryLimit: 5

4.2 Job 触发器配置

ScaledJob 支持所有 KEDA 事件源，但触发行为与 ScaledObject 不同：ScaledJob 不维持 Pod 数量，而是根据事件源指标创建 Job 实例。常用触发器配置如下：

4.3 Job 失败重试策略

ScaledJob 的失败重试策略由 jobTargetRef 中的 backoffLimit 和 activeDeadlineSeconds 控制，同时 KEDA 提供 failedJobsHistoryLimit 管理历史记录。

4.3.1 重试机制层级

• Pod 级别重试： 由 Job 的 backoffLimit 控制，默认 6 次。Pod 失败后，Job 控制器重新创建 Pod，直到达到限制或成功。
• Job 级别重试： ScaledJob 不直接重试失败的 Job，而是通过 failedJobsHistoryLimit 保留失败记录，供运维排查。
• 全局超时： activeDeadlineSeconds 设置 Job 最大运行时间，超时后强制终止。

# 重试策略配置示例
jobTargetRef:
  template:
    spec:
      containers:
      - name: batch-worker
        image: batch-worker:latest
        command: ["/bin/sh", "-c", "process_data.sh"]
      restartPolicy: Never
  backoffLimit: 3            # 最多重试 3 次
  activeDeadlineSeconds: 300 # 5 分钟超时
  ttlSecondsAfterFinished: 120  # 完成后保留 2 分钟

4.4 Job 并行度控制

ScaledJob 的并行度控制通过 scalingStrategy 和 maxParallelism 实现，决定 同时运行多少个 Job 实例。

4.4.1 并行度参数

4.4.2 三种扩缩策略对比

• default： 根据触发器指标值直接计算 Job 数量。例如队列深度 50，阈值 10，则创建 5 个 Job。
• custom： 使用自定义公式计算 Job 数量，需配合 customScalingQueueLengthDeduction 等参数。
• accurate： 精确匹配指标值，每个指标单位对应一个 Job，适合严格资源隔离场景。

# 并行度控制完整示例
spec:
  maxParallelism: 10         # 最多同时运行 10 个 Job
  pollingInterval: 15        # 每 15 秒检查一次队列
  scalingStrategy:
    strategy: "default"
    multipleScalersCalculation: "max"
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      queueLength: "5"       # 每 5 条消息创建一个 Job
      host: amqp://...:5672

4.5 ScaledJob 生命周期与状态流转

以下 SVG 图展示了 ScaledJob 从事件触发到 Job 完成的完整生命周期：

4.6 实战配置清单

配置 ScaledJob 时，请按以下清单逐项确认：

1. Job 模板完整性： 确认 containers 镜像、命令、环境变量正确；restartPolicy 为 Never 或 OnFailure。
2. 触发器阈值： 根据任务处理能力设置合理的触发阈值，避免频繁创建或资源浪费。
3. 重试策略： backoffLimit 建议 3-5 次；activeDeadlineSeconds 根据任务最长耗时设置。
4. 并行度上限： maxParallelism 结合集群资源设置，防止突发流量打满集群。
5. 历史记录清理： failedJobsHistoryLimit 和 successfulJobsHistoryLimit 建议 5-10，避免 etcd 存储膨胀。
6. 轮询间隔： pollingInterval 默认 30 秒，对延迟敏感场景可调至 5-10 秒。