4. Argo CD 架构与部署

Argo CD 是 Kubernetes 生态中最主流的声明式 GitOps 工具。理解其组件架构与高可用部署方式，是构建可靠回滚机制的基础。本章将深入剖析 Argo CD 的核心组件、安装方式及生产级高可用配置。

4.1 Argo CD 组件架构

Argo CD 遵循微服务架构设计，由多个独立组件协同工作，共同实现 Git 仓库与 Kubernetes 集群的状态同步。其核心组件包括：

组件名称 职责描述 关键特性
API Server 提供 REST/gRPC 接口，处理 Web UI、CLI 和 CI/CD 系统的请求 认证授权、RBAC、Webhook 入口
Repository Server 负责克隆、缓存 Git 仓库，生成 Kubernetes 清单（Manifest） 支持 Helm、Kustomize、Jsonnet 等工具链
Application Controller 持续监控 Application 对象，对比期望状态（Git）与实际状态（集群） 自动/手动同步、回滚、健康检查
Redis 缓存 Git 仓库数据、Application 状态，降低 API Server 与 Controller 的负载 支持高可用哨兵模式或集群模式
Dex / 内置 OIDC 提供 SSO 集成，支持 LDAP、GitHub、GitLab、Google 等身份提供商 可选组件，用于企业级认证
架构要点： API Server 是唯一对外暴露的组件，Repository Server 和 Application Controller 在集群内部通信。Redis 作为状态缓存层，对性能和高可用至关重要。

下图展示了 Argo CD 各组件的交互关系与数据流向：

Argo CD 组件架构与数据流 用户 / CI 系统 API Server Repository Server Application Controller Redis 缓存 Git 仓库 Kubernetes 集群 说明 虚线表示 Redis 缓存读取 实线表示主要数据流

4.2 安装方式：Helm vs Kustomize

Argo CD 官方推荐两种安装方式：Helm Chart 和 Kustomize 覆盖。两者各有优劣，适用于不同场景。

对比维度 Helm Chart Kustomize 覆盖
配置复杂度 通过 values.yaml 集中管理，参数化程度高 通过 overlay 分层覆盖，适合多环境差异化
版本管理 Chart 版本与 App 版本分离，升级回滚方便 依赖 Git 分支或目录结构管理版本
社区生态 官方维护，更新及时，文档丰富 官方提供示例，但需自行维护 overlay
适用场景 标准化部署、CI/CD 集成、快速上手 已有 Kustomize 体系、多环境定制需求强

4.2.1 使用 Helm 安装 Argo CD

Helm 安装是最推荐的方式，尤其适合生产环境。以下为关键步骤：

  1. 添加 Helm 仓库
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
  1. 创建自定义 values 文件（argocd-values.yaml）
# argocd-values.yaml 示例
global:
  domain: argocd.example.com

configs:
  params:
    server.insecure: true

server:
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - argocd.example.com

controller:
  replicas: 2
  resources:
    requests:
      cpu: 500m
      memory: 512Mi

redis:
  enabled: true
  architecture: replication
  auth:
    enabled: false
  1. 执行安装
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  -f argocd-values.yaml
最佳实践： 将 values.yaml 文件纳入 Git 仓库管理，实现 Argo CD 自身的 GitOps 化部署。

4.2.2 使用 Kustomize 安装 Argo CD

对于已采用 Kustomize 管理基础设施的团队，可以直接使用官方提供的 base 和 overlay 结构：

# 目录结构示例
argocd-install/
├── base/
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   ├── argocd-cm.yaml
│   └── argocd-rbac-cm.yaml
└── overlays/
    ├── production/
    │   ├── kustomization.yaml
    │   ├── replica-count.yaml
    │   └── ingress.yaml
    └── staging/
        ├── kustomization.yaml
        └── ingress.yaml
# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: argocd

resources:
  - ../../base
  - ingress.yaml

patches:
  - path: replica-count.yaml
    target:
      kind: Deployment
      name: argocd-application-controller

replicas:
  - name: argocd-server
    count: 2
  - name: argocd-repo-server
    count: 2

4.3 高可用部署配置

生产环境必须保证 Argo CD 自身的高可用性，避免单点故障导致 GitOps 流程中断。以下为关键配置项：

组件 高可用策略 推荐配置
API Server 多副本 + 负载均衡 replicas: 2~3，配合 Ingress/Service
Application Controller 多副本 + 分片（Sharding） replicas: 2~3，启用 --sharding.enabled
Repository Server 多副本 + 共享缓存 replicas: 2，挂载 PVC 或使用 Redis 缓存
Redis 哨兵模式或集群模式 architecture: replication，sentinel.enabled: true
Dex 多副本 + 共享存储 replicas: 2，使用 PostgreSQL 作为后端存储
注意： Application Controller 的分片功能需要显式启用。未启用分片时，多副本中只有一个 Controller 实际工作，其余处于 Standby 状态，无法实现真正的负载分担。

以下为高可用部署的 Helm values 配置示例：

# argocd-ha-values.yaml
controller:
  replicas: 3
  sharding:
    enabled: true
    replicas: 3
  resources:
    requests:
      cpu: 1
      memory: 1Gi

server:
  replicas: 3
  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 6
    targetCPUUtilizationPercentage: 70

repoServer:
  replicas: 2
  resources:
    requests:
      cpu: 500m
      memory: 512Mi

redis:
  enabled: true
  architecture: replication
  sentinel:
    enabled: true
  master:
    persistence:
      size: 10Gi
  replica:
    replicaCount: 2

configs:
  params:
    server.insecure: true
    controller.status.processors: 20
    controller.operation.processors: 10

下图展示了高可用部署的组件拓扑：

Argo CD 高可用部署拓扑 Ingress / Load Balancer API Server #1 API Server #2 API Server #3 Controller #1 Controller #2 Controller #3 Repo Server #1 Repo Server #2 Redis 集群 Sentinel + 主从复制 持久化存储 10Gi 说明 所有组件均部署在 argocd 命名空间

4.4 部署验证与健康检查

部署完成后，执行以下命令验证组件状态：

# 检查 Pod 运行状态
kubectl get pods -n argocd

# 预期输出示例
NAME                                                READY   STATUS    RESTARTS   AGE
argocd-application-controller-0                     1/1     Running   0          5m
argocd-applicationset-controller-6b9f8c9d7f-2x4k9   1/1     Running   0          5m
argocd-dex-server-7c8d6f9b8c-5j6k7                  1/1     Running   0          5m
argocd-notifications-controller-5d4f6b7c8d-9j2k3    1/1     Running   0          5m
argocd-redis-0                                      1/1     Running   0          5m
argocd-repo-server-7b8c9d1e2f-3k4l5                 1/1     Running   0          5m
argocd-server-6c7d8e9f0a-1b2c3                      1/1     Running   0          5m

# 检查 Service 和 Endpoint
kubectl get svc -n argocd

# 获取初始管理员密码
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
验证要点： 确保所有组件 READY 状态为 1/1，且无 CrashLoopBackOff。对于高可用部署，检查各组件副本数是否与配置一致。

4.5 生产环境注意事项

  • 资源规划： 根据集群规模合理配置资源请求与限制。建议 Controller 和 API Server 至少分配 1 核 CPU 和 1Gi 内存。
  • 网络策略： 限制 Argo CD 组件间的网络访问，仅开放必要端口。API Server 对外暴露 443 端口，内部组件通过 ClusterIP 通信。
  • 持久化存储： Redis 和 Repository Server 建议使用持久卷（PVC），避免 Pod 重启导致缓存丢失。
  • 监控告警： 集成 Prometheus 监控 Argo CD 指标，关键告警项包括：同步失败、组件宕机、Redis 连接异常。
  • 备份策略： 定期备份 Argo CD 的 CRD 对象（Application、AppProject）和配置映射（argocd-cm、argocd-rbac-cm）。
核心结论： Argo CD 的高可用部署不是简单的多副本，而是需要结合分片、缓存、持久化、监控等多维度策略。只有组件自身稳定，才能为 GitOps 回滚提供可靠的基础设施保障。
← 上一章 📖 返回目录 下一章 →