📚 课程目录第4章 Scheduler概念解析

4. Scheduler 概念解析：CronJob、Workflow Scheduler、事件驱动调度、定时同步触发器

在平台门户集成调度器与 GitOps 同步窗口的架构中，理解四种核心调度概念是参数优化与窗口对齐的前提。每种调度模式解决不同场景下的定时、触发与编排需求，错误的选型会直接导致同步冲突或资源浪费。

4.1 四种调度模式对比总览

调度模式	核心机制	典型场景	同步窗口适配度
CronJob	基于 Unix Cron 表达式的固定周期执行	定时清理、定期备份、固定频率同步	高（窗口可预计算）
Workflow Scheduler	DAG 依赖驱动的多步骤编排调度	CI/CD 流水线、数据管道、多阶段部署	中（依赖链影响窗口）
事件驱动调度	监听外部事件（Webhook、消息队列）触发执行	Git Push 触发同步、配置变更响应	低（不可预测）
定时同步触发器	固定间隔或日历时间点的同步专用触发器	GitOps 定期 reconcile、状态快照	高（窗口对齐核心）

选型建议： 平台门户集成 GitOps 同步窗口时，优先使用定时同步触发器作为主调度，CronJob作为辅助清理任务，事件驱动调度仅用于紧急热修复场景，避免破坏窗口稳定性。

4.2 CronJob：固定周期执行的基础单元

CronJob 是 Kubernetes 原生调度资源，使用标准 Cron 表达式定义执行时间。在平台门户中，CronJob 常用于数据库备份、日志轮转、指标采集等无状态定时任务。

# 标准 CronJob 定义示例
apiVersion: batch/v1
kind: CronJob
metadata:
  name: sync-window-cleaner
spec:
  schedule: "0 */2 * * *"   # 每2小时执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleaner
            image: platform/cleaner:1.0
            args: ["--window", "sync-window-01"]
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1

  参数优化要点：
  concurrencyPolicy：设置为 Forbid 防止窗口重叠
startingDeadlineSeconds：根据窗口长度设置合理超时
successfulJobsHistoryLimit：控制历史记录避免 etcd 压力

4.3 Workflow Scheduler：DAG 依赖驱动的编排调度

Workflow Scheduler 管理具有依赖关系的多步骤任务，每个步骤称为一个 Task，Task 之间通过 DAG（有向无环图）定义执行顺序。在 GitOps 同步场景中，Workflow Scheduler 负责编排：代码检查 → 镜像构建 → 环境部署 → 健康检查 → 同步确认。

# Workflow DAG 定义示例（伪代码）
workflow:
  name: deploy-and-sync
  tasks:
    - name: code-check
      depends_on: []
    - name: build-image
      depends_on: [code-check]
    - name: deploy-staging
      depends_on: [build-image]
    - name: health-check
      depends_on: [deploy-staging]
    - name: gitops-sync
      depends_on: [health-check]
      sync_window: "sync-window-01"

常见陷阱： Workflow Scheduler 的依赖链可能导致同步窗口错过。如果 health-check 耗时超过预期，gitops-sync 可能无法在窗口关闭前完成。建议为每个 Task 设置独立的 timeout，并在 Workflow 级别设置总超时。

4.4 事件驱动调度：响应式触发与窗口冲突

事件驱动调度不依赖固定时间，而是监听 Git Push、Webhook、消息队列等事件触发执行。这种模式响应快，但会破坏同步窗口的可预测性。平台门户集成时，需要为事件驱动调度设置节流（Throttling）和窗口准入检查。

节流策略：同一事件源在窗口期内最多触发 N 次
窗口准入：事件触发时检查当前是否在同步窗口内，不在则排队或丢弃
优先级队列：紧急事件（安全修复）可跳过窗口限制

4.5 定时同步触发器：GitOps 同步窗口的核心

定时同步触发器是专门为 GitOps 同步设计的调度单元，它结合了 CronJob 的固定周期和 Workflow Scheduler 的依赖管理，同时加入窗口感知能力。平台门户通过定时同步触发器实现：

窗口对齐：触发器只在配置的同步窗口内执行
状态一致性：每次触发执行完整的 reconcile 流程
失败重试：窗口内允许重试，窗口外等待下一周期

# 定时同步触发器配置示例
syncTrigger:
  name: main-sync-trigger
  schedule: "0 */4 * * *"        # 每4小时触发
  window: "sync-window-01"        # 绑定同步窗口
  retryPolicy:
    maxRetries: 3
    retryInterval: "5m"
  concurrency: Forbid
  timeout: "30m"

4.6 四种调度模式的关系与集成架构

下图展示了四种调度模式在平台门户中的集成关系，以及它们如何与 GitOps 同步窗口交互。

4.7 调度模式选型决策矩阵

根据平台门户的实际需求，使用以下矩阵快速选择最合适的调度模式：

需求特征	推荐模式	不推荐模式	原因
固定时间备份/清理	CronJob	事件驱动调度	事件驱动无法保证固定时间执行
多步骤部署流水线	Workflow Scheduler	CronJob	CronJob 无法表达依赖关系
Git Push 即时同步	事件驱动调度	定时同步触发器	定时触发无法满足即时性
窗口内定期 reconcile	定时同步触发器	Workflow Scheduler	Workflow 编排过重，增加延迟
混合场景（定时+事件）	定时同步触发器 + 事件驱动调度	单一模式	需要组合满足不同需求

  最佳实践： 平台门户集成时，建议将定时同步触发器作为主调度，CronJob作为辅助任务调度，Workflow Scheduler用于复杂编排，事件驱动调度仅用于紧急热修复。所有调度模式必须通过调度器核心的窗口准入检查，确保不破坏同步窗口的稳定性。