Argo CD 基础：安装、配置与核心概念

Argo CD 是 Kubernetes 生态中最主流的声明式 GitOps 持续交付工具。它通过将应用部署状态与 Git 仓库中的期望状态持续同步，实现了“Git 仓库即单一事实来源”的交付模式。本章将系统讲解 Argo CD 的安装配置、三大核心概念（Application、Project、Repo Server）以及 GitOps 工作流原理，为后续自动化回滚与故障自愈设计奠定基础。

2.1 Argo CD 的安装与配置

Argo CD 支持多种安装方式，包括 kubectl apply 原生 YAML、Helm Chart 以及 Operator。生产环境推荐使用 Helm Chart 以获得灵活的配置管理能力。以下为基于 Helm 的标准安装步骤：

  1. 添加 Helm 仓库：helm repo add argo-cd https://argoproj.github.io/argo-helm
  2. 创建命名空间：kubectl create namespace argocd
  3. 安装 Argo CD：helm install argocd argo-cd/argo-cd --namespace argocd
  4. 暴露 API Server：通过 LoadBalancer、Ingress 或 kubectl port-forward 访问 Web UI
  5. 获取初始密码：kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
生产建议：安装时务必启用 --set configs.params.server.insecure=true 并配合 Ingress TLS 终止，避免 Argo CD 自身证书管理带来的复杂性。同时建议开启 --set server.metrics.enabled=true 以暴露 Prometheus 指标。

安装完成后，核心组件清单如下：

组件名称 Pod 数量 功能职责
argocd-server 1~3 API 服务、Web UI、gRPC 端点、RBAC 控制
argocd-repo-server 1~2 克隆 Git 仓库、生成 Helm/Kustomize/Manifest 清单
argocd-application-controller 1~2 监控 Application 状态、执行同步/回滚操作
argocd-redis 1 缓存仓库元数据、Application 状态、Webhook 事件
argocd-dex-server 1 OIDC/OAuth2 身份认证（可选）

2.2 核心概念：Application、Project、Repo Server

Argo CD 的架构围绕三个核心抽象构建。理解它们之间的关系是掌握 GitOps 的关键。

2.2.1 Application（应用）

Application 是 Argo CD 中最基本的资源对象，它定义了“从哪个 Git 仓库的哪个路径”读取配置，以及“部署到哪个目标集群的哪个命名空间”。一个 Application 包含以下关键字段：

  • source：Git 仓库 URL、目标分支、路径、Helm values 文件路径
  • destination：目标集群 API Server URL（或 in-cluster）、目标命名空间
  • syncPolicy：自动同步策略（auto-sync）、自愈策略（self-heal）、prune 策略
  • syncStatus：当前同步状态（Synced / OutOfSync / Unknown）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-app-config.git
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2.2.2 Project（项目）

Project 是 Application 的逻辑分组和权限隔离单元。它定义了：

  • 允许的源仓库：限制 Application 只能引用白名单内的 Git 仓库
  • 允许的目标集群和命名空间：防止越权部署到非授权环境
  • 资源限制：可部署的 Kubernetes 资源类型白名单/黑名单
  • 角色绑定：通过 RBAC 控制不同团队对 Project 内 Application 的操作权限
最佳实践：每个业务线或环境（dev/staging/prod）使用独立的 Project。例如 project: payment-prod 只允许 payment 团队部署到 prod 集群的特定命名空间，且只能引用 payment 组织的 Git 仓库。

2.2.3 Repo Server（仓库服务器）

Repo Server 是 Argo CD 的“配置引擎”。它负责：

  1. 克隆 Git 仓库：根据 Application 的 source 配置拉取指定分支/标签
  2. 渲染清单：执行 helm template、kustomize build 或直接读取 YAML 目录
  3. 缓存：将生成的 Kubernetes 清单缓存到 Redis，避免重复克隆和渲染
  4. Webhook 处理：接收 Git 仓库的 push 事件，触发 Application 重新同步
Argo CD 核心概念关系图 Git 仓库 单一事实来源 Repo Server 克隆 + 渲染清单 Application 声明式部署单元 Project 权限隔离 + 资源约束 目标集群 Kubernetes API 拉取配置 注入清单 同步部署 约束/隔离 核心关系 Project 包含多个 Application Application 引用 Repo Server 输出

2.3 GitOps 工作流原理

GitOps 的核心思想是“声明式期望状态 + 持续协调循环”。Argo CD 作为协调引擎，其工作流包含以下关键步骤：

  1. 开发者推送代码：修改 Kubernetes 清单、Helm values 或 Kustomize overlay 并推送到 Git 仓库的指定分支
  2. Webhook 触发（可选）：Git 仓库通过 Webhook 通知 Argo CD 配置已变更；Argo CD 也可通过轮询（默认 3 分钟）检测变更
  3. Repo Server 拉取并渲染：Argo CD 的 Repo Server 克隆仓库、执行 helm template 或 kustomize build，生成最终的 Kubernetes 清单
  4. Application Controller 对比状态：将渲染后的期望清单与目标集群中当前运行的资源进行 diff 对比
  5. 自动/手动同步：如果启用了 auto-sync，Application Controller 自动执行 kubectl apply 将集群状态修正为期望状态；否则等待人工审批
  6. 持续自愈：如果集群中的资源被手动修改（配置漂移），Argo CD 会检测到 OutOfSync 并自动恢复为 Git 中的期望状态（需启用 selfHeal）
GitOps 工作流原理 开发者 git push Git 仓库 期望状态 Argo CD Repo Server 渲染 Controller 对比 自动/手动同步 K8s 集群 当前运行状态 kubectl apply 监控 & 告警 配置漂移检测 推送配置 Webhook/轮询 同步期望状态 漂移上报 触发自愈
关键注意事项：GitOps 工作流要求所有集群变更必须通过 Git 仓库驱动。直接使用 kubectl edit 或 kubectl patch 修改集群资源会导致 OutOfSync 状态。如果启用了 selfHeal，Argo CD 会自动覆盖这些手动变更，可能造成服务中断。生产环境建议对 selfHeal 的使用进行严格评审。

2.4 核心概念对比总结

概念 作用域 核心职责 典型配置项
Application 单个部署单元 定义源仓库、目标集群、同步策略 source.repoURL, destination.namespace, syncPolicy
Project 多 Application 逻辑组 权限隔离、仓库白名单、资源约束 sourceRepos, destinations, clusterResourceWhitelist
Repo Server 全局组件 Git 克隆、清单渲染、缓存 repositories, helm.repositories, kustomize.buildOptions
← 上一章 📖 返回目录 下一章 →