一、为什么需要 GitOps 持续部署
ArgoCD 是面向 Kubernetes 的持续部署工具，它把 GitOps 理念真正落进生产环境：以 Git 仓库作为集群状态的唯一事实源，ArgoCD 控制器持续比对「期望态」与「实际态」，一旦发现偏差就自动（或按需）把 Kubernetes 持续部署收敛回声明式清单定义的目标。相比传统的「人敲 kubectl apply」或在 CI 里写一堆 deploy 脚本，ArgoCD 让一次发布变成一次 Git 合并——可审计、可回滚、可一键复制到多个集群。本文带你从零装好 ArgoCD，并用声明式方式托管你的第一个应用。
在动手前，如果你还不熟悉 Kubernetes 的基本对象，建议先回顾 K8s 入门：Pod、Deployment、Service，因为 ArgoCD 本质是在帮你管理这些资源。
二、ArgoCD 核心概念：Application 与同步机制
理解 ArgoCD 只需抓住三个概念。Application 是最核心的 CRD，它定义了「从哪个 Git 仓库的哪个路径，把什么资源，部署到哪个集群的哪个命名空间」。Project 是 Application 的访问边界，用来限制某个团队能部署到哪些集群、哪些命名空间、允许哪些 Git 源。Sync（同步）则是把 Git 里的期望态应用到集群的动作，分为 Manual（手动点同步）和 Automated（自动同步 + 自愈）。
ArgoCD 默认采用 Pull 模式：控制器主动从 Git 拉取清单，而不是 CI 机器 Push 到集群。这意味着集群只需对 ArgoCD 开放权限，CI 系统再也不需要持有 kubeconfig，安全边界清晰很多。当集群实际状态偏离 Git（比如有人手动改了副本数），ArgoCD 会标记为 OutOfSync，开启 selfHeal 后会自动纠正回来。
举一个真实场景：周五晚上某位同事为了救火，直接 kubectl edit 把某个 Deployment 的镜像回退了一版，却忘了提 Git。周一早上 ArgoCD 控制台一片红——它清楚地告诉你哪个资源 drift 了、当前值和期望值差在哪。你点一下 Sync 就能让集群重新对齐，而不必去翻谁在什么时候改过什么。这种「配置漂移可见、一键对齐」的能力，是手工脚本永远给不了的。
三、三步部署 ArgoCD 控制面
ArgoCD 本身也是一组 Kubernetes 资源，几条命令就能装好。官方提供了打包好的 manifests，国内环境若拉取缓慢，可以把镜像替换为阿里云等镜像加速地址。
# 1. 创建专用命名空间
kubectl create namespace argocd
# 2. 应用官方安装清单（stable 标签即最新稳定版）
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 3. 等待所有 Pod 就绪
kubectl get pods -n argocd --watch
# 4. 获取初始 admin 密码（默认用户名 admin）
kubectl -n argocd get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d; echo
# 5. 本地端口转发，浏览器访问 UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
生产环境不要长期用 port-forward，应通过 Nginx 反向代理 为 ArgoCD Server 配置 HTTPS 与域名，再叠加 OIDC 登录或 SSO。把 UI 暴露出去后，研发可以自助查看应用健康度、发起回滚，而不再依赖运维代操作。
四、第一个 Application：声明式托管应用
装好控制面后，真正的「GitOps」从编写一个 Application 清单开始。下面这个例子把官方示例仓库里的 guestbook 应用声明式地托管到 default 命名空间，并开启了自动同步与自愈。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true # 删除 Git 中已移除的资源
selfHeal: true # 集群被手动改动时自动纠正
syncOptions:
- CreateNamespace=true
把这个 YAML 提交到 Git 后用 kubectl apply -f 创建，ArgoCD 立即可见这个应用。它每 3 秒比对一次 Git 与集群，发现 guestbook 的 Deployment、Service 不存在就自动创建；之后你只要改 Git 里的副本数或镜像 tag，ArgoCD 就会把变更同步到线上。这正是 GitOps「Git 即部署」的精髓。
五、镜像更新与自动同步
纯 GitOps 有一个现实痛点：镜像打了新 tag 后，还得手动改 Git 里的 image 字段。ArgoCD Image Updater 能补上这块：它监听镜像仓库，发现新版本后自动向 Git 提交更新，再由 ArgoCD 同步到集群，形成完全自动的发布链路。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
namespace: argocd
annotations:
# 声明需要追踪的镜像
argocd-image-updater.argoproj.io/image-list: myrepo/myapp:1.0.0
# 按语义化版本号自动升到最新稳定版
argocd-image-updater.argoproj.io/myapp.update-strategy: semver
# 更新后写入 Kustomize 的 images 字段
argocd-image-updater.argoproj.io/myapp.kustomize.image-tags: myrepo/myapp
如果你的清单用 Helm 管理，也可以把镜像版本抽成 values.yaml 里的变量，让 Image Updater 只更新 values 而不碰模板。配合 webhook，Git 推送或镜像推送都能秒级触发同步，不必等待默认的 3 分钟轮询。
六、多环境管理：App of Apps 模式
当应用变多，「一个一个写 Application」会失控。ArgoCD 推荐的 App of Apps 模式，是用一个「根 Application」去指向一个包含其他 Application 定义的 Git 目录，从而把所有环境（dev/test/prod）收敛到一处集中管理。
# apps-root.yaml：根 Application，指向存放子应用的目录
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: apps-root
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-repo.git
path: apps/
destination:
server: https://kubernetes.default.svc
namespace: argocd
# apps/guestbook.yaml、apps/api.yaml 等：各自是一个 Application
# 根 Application 同步时，会把这些子 Application 一并创建出来
这种分层结构让「新增一个环境」变成了「在 apps/ 下加一个文件」，非常适合用 Helm Chart 做环境差异化渲染。运维看板里也能一眼看清几十个应用的同步状态，比翻 CI 日志直观得多——日常巡检还可以配合 k9s 在终端快速核对。
七、ArgoCD vs Flux CD：怎么选
提到 GitOps，绕不开另一个主流工具 Flux CD（本站已有 Flux CD 实战 专文）。两者都能实现声明式持续部署，但设计取向不同，下表帮你快速决策。
| 维度 | ArgoCD | Flux CD |
|---|---|---|
| 架构 | 中心化，单一控制面管理多集群 | 去中心化，每集群独立控制器 |
| 可视化 | 自带功能完善的 Web UI 与 CLI | 无官方 UI，依赖 SaaS 或 kubectl |
| 上手成本 | 开箱即用，UI 引导强 | 更轻量，但需自己拼装生态 |
| 多租户 | AppProject 做权限边界，成熟 | 依赖 K8s RBAC，边界靠约定 |
| 适用场景 | 中大型团队、需要统一看板 | 极简栈、偏好纯 Git/CLI 流 |
一句话：想要「看得见、易管、多人协作」选 ArgoCD；想要「轻、纯、和现有 Git 工具链贴得紧」选 Flux CD。本站两篇都写了，可按团队现状各取所需。
八、生产落地清单与常见坑
把 ArgoCD 用进生产，光会装不够，下面这份清单能帮你避开大多数坑。尤其注意权限边界——不要让一个 Application 拥有跨命名空间的无限权力。另一个高频踩坑是「假 Healthy」：ArgoCD 默认只认 K8s 内置对象的就绪状态，如果你部署的是 Operator 或自定义 CRD，它只会看 CR 是否创建成功，而不会等底层工作负载真正就绪。务必为关键 CRD 配置自定义 health 探针，否则同步显示成功、业务却还没起来。
# 用 AppProject 限制团队 A 只能部署到 team-a 命名空间
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
sourceRepos:
- https://github.com/your-org/*
destinations:
- namespace: team-a
server: https://kubernetes.default.svc
clusterResourceWhitelist:
- group: '*'
kind: '*'
namespaceResourceWhitelist:
- group: '*'
kind: '*'
| 检查项 | 要点 |
|---|---|
| 密钥管理 | 用 SealedSecret / External Secrets，别把明文塞进 Git |
| 同步窗口 | 生产用 SyncWindows 锁定发布时间，避免高峰期自动变更 |
| RBAC | 按团队拆 AppProject，禁止全集群通配 |
| 健康检查 | 为自定义 CRD 配置 health 字段，避免误判 Healthy |
| 回滚策略 | 保留 Git 历史即回滚点，配合 ArgoCD Rollouts 做金丝雀 |
九、与现有 CI/CD 流水线衔接
最后澄清一个常见误区：ArgoCD 不是 CI 的替代品，而是 CD 层的补位。正确的分工是——GitHub Actions 这类 CI 负责构建镜像、跑测试、把产物推到镜像仓库；ArgoCD 负责把新镜像同步到集群。CI 跑完只需更新 Git 里的 image tag（或交给 Image Updater），剩下的交付完全交给 GitOps 闭环，职责清晰、故障面更小。
当你把第一条 Application 成功跑起来，就会体会到「发布=合并 PR」的爽感：每一次变更都有 Git 提交可追溯，每一次回滚都是一次 git revert。这也是 ArgoCD 在 Kubernetes 持续部署领域被大规模采用的根本原因。
