90DaysOfDevOps 实践：在 Minikube 上部署 ArgoCD 并以 GitOps 方式交付 Kubernetes 应用-平芜编程栈

文档/教程

【免费下载链接】90DaysOfDevOps

This repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.

项目地址：https://gitcode.com/gh_mirrors/90/90DaysOfDevOps

点击查看免费下载

导读

本篇文章对应 90DaysOfDevOps 2022 路线图的第 76 天（2022/Days/day76.md），是 CI/CD Pipelines 阶段的收官内容。文章以 ArgoCD 为核心，讲解如何在一个本地 Minikube 集群上完成 ArgoCD 的安装、初始管理员密码获取、Web UI 登录，并通过 Git 仓库把应用（Pac-Man）持续部署到 Kubernetes 中。读完本文，你将掌握 ArgoCD 的基本部署流程、声明式 GitOps 应用交付思路，以及在无负载均衡器的本地集群中处理 Service 状态的实用技巧。

为什么需要 ArgoCD：从“线上改一下”到“一切可回滚”

Argo CD 的官方定位是：“Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes”——一个面向 Kubernetes 的声明式 GitOps 持续交付工具。这句话的核心在于“declarative（声明式）”与“GitOps”两个关键词。

在传统运维中，我们常常会遇到两类问题：

直接在环境中临时修改，改完就忘了，因为系统一切正常（“lights are on and everything is green”），问题被掩盖；
或者修改导致故障，但可能不是自己改的、也可能故障没有被立刻发现，最终业务受损。

ArgoCD 给出的解决路径非常明确：

Application definitions, configurations, and environments should be declarative, and version controlled—— 应用定义、配置与环境都必须声明式，且纳入版本控制；
Application deployment and lifecycle management should be automated, auditable, and easy to understand—— 应用的部署与生命周期管理应当自动化、可审计、易理解。

从运维背景出发，在做完大量 Infrastructure as Code 工作之后，ArgoCD 正是把 IaC 的成果进一步延伸到持续部署 / 持续交付工作流中的下一步：Git 仓库成为集群环境的唯一事实来源（single source of truth），任何变更都可追溯、可回滚、可审计。

部署 ArgoCD：两条命令拉起整套控制器

ArgoCD 官方提供了现成的 manifests 安装包，本节的演示环境仍然是项目一贯使用的本地 Minikube Kubernetes 集群。部署只需要两步：

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

第一步创建独立的argocd命名空间，把 ArgoCD 的控制器、服务端与应用部署资源与业务应用隔离；第二步直接应用官方 stable 分支的 install.yaml，该文件一次性声明了 ArgoCD 运行所需的全部 Kubernetes 资源。从执行输出的资源清单可以看到，其中既包括自定义资源定义（CRD）、ServiceAccount、Role/RoleBinding、ConfigMap、Secret，也包括 Deployment、StatefulSet、Service 与 NetworkPolicy 等，这正是 ArgoCD 高可用的典型形态。

部署完成后，验证控制器是否全部就绪：

kubectl get pods -n argocd

从图中可以看到，argocd命名空间下的各个 Pod 均处于Running状态，就绪数全部为 1/1，且没有重启记录，说明核心组件（包括 argocd-server、argocd-repo-server、argocd-application-controller 等）已正常启动。

如果想一次性纵览该命名空间中所有资源类型，可以执行：

kubectl get all -n argocd

该命令会同时列出 Pod、Service、Deployment、ReplicaSet 和 StatefulSet 等资源，帮助你快速确认 ArgoCD 服务端、仓库服务端与应用控制器之间的网络端点是否都已就绪。

访问 Web UI：端口转发 + 初始管理员密码

集群内服务默认不对外暴露，本地体验最直接的方式是使用 kubectl 的端口转发。请在新的终端窗口中执行：

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

这里把argocd-server服务的 443 端口映射到本机 8080 端口。随后在浏览器中访问：

https://localhost:8080

ArgoCD 在安装时会自动生成一个初始管理员 Secret。登录用户名为admin，密码需要从集群中取回并解码，命令如下：

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

该命令利用jsonpath提取 Secret 中的password字段（base64 编码），再通过base64 -d解码为明文，&& echo用于换行输出。出于安全考虑，首次登录后建议立即在 UI 的 User Info 中修改密码并妥善保管。

登录成功后，你会进入 ArgoCD 的空白应用面板——此时集群中还没有任何由 ArgoCD 管理的应用。

页面上方的NEW APP与SYNC APPS按钮，分别用于创建新的 Application 与手动触发应用同步，这正是后续把应用接入 GitOps 流程的入口。

用 ArgoCD 部署应用：以 Pac-Man 为例

ArgoCD 的核心能力是从 Git 仓库（以及 Helm Chart 仓库）拉取应用定义，并将集群实际状态持续收敛到仓库声明的期望状态。本节选择的应用是 Pac-Man——经典吃豆人游戏，一个在数据管理类演示中被反复使用的示例应用。

官方推荐的做法是在 ArgoCD UI 中通过表单逐步完成配置：填写应用名称、选择来源仓库与路径、指定目标集群与命名空间，然后点击创建并同步。整个交互过程在演示视频中有完整呈现，这里不再用截图逐一重复。

需要注意的是，ArgoCD 管理的应用清单本质上就是 Kubernetes 原生资源声明。本仓库的 2022/Days/Kubernetes/pacman-stateful-demo.yaml 恰好提供了一份可对照的完整示例，可以让我们理解 Pac-Man 应用在集群内部的资源拓扑：

命名空间与安全：文件开头定义了pacman命名空间，并配套 PodSecurityPolicy、ClusterRole 与 RoleBinding，允许该命名空间内的 ServiceAccount 使用相应安全策略并读取 pods/nodes 信息；
MongoDB 有状态存储：StatefulSet 使用bitnami/mongodb:4.4.8镜像，数据落在 PVC（mongo-storage）上，并通过 Secret（mongodb-users-secret）注入MONGODB_ROOT_PASSWORD、MONGODB_DATABASE、MONGODB_USERNAME、MONGODB_PASSWORD等环境变量，同时配置了基于mongo ... --eval="quit()"的就绪探针；
Pac-Man 无状态应用：Deployment 使用quay.io/ifont/pacman-nodejs-app:latest镜像，监听 8080 端口，配置了 HTTP 类型的 liveness/readiness 探针，并通过环境变量与 Secret 引用把 MongoDB 的连接信息（主机mongo、认证用户/密码、数据库名、端口 27017、是否启用 SSL 等）注入容器；
服务暴露：mongo服务使用 ClusterIP（内部访问），而pacman服务则声明为LoadBalancer类型，将 80 端口转发到容器的 8080 端口。

这也正好解释了原文档中的一个重要提示：Minikube 默认没有配置负载均衡器，因此pacman的 LoadBalancer 类型 Service 会一直处于pending状态，表现为应用健康但服务“永远不被满足”。如果你想在本地完整体验游戏，可以把 Service 的 type 改为ClusterIP（见 pacman-stateful-demo.yaml 中的 Service 定义），再利用kubectl port-forward转发到游戏端口即可游玩。

此外，仓库中还提供了基于 Ingress 的暴露方式：2022/Days/Kubernetes/pacman-ingress.yaml 通过networking.k8s.io/v1的 Ingress 资源，将主机pacman.com的根路径/路由到pacman命名空间中名为pacman的 Service 的 80 端口，适合集群内已启用 Ingress Controller 的场景。

把 ArgoCD 放到 CI/CD 的上下文里看

第 76 天标志着本阶段 CI/CD Pipelines 内容的收官。正如文档所强调的，当前行业对 CI/CD 领域投入了大量关注，同时你会越来越多地听到GitOps这个术语——它本质上就是本文所述方法论在 CI/CD 大框架下的具体体现：以 Git 为唯一事实来源，用自动化同步替代人工变更。

在 90DaysOfDevOps 的 2022 路线图（见 2022.md）中，ArgoCD 的章节被明确列入 CI/CD 部分，紧接其后的下一站是Observability（可观测性）——Day 77 起开始讨论监控主题（2022/Days/day77.md）。这个安排并非巧合：当你用 GitOps 把部署做到自动化、可审计之后，下一步自然要回答“系统运行得怎么样”，也就是监控、日志与告警。可见这条学习路径在设计上是一脉相承的：先解决“如何可靠地把东西发布出去”，再解决“如何持续观察发布后的状态”。

小结

ArgoCD 是面向 Kubernetes 的声明式 GitOps 持续交付工具，强调“声明式 + 版本控制 + 自动化 + 可审计”；
本地 Minikube 部署只需kubectl create namespace argocd与kubectl apply两条命令，验证用kubectl get pods -n argocd与kubectl get all -n argocd；
通过kubectl port-forward svc/argocd-server -n argocd 8080:443暴露 UI，用初始 Secret 解码出的密码以admin登录；
应用交付从 Git 仓库声明出发，Pac-Man 示例可对照本仓库的 pacman-stateful-demo.yaml 理解其 MongoDB + Node.js 的资源拓扑；
本地无 LoadBalancer 时，可将 Pac-Man Service 改为 ClusterIP 并配合端口转发完成体验，或改用仓库中的 Ingress 方案暴露。