2. GitOps 核心概念：声明式配置、状态同步、Pull vs Push 模式
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维模型。其核心思想是将基础设施和应用的期望状态声明式地定义在 Git 仓库中，并通过自动化机制持续确保集群中的实际状态与仓库中的声明状态保持一致。理解声明式配置、状态同步以及 Pull/Push 模式是掌握 GitOps 的基础，也是后续实现自动化回滚与恢复的前提。
2.1 声明式配置（Declarative Configuration）
声明式配置是 GitOps 的基石。与命令式（Imperative）配置不同，声明式配置只关注“目标状态是什么”，而不关注“如何达到该状态”。
- 命令式（Imperative）：通过执行一系列具体指令来改变系统状态。例如：
kubectl run nginx --image=nginx:1.21、kubectl scale deployment nginx --replicas=5。这种方式难以追踪变更历史，且容易因操作顺序或环境差异导致状态不一致。 - 声明式（Declarative）：在 YAML 或 JSON 文件中定义系统的完整期望状态。例如：一个 Deployment YAML 文件定义了副本数、镜像版本、资源限制等。GitOps 工具负责将集群实际状态向该文件对齐。
| 特性 | 命令式配置 | 声明式配置 |
|---|---|---|
| 关注点 | 如何做（How） | 做什么（What） |
| 状态管理 | 通过操作序列管理 | 通过期望状态文件管理 |
| 可审计性 | 低，依赖操作日志 | 高，Git 提交记录即审计日志 |
| 回滚能力 | 困难，需逆向执行操作 | 简单，直接 revert Git 提交 |
| 环境漂移 | 容易发生 | 自动纠正，持续收敛 |
2.2 状态同步（State Synchronization）
状态同步是 GitOps 的核心执行机制。它通过一个闭环控制回路（Reconciliation Loop）持续比较 Git 仓库中的期望状态（Desired State）与集群中的实际状态（Actual State），并自动执行必要的操作使两者一致。
2.3 Pull vs Push 模式
GitOps 工具主要通过两种模式实现状态同步：Push 模式和 Pull 模式。两种模式在安全性、网络要求和适用场景上存在显著差异。
2.3.1 Push 模式
在 Push 模式下，CI/CD 管道或运维工具（如 Jenkins、GitHub Actions）直接向目标集群推送变更。通常，这些工具需要持有集群的 API Server 凭据，并具备直接执行 kubectl apply 或调用 API 的权限。
2.3.2 Pull 模式
在 Pull 模式下，集群内部署一个 Operator 或 Agent（如 Argo CD、Flux），该 Agent 主动从 Git 仓库拉取配置并同步到集群。Agent 只需要对 Git 仓库的只读访问权限，无需将集群凭据暴露给外部 CI/CD 系统。
2.4 三种模式对比总结
| 维度 | Push 模式 | Pull 模式 |
|---|---|---|
| 安全模型 | 凭据外泄风险高 | 凭据内聚，风险低 |
| 网络流向 | CI/CD → 集群（入站） | 集群 → Git（出站） |
| 同步触发 | 外部事件驱动（如代码合并） | 定时轮询或 Webhook 通知 |
| 多集群管理 | 需为每个集群配置独立管道 | 一个 Git 仓库可管理多集群 |
| 回滚速度 | 依赖 CI/CD 管道重新执行 | Agent 检测到 Git revert 后自动同步 |
| 典型工具 | Spinnaker, Jenkins X | Argo CD, Flux, Rancher Fleet |
2.5 与 Envoy 故障回滚的关联
在 GitOps 框架下，Envoy 配置（如 EnvoyFilter、Listener、Cluster 等 CRD）被声明式地定义在 Git 仓库中。当一次错误的配置变更被合并到主分支后：
- Pull 模式 Agent（如 Argo CD）会在下一个同步周期拉取该变更，并将其应用到集群。
- 如果该配置导致 Envoy 崩溃、连接中断或路由错误，监控系统会检测到故障。
- 自动化回滚策略的核心就是：在同步窗口内，快速识别出导致故障的 Git 提交，并自动执行
git revert操作。 - Agent 在下一个同步周期检测到 Git 仓库的期望状态已回退，便会自动将集群状态恢复至故障前的健康版本。