1. GitOps 基础概念
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制与自动化交付管道相结合，使基础设施和应用的变更全部通过 Git 提交来驱动，从而实现可审计、可回滚、可复现的持续部署。
核心思想：“Git 仓库中的声明式配置 = 生产环境的期望状态”。任何偏离期望状态的变化都会被自动检测并修正。
1.2 核心原则
GitOps 建立在三大支柱之上，三者缺一不可：
| 原则 | 说明 | 关键要求 |
|---|---|---|
| 声明式（Declarative） | 系统描述“要什么”，而非“怎么做”。YAML/JSON 描述期望状态，控制器负责调和。 | 幂等性、可重复、无副作用 |
| 版本控制（Version Control） | 所有配置、策略、环境差异都存储在 Git 中，每次变更产生唯一 Commit SHA。 | 可追溯、可回滚、可审计 |
| 自动化（Automation） | Git 事件触发自动调和循环，无需手动 SSH 或 kubectl 操作。 | Operator/Agent 持续对比期望与实际状态 |
1.3 与传统 CI/CD 的区别
传统 CI/CD 以“构建-测试-部署”管道为中心，GitOps 则以“声明式配置 + 自动调和”为核心。以下从多个维度对比：
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 配置模型 | 命令式脚本（Shell/Ansible Playbook） | 声明式 YAML/JSON（Kubernetes Manifest / Terraform） |
| 部署触发 | CI 管道执行完成后 Push 到环境 | Git 仓库变更触发 Operator 自动调和 |
| 状态管理 | 无持久状态，依赖管道日志 | Git 仓库作为单一事实来源 |
| 漂移检测 | 无内置机制，需额外监控 | 持续调和，自动检测并修正漂移 |
| 回滚方式 | 重新运行旧版本管道或手动修复 | git revert + 自动调和 |
| 审计能力 | 依赖 CI 平台日志，分散且易丢失 | Git Commit 天然提供完整审计链 |
| 典型工具 | Jenkins / GitLab CI / GitHub Actions | ArgoCD / Flux / Terraform Cloud |
关键差异总结：传统 CI/CD 是“推送（Push）模型”——管道将产物推送到环境；GitOps 是“拉取（Pull）模型”——集群中的 Agent 从 Git 拉取期望状态并自动调和。这一转变从根本上解决了配置漂移、手动干预和审计缺失等运维痛点。
1.4 GitOps 工作流示例
一个典型的 GitOps 部署流程包含以下步骤：
- 开发/运维人员修改 Git 仓库中的声明式配置文件（如 Deployment YAML）。
- Pull Request 提交后触发 CI 验证（语法检查、策略扫描、预演部署）。
- PR Merge 到主分支后，Git 仓库的期望状态发生变更。
- GitOps Operator（如 ArgoCD）检测到 Git 仓库与集群实际状态不一致。
- Operator 自动执行调和操作，将集群状态同步至 Git 仓库中的期望状态。
- 持续监控：Operator 保持后台运行，持续检测并修正任何手动或意外漂移。
# 示例：GitOps 声明式配置（Kubernetes Deployment）
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: app
image: registry.example.com/web-app:v1.2.3
ports:
- containerPort: 8080
常见误区：GitOps 不等于“用 Git 存 YAML”。真正的 GitOps 必须满足三个条件：声明式配置 + 版本控制 + 自动化调和。如果只是把 YAML 文件放到 Git 仓库，但依然手动 kubectl apply，那只是“Git + Ops”，不是 GitOps。