2. GitOps 核心概念回顾：声明式配置、状态同步、Pull vs Push 模式、ArgoCD/Flux 简介
在深入 DNS 故障导致回滚的流水线集成案例之前，必须统一团队对 GitOps 核心概念的认知。本章将围绕四个支柱展开：声明式配置、状态同步、Pull 与 Push 模式，以及两大主流工具 ArgoCD 与 Flux 的定位差异。这些概念是后续理解“同步窗口”与“回滚触发”的基础。
2.1 声明式配置：期望状态即真理
GitOps 的第一原则是声明式配置。运维人员不再编写“如何做”的脚本（如：先执行 A 命令，再检查 B 端口），而是直接描述“系统应该长什么样”。
- 声明式文件：Kubernetes YAML、Helm values、Kustomize overlay 等。
- 单一事实来源：Git 仓库中存储的声明式配置是唯一的期望状态。
- 不可变基础设施：任何环境差异都通过修改 Git 中的声明来驱动，而非手动 SSH 登录。
关键区别： 传统运维是“命令式”（如何做），GitOps 是“声明式”（要什么）。例如：命令式会说“运行 kubectl scale deployment nginx --replicas=5”，声明式则是在 Git 中把 replicas 字段改为 5，由工具自动执行。
2.2 状态同步：从 Git 到集群的闭环
状态同步是 GitOps 的核心执行机制。系统持续比较 Git 中的期望状态 与 集群中的实际状态，并自动纠正偏差。
| 同步阶段 | 描述 | 常见触发条件 |
|---|---|---|
| 检测偏差 | 工具定期或事件驱动地对比 Git 与集群资源 | 定时轮询、Webhook、Git 提交 |
| 生成差异 | 计算期望状态与实际状态的 diff | 资源版本、标签、副本数变化 |
| 应用修正 | 执行 kubectl apply / helm upgrade 等操作 | 自动同步策略、手动批准 |
| 健康检查 | 验证应用是否达到 Running/Ready 状态 | Pod 状态、Deployment 可用性 |
同步窗口与回滚的关系： 当 DNS 故障导致集群无法拉取镜像时，同步操作会失败。如果配置了“自动回滚”，系统会将集群状态回退到上一个已知的 Git 提交，从而触发回滚流水线。
2.3 Pull 模式 vs Push 模式
GitOps 工具与集群的交互方式分为两种模式。理解它们的区别，有助于选择适合“同步窗口”场景的架构。
| 特性 | Pull 模式（推荐） | Push 模式（传统 CI/CD） |
|---|---|---|
| 触发方向 | 集群中的 Operator 主动拉取 Git 状态 | CI 流水线将状态推送到集群 |
| 安全模型 | 集群无需暴露 API Server 给外部 | 需要集群凭证暴露在 CI 系统中 |
| 网络依赖 | 集群出站到 Git（通常更稳定） | CI 系统入站到集群（易受 DNS/网络影响） |
| 同步窗口控制 | Operator 内置同步窗口、自动回滚策略 | 依赖 CI 流水线逻辑，实现复杂 |
| 典型工具 | ArgoCD、Flux | Jenkins + kubectl、GitLab CI + 直接部署 |
DNS 故障场景下的关键差异： 在 Push 模式下，如果 CI 系统无法解析集群域名，整个部署会直接失败且难以自动回滚。而在 Pull 模式下，Operator 在集群内部运行，即使外部 DNS 故障，Operator 仍能通过集群内部 DNS 或缓存访问 Git（如果 Git 也在集群内或使用 IP 直连），从而更可靠地执行回滚。
2.4 ArgoCD 与 Flux 简介
ArgoCD 和 Flux 是当前最主流的两个 GitOps 工具，都采用 Pull 模式。它们在“同步窗口”和“回滚策略”的实现上各有侧重。
| 特性 | ArgoCD | Flux |
|---|---|---|
| 架构 | Controller + API Server + UI | 单一 Controller（多版本演进） |
| 同步策略 | 支持自动同步、手动同步、同步窗口（Sync Windows） | 自动同步为主，支持 Kustomize/Helm 控制器 |
| 回滚机制 | 内置回滚到历史版本，支持 Prune 资源清理 | 通过 Git revert 或 Helm rollback 实现 |
| 健康检查 | 丰富的资源健康状态判断（L7 探测） | 依赖 Kubernetes 原生健康检查 |
| UI 与可观测性 | Web UI 强大，支持应用拓扑图 | CLI 为主，社区有第三方 UI |
| 适用场景 | 多集群管理、复杂同步窗口、审批流程 | 轻量级、纯 Git 驱动、与 Kustomize 深度集成 |
本课程选择 ArgoCD 的原因： 后续的 DNS 故障回滚案例中，我们需要演示“同步窗口”配置、自动回滚触发以及 UI 上的状态可视化。ArgoCD 的 Sync Windows 功能可以直接定义“允许同步的时间段”，当 DNS 故障导致同步失败时，ArgoCD 的自动回滚策略能更直观地展示回滚流水线的集成过程。
2.5 核心概念关系图
以下关系图总结了 GitOps 四个核心概念之间的依赖与协作关系，为后续章节的流水线设计奠定理论基础。
- 声明式配置 是 GitOps 的输入，存储在 Git 仓库中。
- 状态同步 是 GitOps 的执行引擎，持续对比并修正偏差。
- Pull 模式 是 GitOps 的推荐架构，由集群内的 Operator 驱动同步。
- ArgoCD/Flux 是 GitOps 的具体实现，封装了同步、回滚、健康检查等能力。
总结： 在 DNS 故障场景下，声明式配置确保回滚目标明确（Git 历史版本），状态同步机制自动检测失败并触发回滚，Pull 模式保障回滚操作不受外部 DNS 影响，ArgoCD 提供同步窗口和回滚流水线的集成接口。这四个概念环环相扣，构成了本案例的技术骨架。