1.1 GitOps 定义与核心原则
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制与自动化协同结合，使基础设施和应用的变更可审计、可回滚、可复现。
1.1.1 GitOps 的三大核心原则
| 原则 | 说明 | 关键实践 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态以 YAML/JSON 等声明式文件描述，而非命令式脚本 | K8s 资源清单、Helm Chart、Kustomize 覆盖层 |
| 版本控制（Version Controlled） | 所有配置变更通过 Git commit 提交，仓库包含完整历史 | 分支策略、PR 审查、标签与 Release 管理 |
| 自动化（Automated） | Operator 或 Agent 持续对比仓库状态与集群状态，自动调和差异 | Argo CD、Flux、Jenkins X 的自动同步机制 |
实践要点：声明式是 GitOps 的基石。如果集群状态被手动修改（如
kubectl edit），GitOps Operator 会在下一次调和周期将其还原为仓库定义的状态，从而杜绝配置漂移。
1.1.2 GitOps 与传统 CI/CD 的核心差异
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 配置存储 | 数据库、CMDB、脚本参数 | Git 仓库（单一事实来源） |
| 部署触发 | CI 管道完成后 Push 到集群 | Git 仓库变更触发 Operator 自动同步 |
| 状态收敛 | 无自动回滚机制，依赖人工 | 持续调和，自动回滚至仓库期望状态 |
| 审计与追溯 | 分散在 CI 日志、数据库变更记录 | Git commit 历史 = 完整变更审计链 |
| 回滚方式 | 重新运行旧版本管道或手动恢复 | git revert 或切换分支，Operator 自动执行 |
| 多环境管理 | 环境配置散落，易出现漂移 | 每个环境对应 Git 分支或目录，配置一致 |
关键区别：传统 CI/CD 是“推送（Push）模式”——管道将构建产物推送到目标环境；GitOps 是“拉取（Pull）模式”——集群内的 Operator 主动从 Git 仓库拉取期望状态并执行调和。这种反转显著提升了安全性与可审计性。
1.1.3 GitOps 的自动化回滚优势
- 回滚即 Git 操作：执行
git revert <commit>或切换分支，Operator 自动将集群恢复至旧版本配置，无需重新触发 CI 构建。 - 原子性回滚：一次 commit 包含完整的环境配置，回滚时所有资源（Deployment、Service、ConfigMap 等）同步恢复，避免部分回滚导致的不一致。
- 审计链完整：每次回滚在 Git 历史中生成新的 commit，记录回滚原因、操作人、时间戳，满足合规审计要求。
- 多环境一致性：通过分支策略（如
main生产、staging预发），回滚时只需切换分支指向，Operator 自动同步。
常见误区：GitOps 不等于“用 Git 存 YAML”。真正的 GitOps 必须包含自动化调和机制（如 Argo CD 或 Flux），否则只是“Git 存储 + 手动部署”，无法实现自动回滚和状态收敛。
1.1.4 GitOps 适用场景与限制
| 场景 | 推荐度 | 说明 |
|---|---|---|
| K8s 原生应用部署 | ★★★★★ | 声明式资源 + 自动调和，天然匹配 |
| 微服务多环境管理 | ★★★★☆ | 分支/目录隔离，环境配置可追溯 |
| 数据库 Schema 变更 | ★★☆☆☆ | 状态型变更不适合纯声明式，需结合迁移工具 |
| 有状态应用（StatefulSet） | ★★★☆☆ | 需配合 Operator 处理持久化数据回滚 |