GitOps 核心理念与优势

核心问题：什么是 GitOps？它和传统 CI/CD 有什么不同？为什么说"Git 是唯一真相来源"？

什么是 GitOps

GitOps 是一种以 Git 仓库为基础设施和应用配置唯一来源的运维范式，核心原则：

1. 声明式：用 YAML / HCL 描述期望状态，而不是写操作步骤
2. 版本化：所有配置提交到 Git，有完整历史记录
3. 自动同步：GitOps Agent 持续监测 Git 与集群差异，自动协调
4. 可观测：任何偏差（配置漂移）都能被检测和告警

GitOps vs 传统 CI/CD

GitOps 两种仓库策略

单仓库策略（Monorepo）

my-monorepo/
├── apps/
│   ├── api/                    # 应用代码
│   └── web/
└── deploy/                     # 部署配置（GitOps 部分）
├── base/                   # 公共配置（Kustomize base）
│   ├── api/
│   └── web/
└── overlays/               # 环境差异（Kustomize overlays）
├── dev/
├── staging/
└── production/

✅ 简单，代码和配置一起审查 ⚠️ 应用代码变更会触发配置 CI，反之亦然

双仓库策略（Recommended）

app-repo/                       # 应用代码仓库（开发者日常工作）
├── src/
├── Dockerfile
└── .github/workflows/
└── ci.yml                  # 构建镜像，更新 infra-repo 中的 image tag
infra-repo/                     # 基础设施配置仓库（GitOps 唯一真相）
├── apps/
│   ├── api/
│   │   ├── base/
│   │   └── overlays/
│   └── web/
└── clusters/
├── staging/
└── production/

✅ 职责分离，更安全 ✅ 代码 CI 和基础设施 GitOps 流程解耦

Kustomize：无模板的 YAML 覆盖

Kustomize 是 GitOps 中常配合使用的 YAML 管理工具（kubectl 内置支持）：

apps/api/
├── base/                          # 基础配置
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
├── dev/
│   ├── kustomization.yaml     # 引用 base + 覆盖差异
│   └── replica-patch.yaml
└── production/
├── kustomization.yaml
└── production-patch.yaml

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
commonLabels:
app: api

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
namespace: production
images:
- name: myorg/api
newTag: v1.3.0     # CI 自动更新这里的 tag
patches:
- path: production-patch.yaml

# overlays/production/production-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3          # 覆盖 base 中的 replicas

GitOps 工具对比

配置漂移检测与自动修复

ArgoCD 有三种同步策略：

下一节：ArgoCD 安装与 Application 配置