深色模式
GitOps 概念：Git 为唯一事实源
摘要：GitOps 的核心只有一句话——Git 里写的就是线上应该长什么样，任何偏差都会被自动纠正。本文讲清四条原则、Push 与 Pull 两种模式的差异，以及什么情况下不该上 GitOps。
适用环境
- 已有一个 Kubernetes 集群（minikube/kind 也可练习）
- 应用已容器化，镜像存于镜像仓库
- 团队已有 Git 评审流程（PR/MR）
操作步骤
1. 四条原则
text
1. 声明式：期望状态用声明式配置（YAML）描述，而不是脚本步骤
2. 版本化与不可变：期望状态存于 Git，有完整历史、可审计、可回滚
3. 自动拉取：Agent 持续比对并把现实拉回期望状态
4. 持续调和：偏差被发现后自动纠正，或至少报警1
2
3
4
2
3
4
2. Push 模式 vs Pull 模式
text
Push（传统 CI 部署）：
CI 跑完 → kubectl apply → 集群
问题：CI 持有集群高权限；凭据外泄风险大；变更后无法感知
Pull（GitOps）：
Git 变更 → 集群内 Agent 检测 → 自动拉取并应用
优点：凭据不出集群；Git 是唯一入口；漂移可自动纠正1
2
3
4
5
6
7
2
3
4
5
6
7
3. 落地前提检查
bash
docker images | head # 应用是否已容器化
ls k8s/ manifests/ 2>/dev/null # 配置是否已声明式1
2
2
GitOps 要求环境配置与镜像版本解耦：改镜像版本只改一个字段，而不是复制整份 YAML。
4. 仓库结构建议
text
方式 A（推荐）：源码仓库与配置仓库分离
app-repo/ 源码、Dockerfile、CI
config-repo/ manifests、Helm values、按环境分目录
方式 B：单仓库多目录
repo/ { src/, deploy/dev/, deploy/prod/ }1
2
3
4
5
6
2
3
4
5
6
分离的好处：配置仓库的提交历史就是发布历史，且 CI 不会因源码提交误触发部署。
5. 镜像版本怎么更新
yaml
spec:
template:
spec:
containers:
- name: app
image: harbor.example.internal/app/myapp:1.2.3 # 只改这一行1
2
3
4
5
6
2
3
4
5
6
CI 构建完新镜像后自动向配置仓库提 PR 改这个 tag，评审合并后 Agent 自动同步。
6. 常见误区
text
误区1 "GitOps = 装了 Argo CD"：它是流程约定，工具只是执行者
误区2 "所有东西都进 Git"：密钥不应明文入库，需 Sealed Secrets
误区3 "Git 合并了就立刻上线"：生产仍需审批门禁、灰度与回滚预案1
2
3
2
3
危险
把含明文密钥的 manifest 推到 Git 是最常见的 GitOps 事故。密钥必须使用加密方案或外部密钥管理系统注入。
验证
- [ ] 能用一句话说清「线上状态 = Git 中 main 分支的描述」
- [ ] 手动在集群里改副本数，能被自动纠正或报警
- [ ] 回滚操作等价于
git revert一次提交
常见坑
在集群里手动 kubectl edit
这是 GitOps 的头号敌人，会产生配置漂移。应急修改后必须回写 Git。
一个巨型仓库管所有环境
容易误改生产。至少按环境分目录/分支，并给生产路径设 CODEOWNERS 保护。
忽略了同步顺序依赖
有状态应用的某些变更需按序执行，纯自动同步可能顺序错乱，需用 sync-wave 控制。