3. ScaledJob 基础：与 ScaledObject 的差异及核心配置

在 KEDA 的触发体系中，ScaledJob 与 ScaledObject 是两种截然不同的工作负载扩展模式。ScaledObject 面向长期运行的 Service/Deployment，而 ScaledJob 专为批处理、一次性任务设计。理解两者的差异是正确配置事件驱动 Job 的前提。

3.1 ScaledJob 与 ScaledObject 的核心区别

3.2 Job 触发模式：事件源如何驱动 Job 创建

ScaledJob 的触发模式遵循“事件源 → ScaledJob → Job 创建”的链路。KEDA 控制器监听事件源（如 Kafka、RabbitMQ、AWS SQS）的消息积压情况，当消息数量超过阈值时，自动创建 Kubernetes Job 来处理这些消息。

3.3 scalingStrategy 配置：控制 Job 的创建速率

scalingStrategy 是 ScaledJob 特有的参数，用于控制当事件源消息积压时，KEDA 以何种策略创建 Job。默认策略是 default，即每个消息创建一个 Job；但在高吞吐场景下，需要调整策略以避免 Job 创建风暴。

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: batch-processor
spec:
  jobTargetRef:
    template:
      spec:
        containers:
        - name: worker
          image: myrepo/batch-worker:latest
        restartPolicy: Never
  triggers:
  - type: kafka
    metadata:
      topic: events
      bootstrapServers: kafka-cluster:9092
      consumerGroup: batch-group
      lagThreshold: "10"
  scalingStrategy:
    strategy: custom
    customScalingQueueLengthDeduction: "1"
    customScalingMetricSpec: "5"        # 每秒最多创建 5 个 Job
    customScalingCooldownPeriod: "30"   # 冷却期 30 秒
  maxReplicaCount: 20

3.4 rollingUpdate 与 executionTimeout：Job 的生命周期控制

ScaledJob 提供了两个关键参数来控制 Job 的更新策略和执行超时，确保批处理任务在异常情况下不会无限期占用资源。

3.4.1 rollingUpdate

rollingUpdate 控制当 ScaledJob 配置更新时，如何处理正在运行的 Job。与 Deployment 的滚动更新不同，ScaledJob 的滚动更新只影响新创建的 Job，不会中断正在执行的 Job。

3.4.2 executionTimeout

executionTimeout 是 ScaledJob 的全局超时控制，用于限制单个 Job 的最大执行时间。如果 Job 在超时时间内未完成，KEDA 会强制终止该 Job 并标记为失败。

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: timeout-controlled-job
spec:
  jobTargetRef:
    template:
      spec:
        containers:
        - name: worker
          image: myrepo/worker:latest
          command: ["/bin/sh", "-c", "process_data.sh"]
        restartPolicy: Never
    backoffLimit: 3
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.region.amazonaws.com/123456789/myqueue
      queueLength: "5"
  executionTimeout: 300   # 单个 Job 最长执行 300 秒
  maxReplicaCount: 10

3.5 最佳实践与常见陷阱

• 避免 Job 创建风暴：在消息积压量较大时，使用 custom 策略配合 customScalingMetricSpec 限制每秒 Job 创建数，防止 API Server 过载。
• 合理设置 executionTimeout：根据业务处理时间的 P99 值设置超时，通常为平均处理时间的 3-5 倍。过短会导致正常任务被误杀，过长则浪费资源。
• 监控 Job 完成状态：ScaledJob 不会自动重试失败的 Job，需要依赖 Kubernetes Job 的 backoffLimit 机制。建议将 backoffLimit 设置为 2-3 次。
• 资源配额规划：ScaledJob 的 maxReplicaCount 应与集群资源配额匹配，避免创建过多 Job 导致节点资源耗尽。