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

GitOps 的核心工作流程围绕四个关键概念构建：声明式配置、Git 作为单一事实来源、自动同步机制以及状态收敛与漂移检测。理解这些概念是掌握 GitOps 回滚操作的基础，因为每一次回滚本质上都是对这四个环节的重新协调。

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

声明式配置是 GitOps 的基石。与传统的“命令式”操作（手动执行 kubectl run 或 kubectl scale）不同，声明式配置要求你描述系统的最终期望状态，而非达成该状态的步骤。

• 命令式：“创建 3 个 Nginx 副本”（关注操作步骤）。
• 声明式：“副本数为 3 的 Nginx Deployment”（关注最终结果）。

在 Kubernetes 生态中，声明式配置通常以 YAML 或 JSON 文件的形式存在。以下是一个典型的声明式 Deployment 配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-registry/my-app:v2.1.0
        ports:
        - containerPort: 8080

这份文件明确声明了：运行 3 个副本、使用 v2.1.0 镜像、监听 8080 端口。GitOps 工具（如 Argo CD 或 Flux）会确保集群中的实际状态与这份声明完全一致。

2.2 Git 作为单一事实来源

在 GitOps 模型中，Git 仓库是系统期望状态的唯一权威来源。这意味着：

• 所有环境（开发、预发布、生产）的配置都必须存储在 Git 中。
• 任何对集群的手动修改（kubectl edit）都被视为“漂移”，会被自动检测并覆盖。
• Git 的提交历史提供了完整的变更审计轨迹，这是回滚操作的基础。

下表对比了传统运维与 GitOps 在配置来源上的差异：

2.3 自动同步机制

自动同步是 GitOps 的“执行引擎”。它持续监控 Git 仓库中的配置变化，并将这些变化自动应用到目标集群。同步机制通常包含以下步骤：

1. 检测变更：GitOps 操作器（Operator）定期轮询 Git 仓库，或通过 Webhook 接收变更通知。
2. 拉取配置：操作器从 Git 仓库拉取最新的声明式配置文件。
3. 对比差异：操作器将 Git 中的期望状态与集群中的实际状态进行对比。
4. 应用变更：如果存在差异，操作器通过 Kubernetes API 应用必要的创建、更新或删除操作。
5. 状态报告：操作器将同步结果（成功/失败）写回集群状态，并可选地通知用户。

以下 SVG 图展示了自动同步的完整流程：

2.4 状态收敛与漂移检测

状态收敛是 GitOps 的“自愈”能力。当集群实际状态与 Git 中定义的期望状态不一致时，GitOps 工具会主动采取行动，将集群状态“收敛”回期望状态。这种不一致被称为配置漂移。

2.4.1 漂移的常见原因

• 手动干预：运维人员直接使用 kubectl scale 或 kubectl edit 修改了集群资源。
• 故障恢复：Pod 因节点故障被重新调度到其他节点，导致副本数或配置发生变化。
• 外部系统影响：HPA（水平自动扩缩）或 Cluster Autoscaler 等组件自动调整了资源。
• 配置错误：Git 仓库中的配置被错误地修改或删除。

2.4.2 漂移检测与收敛流程

GitOps 操作器通过持续的“期望状态 vs 实际状态”对比来检测漂移。以下 SVG 图展示了漂移检测与收敛的完整闭环：

2.5 回滚视角下的工作流程整合

将上述四个概念整合到回滚场景中，可以清晰地看到 GitOps 回滚的本质：

具体步骤如下：

1. 定位问题版本：通过 Git 提交历史找到引入问题的 commit。
2. 执行回滚：使用 git revert <commit-hash> 创建一个新的“回滚 commit”。
3. 推送变更：将回滚 commit 推送到 Git 仓库。
4. 自动同步：GitOps 操作器检测到 Git 仓库变化，开始同步。
5. 状态收敛：操作器将集群状态从“当前错误版本”收敛到“回滚后的旧版本”。
6. 验证确认：确认集群状态与 Git 中的期望状态一致，回滚完成。

下表总结了 GitOps 工作流程中四个核心概念在回滚场景中的角色：