1. GitOps 核心概念：声明式配置、期望状态与当前状态、Git 作为单一事实来源
GitOps 是一种以 Git 仓库为唯一权威来源的运维与交付模式。它要求整个系统的期望状态（Desired State）全部以声明式配置（Declarative Configuration）的形式存储在 Git 仓库中，并通过自动化机制持续将当前状态（Current State）向期望状态收敛。理解这三个核心概念是掌握 Argo CD 回滚验证的前提。
1.1 声明式配置
声明式配置描述的是系统“应该是什么”，而不是“如何去做”。在 Kubernetes 生态中，YAML 或 JSON 清单文件就是声明式配置的典型载体。
| 对比维度 | 声明式（Declarative） | 命令式（Imperative） |
|---|---|---|
| 关注点 | 最终结果（What） | 执行步骤（How） |
| 可复现性 | 高，同一配置产生相同结果 | 低，依赖执行顺序和环境 |
| 审计能力 | 强，配置即文档 | 弱，操作日志易丢失 |
| GitOps 适配 | 原生支持 | 不推荐 |
关键认知： 声明式配置是 GitOps 的“语言”。只有将系统状态描述为可版本化的配置文件，Git 才能成为单一事实来源。
1.2 期望状态与当前状态
GitOps 的核心循环围绕两个状态展开：
- 期望状态（Desired State）：存储在 Git 仓库中的声明式配置集合，代表团队对系统最终形态的共识。
- 当前状态（Current State）：集群中实际运行的资源实例，可能因手动变更、故障、升级中断等原因偏离期望状态。
Argo CD 作为 GitOps 控制器，持续执行“差异检测 → 自动/手动同步 → 状态收敛”的闭环。
# 期望状态示例（Git 仓库中的 Deployment 配置）
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: production
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: myregistry/my-app:v1.2.3
ports:
- containerPort: 8080
回滚视角： 回滚的本质是将期望状态“重置”为 Git 历史中的某个旧提交，Argo CD 随后自动将当前状态收敛到该旧期望状态。
1.3 Git 作为单一事实来源
在 GitOps 模型中，Git 仓库是唯一被信任的真相源。所有环境（开发、预发布、生产）的配置变更都必须通过 Pull Request 合并到 Git 仓库，再由自动化工具应用到集群。
这一原则带来的核心优势：
- 完整审计轨迹：每一次变更都有作者、时间戳、变更说明。
- 快速回滚：只需执行
git revert或切换到历史提交，即可触发全局状态恢复。 - 灾难恢复：集群完全损毁时，可从 Git 仓库重建所有资源。
- 协作基础：团队通过代码审查（Code Review）控制变更质量。
1.4 三者的协同关系
在回滚场景中，三个概念协同工作：
- 声明式配置 提供了可版本化的回滚单元。
- 期望状态 通过 Git 历史提交实现“时间旅行”。
- 当前状态 在 Argo CD 驱动下自动跟随期望状态变化。
常见误区： 不要将 Git 仓库仅当作备份存储。GitOps 要求所有变更必须经过 Git，任何绕过 Git 的集群手动修改都会导致“配置漂移”（Configuration Drift），破坏单一事实来源原则。
1.5 本章小结
- 声明式配置 是 GitOps 的输入格式，确保系统描述可版本化、可审计。
- 期望状态 vs 当前状态 的差异驱动了 GitOps 的自动化收敛循环。
- Git 作为单一事实来源 是回滚操作的基础——回滚即是将期望状态指向历史提交。