3. GitOps 工作流：Git 作为单一事实来源、声明式配置、Pull vs Push 模式、ArgoCD/Flux 等工具的角色
GitOps 的核心思想是将 Git 仓库作为整个基础设施和应用程序配置的单一事实来源（Single Source of Truth）。所有对环境状态的期望描述都存储在 Git 中，任何对集群的变更都必须通过修改 Git 仓库中的声明式配置文件来驱动。这种模式从根本上改变了运维人员与 Kubernetes 集群的交互方式，从“手动执行命令”转变为“自动同步期望状态”。
3.1 声明式配置：描述“想要什么”而非“如何做”
在 GitOps 工作流中，所有配置都是声明式（Declarative）的。这意味着用户只需要在 YAML 或 JSON 文件中描述集群的最终期望状态，而不需要编写一系列命令来达到该状态。Kubernetes 本身就是声明式 API 的典范，GitOps 将其扩展到了整个交付生命周期。
- 指令式（Imperative）： “运行 kubectl apply -f deployment.yaml，然后执行 kubectl rollout status，再手动修改 Service 类型。” —— 依赖操作者记忆和顺序。
- 声明式（Declarative）： “Git 仓库中定义了 Deployment 副本数为 3，Service 类型为 ClusterIP，Ingress 路由规则为 /api -> v2。” —— 系统自动计算差异并执行调和。
声明式配置的核心优势在于可审计性和可重现性。每一次环境变更都对应一次 Git 提交，可以随时回滚到任意历史版本。对于 Envoy 配置回滚场景，这意味着一旦发现新推送的 Envoy 路由规则导致流量异常，运维人员只需 revert 对应的 Git 提交，GitOps 工具会自动将集群状态恢复到上一个健康版本。
3.2 Pull vs Push 模式：两种同步哲学
GitOps 工具在实现“从 Git 同步到集群”的过程中，主要分为两种架构模式：Pull 模式和Push 模式。当前主流工具（如 ArgoCD、Flux）均采用 Pull 模式，因为它更符合安全性和去中心化的原则。
| 特性 | Pull 模式（主流） | Push 模式（传统 CI/CD） |
|---|---|---|
| 执行主体 | 集群内的 Operator/Agent | CI/CD 服务器（如 Jenkins） |
| 触发方式 | 定时轮询 Git 仓库或监听 Webhook | CI 流水线完成后主动推送 |
| 安全模型 | 集群无需暴露 API Server 给外部 | 需要将集群凭据注入 CI 系统 |
| 网络要求 | 集群可访问 Git 仓库（出站） | CI 服务器可访问集群（入站） |
| 典型工具 | ArgoCD, Flux, Jenkins X | 传统 CI/CD + kubectl apply |
| Envoy 回滚适用性 | 高（自动检测 Git 回滚并同步） | 低（依赖 CI 重新触发流水线） |
3.3 ArgoCD 与 Flux：两大 GitOps 工具的角色
在 Kubernetes 生态中，ArgoCD 和 Flux 是最主流的两个 GitOps 工具。它们都遵循 Pull 模式，但设计哲学和功能侧重点有所不同。理解它们的差异对于设计 Envoy 配置回滚的自动化测试策略至关重要。
3.3.1 ArgoCD：以应用为中心，Web UI 强大
- 核心概念： Application（应用）、Project（项目）、Sync Policy（同步策略）。
- 同步机制： 支持手动同步、自动同步、以及基于 Webhook 的事件驱动同步。
- 回滚能力： 内置资源历史版本管理，可以一键回滚到之前的任何同步状态。
- Envoy 场景优势： 清晰的“应用”边界非常适合管理 Envoy 的 xDS 配置或作为独立 Deployment 部署的 Envoy 代理。
3.3.2 Flux：以 Kubernetes 原生为中心，更轻量
- 核心概念： Source（源）、Kustomization（定制化）、HelmRelease（Helm 发布）。
- 同步机制： 基于 Source Controller 定期拉取 Git 仓库，通过 Kustomize 或 Helm 进行渲染和同步。
- 回滚能力： 依赖 Kubernetes 资源自身的版本管理，通过 Git revert 触发自动同步。
- Envoy 场景优势： 与 Kubernetes 资源模型深度集成，适合管理 Envoy 的 ConfigMap、Service、Deployment 等原生资源。
3.4 Git 作为单一事实来源的实践要点
在 GitOps 工作流中，Git 仓库不仅仅是代码存储库，更是整个系统的配置数据库和操作日志。为了确保 Envoy 配置回滚的可靠性和可测试性，需要遵循以下实践要点：
- 分支策略： 采用 GitFlow 或 Trunk-Based 开发模式。Envoy 配置的变更应通过 Pull Request 提交，经过 Code Review 和自动化测试后合并到主分支。
- 配置分离： 将 Envoy 的通用配置（如基础路由规则）与环境特定配置（如上游集群地址）分离，使用 Kustomize 或 Helm 进行渲染。
- 提交信息规范： 每个提交必须包含清晰的变更描述，便于在回滚时快速定位。例如：
fix: 回滚 Envoy 路由规则 /api/v2 到 /api/v1，修复 502 错误。 - 签名与验证： 对 Git 提交进行 GPG 签名，确保配置变更的可追溯性和防篡改性。
# 查看提交历史
git log --oneline --graph
# 找到需要回滚的提交（例如：abc1234 引入了有问题的 Envoy 路由）
git revert abc1234
# 推送回滚到远程仓库
git push origin main
# ArgoCD/Flux 自动检测到变更，将集群同步到回滚后的状态