1. GitOps 基础概念：声明式部署、Git 作为单一事实来源、Pull vs Push 模式对比
GitOps 是一种以 Git 仓库为运维中心的云原生部署与运维模式。它将声明式配置、版本控制与自动化交付管道结合，使基础设施和应用状态始终与 Git 仓库中的期望状态保持一致。本节从三个核心维度拆解 GitOps 的基础概念。
1.1 声明式部署：描述“要什么”，而非“怎么做”
声明式部署的核心思想是：运维人员只需在配置文件中描述系统的期望状态（Desired State），由自动化工具负责将实际状态（Actual State）收敛至期望状态。这与传统的命令式部署（Imperative Deployment）形成鲜明对比。
| 对比维度 | 命令式部署 | 声明式部署（GitOps） |
|---|---|---|
| 操作方式 | 执行具体命令（如 kubectl run、kubectl scale） |
提交 YAML 清单到 Git，由控制器自动同步 |
| 状态管理 | 依赖操作者记忆或脚本顺序 | Git 仓库始终保存完整期望状态 |
| 回滚方式 | 手动执行反向操作或重新运行旧脚本 | git revert 后自动同步 |
| 可审计性 | 操作日志分散，难以追溯 | 每次变更都有 Git commit 记录 |
| 典型工具 | kubectl、Helm CLI |
Argo CD、Flux CD |
实践要点：声明式部署要求所有 Kubernetes 资源（Deployment、Service、ConfigMap 等）都以 YAML 形式存在于 Git 仓库中。任何手动
kubectl edit 或 kubectl patch 操作都会导致实际状态与 Git 仓库不一致，被 GitOps 控制器视为“漂移”并自动纠正。
1.2 Git 作为单一事实来源
在 GitOps 体系中，Git 仓库不仅是代码存储库，更是整个系统的单一事实来源（Single Source of Truth）。所有环境（开发、预发布、生产）的期望状态都定义在 Git 仓库中，且只有 Git 仓库中的配置被视为权威。
关键原则：Git 仓库中的配置是唯一可信的期望状态。任何对 Kubernetes 集群的手动修改都会被 GitOps 控制器检测为“配置漂移”，并在下一次同步周期中被自动覆盖回 Git 中定义的状态。这确保了环境的一致性和可复现性。
1.3 Pull vs Push 模式对比
GitOps 的部署模式分为 Pull 模式和 Push 模式，两者在部署触发方式、安全模型和适用场景上存在显著差异。
Push 模式（传统 CI/CD）
CI/CD 管道（如 Jenkins、GitLab CI）在构建完成后，主动将应用推送至目标 Kubernetes 集群。管道需要持有集群的访问凭证，通常通过 kubectl 或 Helm 客户端直接操作。
Pull 模式（GitOps 原生）
GitOps 控制器（如 Argo CD、Flux）运行在目标集群内部，主动从 Git 仓库拉取配置并同步到集群。CI 管道只需将镜像推送至镜像仓库并更新 Git 仓库中的清单文件，无需直接访问 Kubernetes 集群。
| 对比维度 | Push 模式 | Pull 模式（GitOps） |
|---|---|---|
| 部署触发 | CI 管道主动推送 | 控制器主动拉取 |
| 集群凭证 | CI 系统持有（安全风险高） | 集群内部持有（安全风险低） |
| 网络要求 | CI 系统需访问集群 API | 集群需访问 Git 仓库（通常更易满足） |
| 漂移检测 | 无内置机制 | 内置持续调和（Reconciliation） |
| 回滚操作 | 重新运行旧管道或手动执行 | git revert + 自动同步 |
| 多集群管理 | 需为每个集群配置独立管道 | 一个 Git 仓库管理多个集群 |
生产环境建议：在生产环境中，优先采用 Pull 模式部署 GitOps。如果网络限制导致集群无法直接访问 Git 仓库，可考虑在集群内部署 Git 仓库代理或使用 Git 仓库的只读镜像。避免为了短期便利而采用 Push 模式，否则将丧失 GitOps 的核心安全优势。
1.4 三者关系总结
声明式部署、Git 作为单一事实来源、Pull 模式三者共同构成了 GitOps 的三角基石：
- 声明式部署提供了配置的表达方式（YAML 清单），使系统状态可描述、可版本化。
- Git 作为单一事实来源提供了配置的存储与版本管理机制，确保所有变更可追溯、可审计。
- Pull 模式提供了部署的执行模型，使集群具备自愈能力，无需外部系统直接介入。