1. GitOps 核心概念：声明式配置、不可变基础设施、Git 作为单一事实来源
GitOps 是一套以 Git 仓库为运维中心的云原生交付模式。其核心思想可归纳为三个相互支撑的支柱：声明式配置、不可变基础设施、Git 作为单一事实来源。理解这三者之间的逻辑链条，是后续调度优化与同步窗口准入配置的基础。
1.1 声明式配置（Declarative Configuration）
声明式配置要求运维人员描述系统的期望状态，而非编写达到该状态的操作步骤。GitOps 控制器持续对比集群当前状态与 Git 仓库中的期望状态，并自动执行调和（Reconciliation）操作。
| 对比维度 | 声明式（Declarative） | 命令式（Imperative） |
|---|---|---|
| 关注点 | 系统应该是什么样子 | 如何一步步操作 |
| 幂等性 | 天然幂等，重复应用结果一致 | 需手动保证幂等，易产生漂移 |
| 版本管理 | YAML/JSON 文件可直接纳入 Git | CLI 命令难以追溯和回滚 |
| 典型工具 | Kubernetes YAML、Terraform、Crossplane | kubectl run、helm install 命令 |
| 适用场景 | 生产环境、合规审计、多集群 | 调试、临时测试、快速验证 |
实践要点：所有 Kubernetes 资源（Deployment、Service、ConfigMap 等）必须写成完整的 YAML 清单，存放在 Git 仓库中。禁止通过 kubectl edit 或 kubectl scale 直接修改集群状态。
1.2 不可变基础设施（Immutable Infrastructure）
不可变基础设施强调：一旦部署，运行中的组件不应被原地修改。任何变更都应通过替换整个组件（如重建 Pod、替换镜像版本）来实现。这一原则与 GitOps 的声明式调和机制天然契合——控制器检测到期望状态变化后，直接替换而非修补。
- 优势一：消除配置漂移 —— 服务器不会因为“临时修复”而偏离基线。
- 优势二：可预测回滚 —— 回滚只需将 Git 仓库中的配置恢复到旧版本，控制器自动重建。
- 优势三：一致性保障 —— 开发、测试、生产环境使用相同的镜像和配置清单。
- 优势四：安全合规 —— 所有变更都有 Git 记录，不存在“幽灵修改”。
常见误区：不可变不等于“不更新”。更新时通过修改 Git 仓库中的镜像标签或资源配置，触发控制器执行滚动替换。原地 exec 进入容器修改配置文件会破坏不可变原则，应通过 ConfigMap 版本更新来实现。
1.3 Git 作为单一事实来源（Single Source of Truth）
在 GitOps 体系中，Git 仓库不仅是代码存储库，更是整个集群的权威状态数据库。所有对集群的变更必须通过 Pull Request 提交到 Git，经审核后合并，再由 GitOps 控制器自动同步到目标环境。
# 典型的 GitOps 工作流示例
# 1. 开发者修改 deployment.yaml 中的镜像版本
# 2. 提交 PR 到 Git 仓库
# 3. 代码审查通过后合并到 main 分支
# 4. GitOps 控制器（如 Argo CD）检测到 main 分支变更
# 5. 控制器对比 Git 中的期望状态与集群当前状态
# 6. 控制器执行调和，将集群更新到期望状态
关键指标：Git 仓库应包含集群的完整配置——命名空间、RBAC、网络策略、存储类、监控告警规则等。任何无法从 Git 仓库重建的集群状态，都属于“不可审计的漂移”。
1.4 三者协同：GitOps 工作流全景
将上述三个概念串联起来，形成完整的 GitOps 工作流。下图展示了从代码提交到集群同步的端到端路径，以及调度优化与同步窗口准入配置在其中的位置。
1.5 核心概念总结
| 概念 | 一句话定义 | 对 GitOps 的价值 |
|---|---|---|
| 声明式配置 | 描述期望状态，而非操作步骤 | 使配置可版本化、可审计、可自动化调和 |
| 不可变基础设施 | 替换组件而非原地修改 | 消除配置漂移，保证环境一致性 |
| Git 单一事实来源 | Git 仓库是集群状态的权威记录 | 提供变更历史、回滚能力、协作基础 |