第二篇：安装 Argo CD + 第一次部署应用

上一篇我把 GitOps 讲得头头是道，但讲道理归讲道理，东西得跑起来才算数。这篇就动手：把 Argo CD 装进集群，部署第一个应用，然后亲手搞个"破坏"，看它怎么把集群拉回该有的样子。

一、环境准备

先说清楚我的环境，你照着搭也差不多：

WSL2 里的 Ubuntu，装好了 Docker
minikube，用 docker 驱动拉起一个单节点集群
kubectl 配置好了，能连上集群

bash 复制代码

minikube start --driver=docker
kubectl get nodes   # 看到 READY 就说明集群活了

还要准备一个 Git 仓库。这里我不急着自己建，先用 Argo CD 官方给的示例仓库 argoproj/argocd-example-apps，里面躺着几个现成的应用，正好拿来试水。

二、安装 Argo CD：不是装一个软件，是装一整套控制器

安装其实就两条命令：

bash 复制代码

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

第一行先开一个独立的命名空间，第二行把官方打包好的清单整个 apply 进去。

第一次跑完我盯着终端愣了几秒：就这？apply 完就完事了？然后 kubectl get pods -n argocd 一看，一堆 Pod 正在创建。这里要留意，install.yaml 不是装了一个软件，是往集群里塞了一整套控制器和相关服务。等 Pod 全变 Running 之后，你会看到大概这么几样：

argocd-server：上一篇说的"前台"，Web UI 和 API 的大门
argocd-application-controller："监工"，盯着 Git 和集群之间的差异
argocd-repo-server："图纸翻译官"，把仓库内容渲染成 manifest
argocd-redis：给上面几个当缓存的，算后勤
可能还有 argocd-applicationset-controller、argocd-notifications-controller 之类，版本不同会有点出入

我一开始还纳闷：文档里说三个核心组件，怎么 Pod 这么多？后来想明白了------那三个是核心分工，不代表只有三个 Pod。每个组件拆开跑，各管一摊。

三、把大门打开：port-forward + 拿初始密码

Argo CD 现在装好了，但外面还访问不到。它的 server 服务默认是 ClusterIP，只在集群内部通。最简单的打开方式是端口转发：

bash 复制代码

kubectl port-forward svc/argocd-server -n argocd 8080:443

这条命令把集群里的 443 端口映射到本机的 8080，然后浏览器打开 https://localhost:8080 就能看到登录页（证书是自签的，浏览器会警告，点"继续前往"就行）。

账号密码呢？初始账号是 admin，密码是 Argo CD 自动生成后放在一个叫 argocd-initial-admin-secret 的 Secret 里的。取出来要两步：

bash 复制代码

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}"

输出是一串像乱码的东西，那是 base64 编码。我第一次直接把这串密文往登录框里粘，提示密码错误，愣了好一会才反应过来：得先解码：

bash 复制代码

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

这个解码出来的才是真密码。

后面我要用命令行操作，顺手装个 argocd CLI：

bash 复制代码

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64
argocd version

Windows 也有对应的 argocd-windows-amd64.exe，不过我在 WSL2 里就直接用 Linux 版了。

四、部署第一个应用：guestbook

装好 CLI，先在命令行登录一次，让 CLI 记住连的是这个 Argo CD：

bash 复制代码

argocd login localhost:8080 --username admin --password <密码> --insecure

后面跟 --insecure 是因为它是自签证书，不做证书校验。

然后创建第一个应用，用官方示例仓库里的 guestbook：

bash 复制代码

argocd app create guestbook \
  --repo https://github.com/argoproj/argocd-example-apps.git \
  --path guestbook \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default

这条 argocd app create 的每一个参数，其实就是在填写上一篇说过的那个 Application 对象------一张写着"从哪来、到哪去"的清单：

--repo：从哪个 Git 仓库来
--path：仓库里的哪个目录（guestbook）
--dest-server：部署到哪个集群（https://kubernetes.default.svc 指的就是当前这个集群）
--dest-namespace：部署到哪个命名空间（default）

这里有个我后来才意识到的机制：Application 本身也是一个 Kubernetes 资源（CRD） ，argocd app create 只是在帮你往集群里写入这个对象。你可以直接 kubectl get application guestbook -o yaml 把它打出来看------本质上和你 apply 一个 deployment.yaml 没有区别，只是这个对象的"控制器"正好是 Argo CD 自己。

创建完先别急着高兴，现在它还处于 OutOfSync 状态------Git 里的期望状态还没同步到集群里。手动触发一次同步：

bash 复制代码

argocd app sync guestbook

再查一下状态：

bash 复制代码

argocd app get guestbook

等一会，Sync Status 会从 OutOfSync 变成 Synced，Health Status 变成 Healthy，说明 guestbook 已经按 Git 仓库里描述的样子跑起来了。

五、核心实验：手动改集群，看它被拉回来

应用跑起来了，现在来干一件"坏"事------这正是上一篇讲的自动恢复原则的现场版。

直接绕过 Git，手工把副本数改了：

bash 复制代码

kubectl scale deployment guestbook --replicas=5

这时候 Argo CD 会怎么反应？等一小会再看：

bash 复制代码

argocd app get guestbook

你会发现 Sync Status 又变回 OutOfSync 了。原因就是上一篇说的：Git 仓库里定义的期望状态是 3 个副本，集群里现在实际是 5 个，期望和实际对不上了，这就是 drift（漂移）。

现在执行同步：

bash 复制代码

argocd app sync guestbook

再看副本数，它又变回 3 个了------集群被拉回了 Git 描述的样子。这个"手动改 → 检测到偏离 → 拉回来"的闭环，就是 GitOps 最核心的那套动作。

不过上面这步还是我手动敲的 sync。如果连这步都想省，可以把 app 的同步策略改成自动 + 自愈：

bash 复制代码

argocd app set guestbook --sync-policy automated --self-heal

设置完再手动改一次副本数：

bash 复制代码

kubectl scale deployment guestbook --replicas=5

这次你什么都不用干，过一会儿它自己就把副本数改回 3 了。看着这个"你改了，它自己改回来"的过程，我脑子里那个"监工盯着图纸"的比喻一下子有了实感。

六、Sync 策略：什么时候自动，什么时候手动

上一步踩到了 Sync 策略，这里单独说清楚，它是 Argo CD 最常用的几个开关：

手动同步 （默认）：Git 有变化不会自动部署，要你点 SYNC 或执行 argocd app sync。适合生产环境------每一步都由人确认。
自动同步 （--sync-policy automated）：只要检测到 Git 有变化就自动同步，不等人。适合测试环境、自己玩。
self-heal （--self-heal）：自动同步只管"Git 有变化"这件事；self-heal 管的是"集群被人为改偏了"这件事，发现偏离就拉回来。两者可以分开配。
prune：同步时把"Git 里已经删掉"的资源也从集群里删掉。不配的话，Git 里删了资源它也不管，属于保守玩法。

还有一个关键点：Argo CD 默认是轮询 Git 仓库，大概 3 分钟一次。想更快，可以配 webhook，让 Git 仓库在 push 的时候主动喊它一声。所以如果你改了代码 push 上去，发现半天没动静，先别怀疑人生------可能就是还没到下一轮轮询。

七、小结 + 下一篇

这一篇干的事：

装好了 Argo CD（一整套控制器，不是单个软件）
打开了 UI，拿到初始密码
用官方示例仓库部署了第一个应用 guestbook
亲手做了"改坏 → 被拉回来"的实验，验证了自动恢复
搞清了手动/自动同步、self-heal、prune 这几个开关

还有一块没走完：上面用的是别人现成的仓库。真正要"改代码 → push → 自动部署"的完整闭环，得用自己的 Git 仓库。这个我放到第三篇，连同多环境、Helm 集成一起深入。

下一篇：深入理解 Argo CD 原理与生产实践。

------ 2026-08-24 · WSL2 + minikube 环境实操