2. GitOps 工作流：Pull vs Push 模式、Git 作为单一事实来源、状态收敛机制

GitOps 的核心在于将 Git 仓库作为整个交付管线的“单一事实来源”（Single Source of Truth），并通过自动化机制确保运行环境的状态始终与仓库中声明的期望状态保持一致。本章深入剖析 GitOps 工作流的两种驱动模式、Git 仓库的权威角色以及状态收敛的底层原理。

2.1 两种驱动模式：Push 与 Pull

传统 CI/CD 流水线多采用 Push 模式：CI 服务器在构建完成后，主动将制品或配置“推送”到目标环境。GitOps 则倡导 Pull 模式：运行在目标环境中的 Operator（操作器）主动从 Git 仓库“拉取”期望状态并执行同步。下表对比了两种模式的核心差异：

下图展示了两种模式在架构层面的本质区别：

2.2 Git 作为单一事实来源

在 GitOps 体系中，Git 仓库不再仅仅是代码托管平台，而是整个系统状态的权威数据库。所有与环境相关的声明性配置——包括部署清单、ConfigMap、Secret 引用、网络策略、存储卷声明等——都必须存储在 Git 仓库中。

Git 仓库作为单一事实来源需满足以下原则：

• 声明性（Declarative）：仓库中存储的是“期望状态”的描述，而非达到该状态的命令序列。
• 不可变（Immutable）：任何环境变更都必须通过 Git 提交（Commit）发起，禁止手动修改运行环境。
• 可审计（Auditable）：每一次变更都记录在 Git 历史中，包含提交者、时间戳、变更内容及关联的 MR/PR。
• 可回滚（Rollback-ready）：通过 git revert 或切换到历史提交即可将环境恢复至任意已知状态。

典型的 GitOps 仓库结构示例如下：

gitops-infra/
├── base/                          # 公共基础配置
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
├── overlays/
│   ├── dev/                       # 开发环境覆盖
│   │   ├── kustomization.yaml
│   │   ├── configmap-patch.yaml
│   │   └── replica-count.yaml
│   ├── staging/                   # 预发布环境覆盖
│   │   ├── kustomization.yaml
│   │   └── ingress.yaml
│   └── prod/                      # 生产环境覆盖
│       ├── kustomization.yaml
│       ├── hpa.yaml
│       └── pdb.yaml
└── README.md

2.3 状态收敛机制

状态收敛（State Reconciliation）是 GitOps 工作流的核心闭环。Operator 通过持续的“对比-修正”循环，确保运行环境的实际状态与 Git 仓库中声明的期望状态保持一致。当两者出现偏差时，Operator 会自动执行修正操作，将环境拉回期望状态。

收敛循环通常包含以下四个步骤：

1. 检测（Detect）：Operator 定期（如每 3 分钟）或通过 Webhook 触发，对比 Git 仓库中的期望清单与集群中的实际资源。
2. 差异分析（Diff）：生成期望状态与实际状态之间的差异报告，识别出新增、修改、删除的资源。
3. 修正（Reconcile）：自动应用差异补丁，创建/更新/删除 Kubernetes 资源，使集群状态向期望状态对齐。
4. 反馈（Feedback）：将同步结果（成功/失败、资源状态、事件日志）写回 Git 仓库或通知外部系统。

下图展示了 GitOps 状态收敛的完整闭环：

2.4 三种收敛策略对比

不同的 GitOps 工具在实现状态收敛时采用不同的策略，下表对比了三种主流方式：