GitOps 是 DevOps 在云原生下的落地实现，核心是声明式配置、持续拉取与自动自愈；它通过 Argo CD 等工具持续比对 Git 与集群状态并修复偏差，而非依赖一次性 CI/CD 推送。
GitOps 不是 DevOps 的替代品，而是它在云原生场景下最落地的实现方式——用 git push 触发部署，靠 Argo CD 或 Flux 持续比对并修复偏差，不是“跑完流水线就完事”，而是“系统永远盯着 Git 里的 YAML，不对就拉回来”。
GitOps 的核心动作：声明 + 拉取 + 自愈
它不依赖你手动执行 kubectl apply，也不靠 CI 流水线“推”到集群。真正的 GitOps 工作流是：
- 你在 Git 仓库里修改
k8s/deployment.yaml，提交 PR → 合并到main - Argo CD 每 30 秒（默认）轮询一次 Git，发现新 commit → 下载 YAML → 计算差异
- 如果集群里
Deployment的副本数是 2，但 Git 写的是 3，它立刻执行同步（不是重放命令，是调用 Kubernetes API PATCH） - 哪怕有人绕过 Git 直接
kubectl scale把副本改成 1，5 分钟内也会被自动纠回成 3
这个“持续协调（Continuous Reconciliation）”机制，才是 GitOps 和传统 DevOps CD 最本质的区别：前者管“状态是否长期一致”，后者只管“这次部署有没有成功”。
DevOps 流水线为什么容易漂移？
典型 CI/CD（比如 Jenkins + Shell 脚本）常见问题：
-
CI构建镜像、打 tag、推送 registry；CD拿着新 tag 去kubectl set image—— 这个操作只发生一次，之后没人再校验 - 运维半夜紧急修复，直接
kubectl edit configmap，Git 里还是旧内容，下次发布就覆盖或冲突 - 不同环境（staging/prod）共用一套脚本，但参数靠环境变量传，
env=prod写错一个字母，配置就漏掉
这些都不是工具不行，而是流程设计没把“期望状态”固化下来。GitOps 强制你把所有环境的终态都写进 Git，连 namespace、ResourceQuota、NetworkPolicy 都得声明，否则集群就不认。
Argo CD vs Jenkins：谁该干哪部分？
别让 Argo CD 做 Jenkins 的事，也别让 Jenkins 做 Argo CD 的事：
- Jenkins / GitHub Actions 该做：
git clone→npm test→docker build→docker push→ 更新image: myapp:v1.2.3到 Git（注意：只改镜像 tag，不动其他 YAML） - Argo CD 该做：监听 Git 中
manifests/prod/目录，发现image字段变了 → 对比 prod 集群当前状态 → 计算 diff → 调用 API 更新 Deployment - 错误做法：
GitHub Actions里写kubectl apply -f k8s/—— 这属于“伪 GitOps”，只是用 Git 存配置，没启用自愈能力
真正启用 GitOps，必须关掉所有直连集群的部署权限，让运维人员只剩 Git 权限。否则，kubectl 就是后门，Git 就不是唯一真实源。
最容易被忽略的坎：分支策略和权限隔离
很多团队卡在“GitOps 跑不起来”，其实不是工具问题，是 Git 协作规则没对齐：
- 不要用
main分支直连生产集群。标准做法是：main对应 staging，prod分支受保护，只有合并 PR + 人工批准才能触发生产同步 - Argo CD 应用定义本身也要进 Git（即
argocd-app.yaml），不能用argocd app create手动注册 —— 否则应用元数据不在版本控制里 - 避免把所有环境 YAML 堆在一个 repo 里。推荐按环境拆 repo（
infra-prod、infra-staging），或用目录+路径过滤（Argo CD 支持path: manifests/prod）
GitOps 看似只是换了个工具，实则是把“人管状态”变成“代码管状态”。一旦接受这个前提，所有设计决策——从分支命名到 RBAC 策略——都得围绕“Git 是唯一入口”来重构。
