2. GitOps 工作流：声明式配置、Git作为单一事实来源、自动同步机制、状态收敛与漂移检测

GitOps 工作流的核心在于将运维与部署的思维模式从“命令式操作”转变为“声明式期望”。本章深入剖析构成 GitOps 工作流的四大支柱：声明式配置、单一事实来源、自动同步机制以及状态收敛与漂移检测。理解这些概念是掌握 GitOps 同步复核的基础。

2.1 声明式配置：定义“期望状态”

声明式配置是 GitOps 的基石。它要求运维人员不再编写“如何做”的脚本（如：执行 kubectl apply、运行安装命令），而是直接定义系统“应该是什么样子”的最终状态文件。

• 命令式（Imperative）：关注步骤。例如：kubectl run nginx --image=nginx:1.25。
• 声明式（Declarative）：关注结果。例如：在 YAML 文件中定义 Deployment 对象，包含副本数、镜像版本、端口等。

以下是一个典型的 Kubernetes 声明式配置片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myregistry/my-app:v1.2.3
        ports:
        - containerPort: 8080

2.2 Git 作为单一事实来源（Single Source of Truth）

在 GitOps 模型中，Git 仓库不仅仅是代码的存储地，更是整个系统期望状态的权威数据库。所有环境（开发、预发布、生产）的声明式配置都必须存储在 Git 仓库中。

2.3 自动同步机制

自动同步是 GitOps Operator（如 Argo CD、Flux）的核心功能。它持续监控 Git 仓库中的声明式配置，并将其与集群中的实际运行状态进行对比。

同步流程通常包含以下步骤：

1. 轮询/Webhook 触发：Operator 定期轮询 Git 仓库（如每 3 分钟），或接收 Git Webhook 事件。
2. 拉取配置：从 Git 仓库拉取最新的声明式配置清单。
3. 差异对比：将拉取的期望状态与集群中的实时状态进行 Diff。
4. 执行同步：如果存在差异，Operator 自动执行 kubectl apply 或等效操作，将集群状态推向期望状态。

2.4 状态收敛与漂移检测

状态收敛是 GitOps 的最终目标，即系统实际状态始终与 Git 中定义的期望状态保持一致。漂移检测则是实现收敛的前提。

• 漂移（Drift）：指集群实际状态与 Git 仓库中期望状态之间的偏差。产生原因包括：人工直接修改集群资源（kubectl edit）、临时故障恢复脚本、配置管理工具误操作等。
• 漂移检测：Operator 通过定期比较 Git 中的 Manifest 与集群中的 Live State 来发现漂移。
• 状态收敛：一旦检测到漂移，Operator 自动执行同步操作，将集群状态“拉回”到期望状态。这通常被称为“自愈”能力。

2.5 工作流总结与同步复核切入点

GitOps 工作流形成了一个闭环：声明式配置 → Git 存储 → 自动同步 → 状态收敛。同步复核正是嵌入在这个闭环中的关键质量门禁。