🏗️ 深入剖析Argo CD架构：探寻GitOps的核心

6 月 22, 2026

—

cslab

in IT Security

大家好！Argo CD 使得 Kubernetes 环境中的声明式持续交付（Declarative CD）成为可能。在“推送到 Git 即可部署”这一简单结果的背后，隐藏着一个精心设计的微服务架构。

今天，我们将深入探讨构成 Argo CD 的主要组件、它们之间的数据流，以及为什么会采用这种结构设计。🛠️

https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/

1. 🌐 Argo CD 架构概述 (High-level View)

Argo CD 是一个由三个主要服务组成的微服务架构。每个服务都扮演着独立的角色，并在集群内部进行有机通信。

核心组件

API Server: 用户和外部工具的网关
Repository Server (Repo Server): 源代码 (Git) 管理的中心
Application Controller: 监控集群状态的大脑

2. 🚦 API Server: 网关与安全

API Server 是用户（UI/CLI）或外部系统（CI 工具）与 Argo CD 交互的唯一接口。它作为 gRPC/REST 服务器实现。

认证与授权 (AuthN/AuthZ): 验证用户身份，并根据 argocd-rbac-cm 中定义的权限进行检查。
应用程序管理: 处理应用程序的创建、修改和删除请求。
RBAC 实施: 对特定项目 (AppProject) 执行访问控制。

💡 提示: 我们之前讨论过的 Scoped Token 也是由该 API Server 验证和处理的核心安全要素。

3. 📂 Repository Server: 真理之源 (Source of Truth)

Repository Server 维护内部缓存并管理 Git 仓库中的清单。

清单生成: 将 Git 中的 Helm、Kustomize 或原始 YAML 文件渲染成 Argo CD 可以理解的纯 Kubernetes 对象。
缓存引擎: 由于每次都从 Git 获取会很慢，因此在没有更改时，它会利用本地缓存来最大化性能。
Kustomize/Helm 支持: 这是通过 kustomize.path 设置等方式，使用特定二进制版本执行渲染操作的地方。

💻 (参考) Repo Server 自定义配置示例

请查看之前学过的 InitContainer 技术，通过该技术在 Repo Server 中预注册 Helm 仓库的配置的架构位置。

YAML

# argocd-repo-server 必须准备好与外部 Helm 仓库通信以进行渲染。
containers:
- name: argocd-repo-server
  env:
  - name: ARGOCD_REPO_SERVER_HELM_BIN
    value: "/usr/local/bin/kustomize-v5" # 使用自定义二进制文件时

4. 🧠 Application Controller: 状态的守护者

这个组件正是 Argo CD 的“大脑”和 GitOps 的核心引擎。

持续监控 (Continuous Monitoring): 不断比较当前运行的集群状态 (Live State) 与 Git 中定义的状态 (Desired State)。
健康评估 (Health Assessment): 这是我们之前在 argocd-cm 中定义的 resource.customizations.health Lua 脚本执行的地方。
自动修复 (Self-Healing): 当集群中有人手动更改设置时，执行将集群恢复到 Git 状态的操作。

5. 🔄 数据流：部署过程

让我们逐步了解用户点击 Sync 按钮时架构内部发生的事情。

用户请求: 用户通过 UI/CLI 向 API Server 发送 Sync 命令。
清单请求: API Server 向 Repo Server 请求“使用最新提交版本渲染清单”。
渲染: Repo Server 从 Git（或缓存）获取代码，并执行 Helm/Kustomize 以生成最终的 YAML。
比较与执行: Application Controller 比较接收到的 YAML (Desired) 与当前集群状态 (Live)，并将仅有的更改应用 (Apply) 到集群。
状态更新: 部署完成后，Controller 记录最终状态并在 UI 上显示 Synced 或 Healthy 徽章。

6. 🏗️ 高级架构：HA (高可用性) 配置

在生产环境中，每个组件都以高可用性模式运行，以防止服务中断。

Redis: 作为 Repo Server 缓存数据的外部存储，允许多个 Repo Server 共享状态。
分片 (Sharding): 如果管理数千个集群，Application Controller 会被拆分成多个实例（分片）以分散负载。

💻 Controller 分片配置示例 (argocd-cmd-params-cm)

YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
data:
  # 限制单个控制器负责的集群数量以实现分片。⚖️
  controller.replicas: "2"
  controller.cluster.sharding.algorithm: "round-robin"

📝 总结表格：架构组件比较


组件	主要职责	相关配置文件	比喻

—	—	—	—
API Server	认证、授权、API 提供	argocd-rbac-cm	问询台
Repo Server	清单渲染、缓存	argocd-cm (kustomize)	翻译与设计局
Controller	状态比较、同步、恢复	argocd-cm (health)	现场主管
Redis	数据缓存共享		共享记事本

—

💡 总结

Argo CD 的架构经过彻底分工，旨在弥合“定义状态的地方 (Git)”与“维护状态的地方 (Cluster)”之间的鸿沟。理解这种结构有助于在故障排除时明确应该查看哪个组件的日志。

如果无法登录？ → API Server
如果 Git 更改未反映？ → Repo Server
如果部署完成但持续处于 Progressing 状态？ → Application Controller

希望这能帮助您理解这些守护您集群的无形英雄们的结构！ 🎯