3. GitOps 工作流：声明式配置、Git 仓库作为单一事实来源、Operator 模式（ArgoCD/Flux）
GitOps 的核心是将运维与部署的“期望状态”全部声明在 Git 仓库中，并通过自动化 Operator 持续调和集群实际状态。本章拆解 GitOps 工作流的三大支柱：声明式配置、单一事实来源、Operator 模式，并对比 ArgoCD 与 Flux 的实现差异。
3.1 声明式配置：从“如何做”到“要什么”
传统运维依赖脚本或命令式指令（kubectl run、helm install），而 GitOps 要求所有资源以 YAML/JSON 声明文件形式存在。声明式配置具备以下特征：
- 幂等性：同一份声明反复应用，结果始终一致。
- 可审计：每次变更都对应 Git commit，可追溯、可回滚。
- 可版本化：声明文件与代码分支、标签绑定，支持环境隔离。
| 对比维度 | 命令式（Imperative） | 声明式（Declarative） |
|---|---|---|
| 操作方式 | 执行命令/脚本，逐步操作 | 提交期望状态文件，自动调和 |
| 状态管理 | 依赖操作者记忆或外部状态库 | Git 仓库始终是权威状态 |
| 回滚复杂度 | 需逆向执行或手动恢复 | git revert + Operator 自动同步 |
| 典型工具 | kubectl run/delete, helm upgrade --reuse-values | ArgoCD Application, Flux Kustomization |
关键原则：声明式配置必须完整描述目标状态，不依赖集群当前状态。例如 Deployment 必须包含 replicas、image、ports 等全部字段，Operator 不会自动补全缺失值。
3.2 Git 仓库作为单一事实来源（Single Source of Truth）
在 GitOps 模型中，Git 仓库不仅是代码存储，更是整个系统的“期望状态数据库”。所有环境（开发、预发、生产）的配置都集中管理，Operator 持续对比 Git 中的声明与集群实际状态。
单一事实来源带来的核心收益：
- 一致性：所有集群从同一份配置派生，消除环境漂移。
- 可复现：任何时间点的集群状态都可以通过 checkout 对应 commit 重建。
- 权限收敛：只有 Git 仓库的写入权限能改变生产配置，集群凭证无需暴露给开发者。
3.3 Operator 模式：ArgoCD 与 Flux 的调和循环
Operator 模式是 GitOps 的执行引擎。Operator 是一个运行在集群内的控制器，持续执行“读取期望状态 → 对比实际状态 → 执行调和操作”的循环。ArgoCD 和 Flux 是目前最主流的两个实现。
3.3.1 调和循环（Reconciliation Loop）
- Poll / Webhook：定期轮询 Git 仓库或接收 Webhook 通知。
- Diff：对比 Git 中的声明式配置与集群当前资源状态。
- Apply / Prune：创建、更新或删除资源使集群对齐期望状态。
- Health Check：验证资源是否达到就绪状态（如 Deployment 的 Available 条件）。
- Report：将同步结果写回状态字段或外部监控系统。
3.3.2 ArgoCD vs Flux：核心差异
| 对比维度 | ArgoCD | Flux |
|---|---|---|
| 架构模式 | Pull-based + 可选 Push | Pull-based（专注 Git 驱动） |
| 配置源 | Git 仓库、Helm Chart、Kustomize、OCI | Git 仓库、Helm Chart、OCI、Bucket |
| 同步策略 | 自动同步 + 手动同步 + 同步窗口 | 自动同步 + 手动同步 + 暂停/恢复 |
| 回滚能力 | 内置回滚 UI/CLI，保留历史 | 依赖 git revert 或 Flux 自动回滚 |
| 多集群管理 | 原生支持（ApplicationSet） | 通过 Kustomize 或 Cluster API |
| 安全模型 | RBAC + SSO + 项目隔离 | RBAC + 多租户（Tenancy） |
选型建议：如果团队需要丰富的 UI 界面、多集群管理和细粒度同步窗口控制，ArgoCD 更合适；如果追求轻量、纯 Git 驱动、与 Kubernetes 原生 CRD 深度集成，Flux 是更简洁的选择。
3.4 声明式配置示例：ArgoCD Application
以下是一个完整的 ArgoCD Application 声明，展示如何将 Git 仓库中的配置同步到目标集群：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: production-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/team/production-config.git
targetRevision: main
path: overlays/production
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
- ApplyOutOfSyncOnly=true
syncWindow:
kind: "deny"
schedule: "0 0 * * *"
duration: "8h"
applications:
- "production-app"
注意：
syncWindow 字段是本章后续 DNS 故障回滚设计的核心。通过定义拒绝同步窗口，可以防止在 DNS 故障期间 Operator 自动执行破坏性变更。具体窗口策略将在第 5 章详细展开。
3.5 本章小结
- GitOps 工作流以声明式配置为基础，消除命令式运维的不可预测性。
- Git 仓库作为单一事实来源，确保所有环境配置可追溯、可复现、可回滚。
- Operator 模式（ArgoCD/Flux）通过持续调和循环，自动将集群实际状态对齐 Git 期望状态。
- ArgoCD 和 Flux 在架构、同步策略、回滚能力上各有侧重，选择需结合团队运维习惯和基础设施规模。