1. GitOps 概述：定义、声明式模型核心思想与传统 CI/CD 的区别
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将整个系统的期望状态（Desired State）声明式地存储在 Git 中，并通过自动化机制持续确保运行环境与该期望状态保持一致。
核心公式： GitOps = 声明式基础设施 + 版本控制 + 自动化协调（Reconciliation）
GitOps 并非简单的“用 Git 管理配置”，而是一种将 Git 工作流（分支、合并、回滚、审批）直接映射到生产环境变更的工程实践。任何对集群的修改都必须通过 Pull Request 发起，经审核后合并到主分支，再由 Operator 自动同步到目标环境。
1.2 声明式模型核心思想
声明式模型（Declarative Model）是 GitOps 的基石。与命令式（Imperative）模型不同，声明式模型只描述“系统应该是什么状态”，而不描述“如何达到该状态”。
| 维度 | 命令式模型 | 声明式模型 |
|---|---|---|
| 操作方式 | 执行具体命令（kubectl run、kubectl scale） | 提交期望清单（YAML/JSON）到 Git |
| 状态管理 | 依赖操作者记忆和脚本顺序 | Git 仓库始终保存完整期望状态 |
| 回滚方式 | 反向执行命令或手动恢复 | git revert 到上一个期望状态版本 |
| 漂移检测 | 需要额外监控脚本 | Operator 自动检测并纠正漂移 |
| 审计能力 | 分散在终端日志中 | Git 提交历史即完整审计链 |
实践要点： 声明式模型要求运维人员从“如何操作”的思维转变为“如何定义”的思维。在灰度发布场景中，这意味着你不再手动调整副本数，而是修改 Git 中的 Deployment 清单，让 Operator 自动执行批次切换。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 管道（如 Jenkins、GitLab CI）侧重于“构建-测试-部署”的自动化流水线，而 GitOps 将部署环节从管道中剥离，交给独立的协调器（如 Argo CD、Flux）持续运行。
1.4 关键差异对比
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署触发 | 管道执行完毕即触发部署 | Git 仓库变更触发 Operator 同步 |
| 状态一致性 | 部署后不再关注环境漂移 | 持续检测并纠正漂移（Reconciliation Loop） |
| 回滚粒度 | 重新运行管道或手动回滚 | git revert + 自动同步 |
| 权限模型 | CI/CD 系统账号直接操作集群 | Operator 通过 Git 权限间接控制集群 |
| 审计追溯 | 管道日志 + 集群事件 | Git 提交历史 + 签名 + PR 讨论 |
| 灰度发布支持 | 需额外开发灰度逻辑 | 声明式清单天然支持分批、回滚、暂停 |
常见误区： GitOps 不是要取代 CI/CD，而是重新定义 CD 的职责边界。CI 阶段（构建、单元测试、镜像推送）仍然保留在传统管道中；CD 阶段（部署、协调、漂移检测）由 GitOps Operator 接管。在灰度批次场景中，这种分离使得运维人员可以独立控制发布节奏，而不受 CI 管道执行时间的限制。
1.5 灰度发布场景下的 GitOps 优势
- 批次清单留痕： 每次灰度批次的期望状态（如 10% → 30% → 100%）都以 Git 提交形式永久保存，支持精确回滚到任意批次。
- 审批与合规： 批次切换必须通过 PR 审批，满足金融、医疗等行业的变更管理要求。
- 自动漂移纠正： 如果某批次节点异常导致实际状态偏离期望状态，Operator 会自动尝试恢复，避免人工介入延迟。
- 多环境一致性： 同一套声明式清单可通过参数化（Kustomize/Helm）应用到开发、预发、生产环境，确保灰度策略可复现。
课程关联： 本章后续将深入讲解如何利用 GitOps 声明式模型，在灰度发布过程中实现批次运维清单的自动生成、版本留痕与审计追溯。你将看到 Git 提交如何成为每一次灰度操作的“数字签名”。