1. GitOps 基础概念
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式基础设施与版本控制工作流相结合，通过自动化机制确保集群的实际状态始终与 Git 仓库中定义的期望状态保持一致。在 Kubernetes 生态中，GitOps 已成为管理复杂集群配置与持续交付的事实标准。
核心思想： 一切皆声明，一切皆入 Git，一切皆自动化。
1.2 核心原则
GitOps 建立在三条不可动摇的支柱之上，三者缺一不可：
| 原则 | 说明 | 关键要求 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态由配置文件完整描述，而非通过命令式指令逐步构建 | 所有资源（Deployment、Service、ConfigMap 等）必须使用 YAML/JSON 定义 |
| 版本控制（Version Controlled） | 所有声明式配置存储在 Git 仓库中，每次变更产生可追溯的提交记录 | 分支策略、PR 审查、标签与回滚机制 |
| 自动化（Automated） | 通过 Operator 或 Agent 自动将集群状态同步至 Git 中定义的期望状态 | 持续检测偏差、自动应用变更、失败告警 |
实践提示： 声明式配置是 GitOps 的基石。如果团队仍在使用
kubectl run 或 kubectl edit 直接修改集群，则尚未进入 GitOps 模式。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 流水线以“构建-测试-部署”的推送模式为主，而 GitOps 采用“拉取模式”与“持续协调”机制。以下对比表清晰展示了两者的核心差异：
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署触发方式 | CI 流水线完成后主动推送至目标环境 | Git 仓库变更触发 Operator 从仓库拉取期望状态 |
| 状态管理 | 部署工具维护状态，易出现配置漂移 | Git 仓库作为唯一事实来源，持续协调消除漂移 |
| 回滚策略 | 重新运行旧版本流水线或手动恢复 | git revert 提交即可触发自动回滚 |
| 权限模型 | CI 系统持有集群凭证，风险集中 | Operator 持有最小权限，变更需通过 Git PR 审查 |
| 环境一致性 | 依赖流水线脚本，不同环境可能产生差异 | 所有环境使用同一套声明式配置，差异仅通过 Overlay 管理 |
| 故障恢复 | 需要人工介入排查并修复 | Operator 自动检测偏差并尝试恢复至期望状态 |
1.4 GitOps 工作流架构
下图展示了 GitOps 的核心工作流：开发人员通过 Pull Request 修改 Git 仓库中的声明式配置，GitOps Operator（如 Argo CD 或 Flux）持续监控仓库变更，并将期望状态同步至 Kubernetes 集群。
1.5 GitOps 与传统 CI/CD 流水线对比图
以下图示从流水线结构角度对比两种模式：传统 CI/CD 采用“构建 → 测试 → 部署”的线性推送链，而 GitOps 将部署阶段解耦为 Git 提交与 Operator 协调两个独立环节。
1.6 为什么 GitOps 适合 K8s 调度优化
GitOps 与 Kubernetes 的结合为调度优化提供了天然的基础设施：
- 声明式调度策略： 节点亲和性、Pod 拓扑分布约束、资源配额等调度配置全部以声明式方式纳入 Git 管理，避免配置漂移。
- 可追溯的调度变更： 每次调度策略调整都对应一次 Git 提交，便于审计与回滚。
- 自动化同步窗口： 通过 GitOps Operator 的同步策略，可以精确控制调度变更的生效时间窗口，避免在业务高峰期触发大规模 Pod 重调度。
- 多集群一致性： 同一套调度配置可以跨集群复用，通过 GitOps 确保多集群调度行为一致。