1. GitOps 解决的不是“部署”，而是“持续一致性”
很多团队已经能自动部署，但仍然经常遇到三类痛点：
- 漂移：生产环境被临时改过（热修、手动 kubectl），但没人知道、也没记录。
- 不可追溯：出事时只能问“谁上了什么”，缺乏确定答案。
- 不可复制：新环境搭不出来，或者搭出来行为不一致。
GitOps 的一句话：让集群状态长期与 Git 中的期望状态一致，并且让“变更与恢复”都可审计。
2. 推 vs 拉：为什么 Pull-based 部署更适合规模化治理？
Push-based：CI/CD 系统拿着凭证，把资源直接推到集群。它的风险是：外部系统一旦被攻破，就等于拿到了集群钥匙。 Pull-based：集群里的控制器（Argo/Flux）拿着最小权限，定期从 Git 拉取配置，完成对比与收敛。
图 1：Push vs Pull。GitOps 的关键收益之一是把集群写权限从“外部流水线”收敛到“集群内控制器”，降低攻击面与爆炸半径。
3. Reconcile loop：GitOps 的发动机
GitOps 的运行像一个永不停歇的“收敛循环”：
- Source：从 Git/Helm repo/OCI 拉取配置源。
- Diff：把当前集群状态与期望状态对比（含漂移检测）。
- Apply：把差异应用到集群（可能分批、可能带策略）。
- Health：判断应用健康与同步状态，必要时暂停/告警/回滚。
图 2：Argo CD / Flux 的共同循环。无论工具形态差异多大，核心都是“收敛循环 + 漂移检测 + 健康判定”。
4. 漂移（Drift）与回滚：GitOps 的“自愈”与证据链
漂移通常来自三类行为：临时热修、紧急排障、手工变更。GitOps 不否认它会发生，而是把它变成可治理事件：
- Detect：发现 drift（Diff）。
- Decide：自动纠正还是暂停等待人工？（策略与权限）。
- Correct：收敛回期望状态（Apply）。
- Audit：记录谁批准了什么、何时发生、影响范围（Git + 控制器事件）。
重要：GitOps 的回滚不是“回滚脚本”，而是“回滚 Git 的期望状态”。因此你要在 Git 上建立与生产一致的审批与策略。
图 3：漂移治理闭环。GitOps 不怕漂移发生，怕的是漂移不可见、不可追溯、不可恢复。
5. 最小落地清单（从 0 到 1）
- 分仓/分路径：把“应用配置（manifests）”与“平台基础设施”边界分开。
- 环境分层：dev/staging/prod 通过目录或分支表达，审批规则不同。
- 最小权限：控制器按命名空间授权；prod 尽量少开 auto-sync。
- 漂移策略：先 detect + alert，再逐步引入自动纠正。
- 证据链：PR 审批 + 签名（可选）+ controller sync history。
你现在应该能回答：
1) 我们的期望状态在哪里？Git 是否是唯一真相源？
2) 集群写权限掌握在谁手里？能否收敛到集群内控制器并做到最小权限？
3) 漂移发生时，系统是自动纠正、自动暂停，还是只告警？证据链在哪里？
1) 我们的期望状态在哪里？Git 是否是唯一真相源？
2) 集群写权限掌握在谁手里？能否收敛到集群内控制器并做到最小权限？
3) 漂移发生时，系统是自动纠正、自动暂停，还是只告警？证据链在哪里？