GitOps 基础：声明式配置与期望状态、Git 作为单一事实来源、Pull vs Push 模式对比
GitOps 是一种以 Git 仓库为单一事实来源（Single Source of Truth）的云原生运维模式。其核心思想是将声明式配置与自动化协调循环相结合，确保集群的实际运行状态始终与 Git 仓库中定义的期望状态保持一致。理解声明式配置、期望状态、Git 仓库角色以及 Pull/Push 模式的差异，是掌握 GitOps 回滚与审计机制的前提。
2.1 声明式配置与期望状态
在传统运维中，我们通常使用命令式操作：手动执行 kubectl run、kubectl scale 等指令，直接告诉系统“做什么”。这种方式依赖操作者的经验，难以追溯变更历史，且容易因人为失误导致配置漂移。
GitOps 采用声明式配置：你只需在 Git 仓库中定义应用的期望状态（Desired State），例如 Deployment 的副本数、镜像版本、Service 端口等。GitOps Operator 会自动将集群的实际状态向期望状态收敛。
- 命令式：“将副本数扩展到 5 个”（操作指令，无持久化记录）。
- 声明式：“Deployment 的 replicas: 5”（期望状态，存储在 Git 中）。
声明式配置的优势在于：
- 可审计：每次变更都对应一次 Git Commit，形成完整的变更时间线。
- 可回滚：只需将 Git 仓库回退到上一个 Commit，Operator 会自动将集群状态还原。
- 可复现：任何环境（开发、测试、生产）都可以从同一个 Git 仓库重建出完全一致的集群状态。
2.2 Git 作为单一事实来源
在 GitOps 体系中，Git 仓库不再仅仅是代码托管平台，而是整个集群配置的权威数据源。所有对集群的变更——无论是应用部署、配置更新还是基础设施调整——都必须先提交到 Git 仓库，再由自动化流程同步到集群。
Git 仓库中通常包含以下内容：
| 配置类型 | 示例文件 | 说明 |
|---|---|---|
| 应用部署清单 | deployment.yaml |
定义 Pod 模板、副本数、资源限制等 |
| 服务与网络配置 | service.yaml, ingress.yaml |
定义服务暴露方式与流量路由规则 |
| 配置与密钥 | configmap.yaml, secret.yaml |
应用配置与敏感信息（Secret 建议加密存储） |
| 基础设施定义 | namespace.yaml, rbac.yaml |
集群级别的资源定义 |
| Kustomize / Helm 模板 | kustomization.yaml, Chart.yaml |
用于参数化与多环境管理 |
main 分支对应生产环境，dev 分支对应开发环境。所有变更必须通过 Pull Request 合并，并触发 CI 流水线进行合规检查与预演。
Git 作为单一事实来源的核心价值在于：
- 一致性：无论集群发生何种漂移，Operator 都会以 Git 中的配置为准进行修复。
- 可追溯：每一次变更都关联到具体的 Commit、作者、时间戳和变更说明。
- 安全：通过 Git 的权限控制（分支保护、签名验证）和审计日志，确保只有授权变更才能生效。
2.3 Pull vs Push 模式对比
GitOps 的实现模式主要分为两种：Push 模式和Pull 模式。两者的核心区别在于谁主动触发同步操作。
2.3.1 Push 模式（传统 CI/CD）
在 Push 模式中，CI/CD 工具（如 Jenkins、GitLab CI）在检测到 Git 仓库变更后，主动将配置推送到目标集群。这种模式是传统持续部署的常见做法。
- 优点：部署流程直观，易于与现有 CI 流水线集成。
- 缺点：CI/CD 工具需要持有集群的访问凭证，存在安全风险；集群状态变更不经过 Git 仓库，容易产生配置漂移；回滚时需要手动触发新的流水线。
2.3.2 Pull 模式（GitOps 标准模式）
在 Pull 模式中，集群内部运行一个Operator（如 Argo CD、Flux），它会定期从 Git 仓库拉取配置并与集群当前状态进行比较。如果发现差异，Operator 会自动将集群状态调整到 Git 中定义的期望状态。
- 优点：集群无需对外暴露 API Server 凭证；变更必须经过 Git 仓库，天然防止配置漂移；回滚只需在 Git 中 revert Commit，Operator 自动执行。
- 缺点：需要额外部署和维护 Operator；同步存在一定延迟（通常为 1-3 分钟）。
以下表格总结了两种模式的关键差异：
| 对比维度 | Push 模式（传统 CI/CD） | Pull 模式（GitOps 标准） |
|---|---|---|
| 触发方式 | CI/CD 工具主动推送 | 集群内 Operator 主动拉取 |
| 凭证管理 | CI/CD 工具持有集群凭证 | 集群内 Operator 持有 Git 只读凭证 |
| 配置漂移防护 | 弱（手动操作可绕过 Git） | 强（Operator 持续修复漂移） |
| 回滚操作 | 手动触发新流水线 | Git revert → 自动同步 |
| 审计留痕 | 依赖 CI/CD 日志 | Git Commit 即为审计记录 |
| 网络要求 | CI/CD 需访问集群 API | 集群需访问 Git 仓库 |
2.4 GitOps 协调循环示意图
下图展示了 Pull 模式下 GitOps 的核心协调循环：Operator 持续对比 Git 仓库中的期望状态与集群的实际状态，并自动修复漂移。
2.5 Push 与 Pull 模式架构对比图
为了更直观地理解两种模式的架构差异，下图展示了 Push 模式（左）与 Pull 模式（右）的组件关系与数据流向。
2.6 本章小结
- 声明式配置是 GitOps 的基石，它将运维从“操作指令”转变为“状态定义”，使得配置可审计、可回滚、可复现。
- Git 作为单一事实来源，确保所有集群变更都有据可查，任何漂移都能被自动修复。
- Pull 模式是 GitOps 的标准实现方式，相比 Push 模式具有更高的安全性和更强的漂移防护能力。
- 在后续章节中，我们将基于 Pull 模式深入探讨如何实现配置变更的回滚验证与审计留痕。