📚 课程目录第1章课程导论

1. 课程导论：GitOps核心原则、同步窗口概念、DNS故障在GitOps中的典型影响

1.1 GitOps 核心原则

GitOps 是一种以声明式描述和版本控制（Git）为单一事实来源的运维模型。其核心原则可归纳为以下四点：

原则	说明	关键要求
声明式描述	整个系统的期望状态（应用、基础设施、配置）以声明式清单定义，存储在 Git 仓库中。	所有变更必须通过修改清单文件完成，禁止手动操作运行时环境。
版本控制与不可变历史	Git 仓库记录每一次变更的完整历史，支持审计、回滚、分支策略和协作评审。	每次提交对应一个可追溯的原子变更，回滚即 revert 或 reset 到历史 commit。
自动同步	集群中运行一个 Operator（如 Argo CD、Flux），持续对比 Git 中的期望状态与集群中的实际状态，自动执行差异修正。	同步策略可配置（自动/手动/窗口），但最终目标是将集群状态收敛到 Git 定义。
自愈与收敛	当集群状态因故障、误操作或外部干扰偏离 Git 定义时，Operator 自动将其拉回期望状态。	自愈能力依赖 Operator 的持续调和（Reconciliation）循环。

  关键认知： GitOps 的“自愈”并非万能——当 Git 仓库本身或 Operator 依赖的外部服务（如 DNS）出现故障时，同步行为可能产生非预期后果。这正是本课程要解决的核心矛盾。

1.2 同步窗口概念

同步窗口（Sync Window）是 GitOps Operator 提供的一种时间策略机制，用于控制自动同步的生效时段。其设计目的是在变更风险较高的时段（如业务高峰期、维护窗口外）抑制自动调和，避免意外触发大规模回滚或部署。

同步窗口的核心参数包括：

窗口类型： allow（允许同步）或 deny（禁止同步）。
时间表达式： 基于 Cron 或 Duration 定义生效时段（如 0 0 2-4 * * * 表示凌晨 2-4 点允许同步）。
作用范围： 可应用于整个集群、特定 Application 或 Namespace。
超时行为： 窗口关闭时，正在进行的同步是否立即终止或允许完成。

# Argo CD Sync Window 示例（Application 级别）
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
spec:
  syncWindows:
  - kind: deny
    schedule: "0 0 8-20 * * *"   # 每天 8:00-20:00 禁止自动同步
    duration: 12h
    applications:
    - "prod-*"
    clusters:
    - "https://prod-cluster:6443"
    namespaces:
    - "production"
  - kind: allow
    schedule: "0 0 22-6 * * *"   # 每天 22:00-06:00 允许自动同步
    duration: 8h

实践建议： 同步窗口应结合变更风险等级设置。核心生产服务建议使用 deny 窗口覆盖业务高峰时段，仅保留低峰期自动同步；非关键环境可保持 7×24 自动同步。

1.3 DNS 故障在 GitOps 中的典型影响

DNS（Domain Name System）是 GitOps 工作流中隐式但关键的依赖。当 DNS 解析出现故障时，GitOps 的同步和自愈机制可能产生以下典型影响：

故障场景	影响链路	典型后果
Git 仓库域名解析失败	Operator → DNS → Git Server	Operator 无法拉取最新清单，同步停滞；若同时触发自愈，可能误判集群状态为“偏离”，反复重试导致资源消耗。
容器镜像仓库域名解析失败	Kubelet → DNS → Registry	新 Pod 无法拉取镜像，部署卡在 `ImagePullBackOff`；旧 Pod 可能被自动缩容，造成服务降级。
集群 API Server 域名解析失败	Operator → DNS → API Server	Operator 无法连接集群，同步和自愈完全中断；集群内其他组件也可能出现通信异常。
外部依赖服务域名解析失败	应用 Pod → DNS → 外部 API	业务功能受损，但 GitOps 可能误认为“集群状态正常”，不会触发回滚，形成静默故障。

风险提示： DNS 故障在 GitOps 中具有“放大效应”——一次短暂的 DNS 抖动，可能被 Operator 的自动同步和自愈循环放大为大规模回滚或部署风暴。同步窗口若未考虑 DNS 依赖，反而可能加剧故障。

1.4 DNS 故障与同步窗口的冲突关系

下图展示了 DNS 故障发生时，同步窗口机制可能面临的典型冲突场景：

上图中，DNS 故障导致 Operator 无法从 Git 仓库拉取期望状态，同时同步窗口处于 deny 状态，禁止手动同步或回滚。此时集群处于“盲飞”状态——Operator 既无法自愈，也无法接受新的变更指令，故障恢复窗口被压缩。

1.5 课程目标与解决思路

本课程旨在设计一套 DNS 故障感知的 GitOps 同步窗口回滚机制，核心解决思路包括：

DNS 健康探测集成： 在同步窗口决策链路中引入 DNS 解析状态检查，当检测到关键域名解析失败时，自动触发回滚策略。
故障分级与回滚策略： 根据 DNS 故障影响范围（Git 仓库、镜像仓库、API Server）定义不同回滚等级，避免一刀切。
同步窗口自适应调整： 在 DNS 故障期间自动切换同步窗口为 allow 或缩短窗口周期，允许紧急回滚操作。
回滚安： 确保回滚操作本身不依赖 DNS 解析（如使用本地缓存或直连 IP），避免回滚动作被二次故障阻断。

  课程产出： 完成本课程后，你将掌握一套可落地的 GitOps 故障回滚框架，能够在不依赖 DNS 的情况下安全回滚集群状态，并设计出适应 DNS 故障的同步窗口策略。