上一篇【第77篇】Istio——服务网格的入门与实践给每个服务配个“私人保镖“下一篇【第79篇】Gateway API——Ingress的接班人摘要传统部署流程代码推上Git → CI打镜像 → 用脚本SSH到服务器kubectl apply。这条链路有几个毛病集群状态不透明谁知道现在跑的是哪个版本、不可审计没记录谁改了啥、容易漂移手动改了集群但Git没同步。GitOps换个根本思路把期望的集群状态存在Git仓库以Git为唯一真相源。ArgoCD是GitOps的事实标准实现——它持续对比Git里的期望状态和集群里的实际状态不一致就自动拉齐同步。这篇文章讲清GitOps原则、ArgoCD架构、自动/手动同步、多集群管理以及从Git Push到自动部署的完整链路。一、GitOps核心原则1.1 一切以Git为准【传统部署 vs GitOps】 传统: dev → push代码 → CI → 脚本 kubectl apply 到集群 ⚠️ 集群是终点状态散落各处不可追溯 GitOps: dev → push到Git(存期望状态) → ArgoCD → 同步到集群 ✅ Git是唯一真相源 ✅ 集群只是Git状态的投影 ✅ 任何变更都走Git(PR/MR)可审计、可回滚要点GitOps的精髓是**“声明期望状态在Git集群自动向Git靠拢”**。这和K8s的声明式哲学第062篇一脉相承——只不过把期望状态从etcd扩展到了Git。好处爆炸所有变更有Git历史谁、何时、改了啥、回滚就是git revert、集群状态永远可重建Git在就不怕集群崩。二、ArgoCD架构2.1 核心概念【ArgoCD 架构】 Git Repository (期望状态) ▲ │ ArgoCD 持续对比(difference) │ ┌─────────────────────────────────┐ │ ArgoCD (控制面, 跑在集群里) │ │ • API Server / UI │ │ • Application Controller │ │ - 对比Git和集群 │ │ - 发现drift(漂移)就同步 │ │ • Repository Server │ │ - 拉取Git/Helm仓库 │ └─────────────────────────────────┘ │ 执行 kubectl apply (通过K8s API) ▼ K8s Cluster (实际状态) —— 可多集群!2.2 Application 和 AppProject【ArgoCD 的两个核心CRD】 Application (应用): • 连接 一个Git路径 和 一个集群namespace • 定义: 去哪个Git仓库的哪个path、用哪种工具(helm/kustomize/plain) • 同步策略(自动/手动) 例: prod环境的web应用 gitexample/web.git//prod cluster-A AppProject (项目): • 对Application分组权限控制 • 限制: 这个project的App能部署到哪些集群/namespace • 多团队隔离用三、自动 vs 手动同步3.1 两种模式【同步模式】 Manual (手动): • ArgoCD检测到Git和集群不一致 → 标红OutOfSync • 人工点Sync按钮才生效 • 适合: 生产环境要审批的场景 Automatic (自动): • Git一变 → ArgoCD自动同步到集群 • 可设 prune(删除Git里没了但集群还有的资源) • 可设 selfHeal(集群被手动改了→自动改回Git状态) • 适合: 测试/预发或信任Git的自动化生产apiVersion:argoproj.io/v1alpha1kind:Applicationmetadata:name:web-prodnamespace:argocdspec:project:defaultsource:repoURL:https://github.com/me/web.gitpath:k8s/prod# Git里的manifest路径targetRevision:HEAD# 跟Git主线destination:server:https://kubernetes.default.svc# 目标集群namespace:prodsyncPolicy:automated:prune:true# Git删了→集群也删selfHeal:true# 集群被改→自动改回Git状态四、实战从Git Push到自动部署4.1 完整链路【一次GitOps部署的时间线】 1. 开发者改了 web 的 image 版本 git commit -m bump web to v1.2 git push origin main 2. ArgoCD 轮询Git(或Git webhook通知) → 发现 main 分支变了 3. ArgoCD 拉取最新 manifest → 对比集群当前状态 → 发现 image 版本不一致 → 标记 OutOfSync 4. (自动模式) ArgoCD 同步 → 调K8s API apply新manifest → Deployment滚动更新(第013篇) → Pod变成新版本 5. ArgoCD 再对比 → Synced ✅ (Git和集群一致) 整个过程开发者只碰了Git没碰集群!# 看ArgoCD状态(CLI或UI)argocd app get web-prod# NAME CLUSTER NAMESPACE STATUS HEALTH# web-prod in-cluster prod Synced Healthy# 回滚? 直接 git revert push, ArgoCD自动同步回去# 或: argocd app rollback web-prod 3要点GitOps的闭环是开发者只改Git集群自动追平。ArgoCD的selfHeal能抵御有人手动kubectl改了集群——它会把集群改回Git定义的状态保证集群永不漂移。回滚就是git revert比传统找旧yaml重apply优雅一万倍。多集群时一个ArgoCD能管多个集群的多个Application是多云部署的利器。五、GitOps vs 传统CI/CD维度传统CI/CDGitOps(ArgoCD)真相源CI脚本/流水线Git仓库部署触发CI主动push到集群ArgoCD拉取同步集群状态不透明/易漂移Git即状态,可比对回滚重跑旧流水线git revert审计靠CI日志靠Git历史多集群脚本逐个部署一个ArgoCD统一管理六、和CI的关系【GitOps 不取代CI只接管CD】 CI (如GitHub Actions/Jenkins): • 编译代码 → 跑测试 → 打镜像 → 推镜像仓库 • 改Git里的image tag CD (ArgoCD, GitOps): • 看Git里的manifest变了 → 同步到集群 分工: CI管构建出什么GitOps管部署成什么样本篇小结GitOps把Git作为集群唯一真相源——期望状态存GitArgoCD持续对比Git与集群、不一致就自动拉齐。核心是Application连接一个Git路径和一个集群namespace和AppProject分组权限。自动同步pruneselfHeal保证集群永不漂移、永不丢失Git定义的状态。开发者只需改Git回滚就是git revert多集群一个ArgoCD统一管。GitOps不取代CI——CI管构建出什么打镜像ArgoCD管部署成什么样同步manifest。下篇讲Gateway API——Ingress的接班人。上一篇【第77篇】Istio——服务网格的入门与实践给每个服务配个“私人保镖“下一篇【第79篇】Gateway API——Ingress的接班人