1. Argo CD 架构概览：核心组件及其职责

Argo CD 采用微服务架构，由四个核心组件协同工作，实现 GitOps 声明式持续交付。理解每个组件的职责与交互方式，是进行变更风险评估、故障排查与性能调优的基础。

1.1 核心组件总览

下表列出了 Argo CD 的四个核心组件及其主要职责：

1.2 组件交互架构图

下图展示了四个核心组件之间的数据流与控制流关系：

1.3 组件职责详解

1.3.1 API Server

• 入口网关：所有外部交互（CLI、UI、API 调用、Webhook）的唯一入口。
• 认证与授权：集成 OIDC、LDAP、SAML、本地用户，执行 RBAC 策略。
• 应用状态聚合：从 Application Controller 拉取实时状态，从 Repo Server 获取期望清单，合并后返回给客户端。
• 操作代理：将同步、回滚、删除等操作转发给 Application Controller。

1.3.2 Repo Server

• 仓库管理：维护 Git 仓库的本地克隆，支持 SSH/HTTPS 认证。
• 清单生成：将 Helm Chart、Kustomize overlay、Jsonnet 或纯 YAML 目录渲染为 Kubernetes 原生清单。
• 缓存层：将生成的清单缓存到 Redis，避免重复克隆和渲染。
• 并发控制：每个仓库的生成操作由独立的 goroutine 处理，支持并行请求。

1.3.3 Application Controller

• 状态循环：每个 Application 对应一个控制循环，定期（默认 3 分钟）比较 Git 中的期望状态与集群中的实际状态。
• 同步执行：执行 kubectl apply、kubectl delete 等操作，支持 prune、自愈、hook。
• 健康评估：根据资源类型（Deployment、StatefulSet、Service 等）内置健康检查规则，判断应用是否健康。
• 事件驱动：监听 Webhook 通知，触发即时同步。

1.3.4 Redis

• 会话存储：保存 API Server 的用户登录会话和 JWT 令牌。
• 清单缓存：Repo Server 生成的渲染清单以键值对形式缓存，TTL 默认 24 小时。
• 状态缓存：Application Controller 将比较结果写入 Redis，供 API Server 查询。
• 通知队列：作为轻量级消息队列，传递 Webhook 事件和同步请求。

1.4 组件职责对比表

1.5 组件间通信协议

Argo CD 组件间使用 gRPC 进行高效通信，减少序列化开销：

• API Server ↔ Repo Server：通过 gRPC 调用 RepositoryService.GetManifests 获取渲染清单。
• API Server ↔ Application Controller：通过 gRPC 调用 ApplicationService.Watch 订阅状态变更。
• API Server ↔ Redis：标准 Redis 协议，用于会话和缓存读写。
• Application Controller ↔ K8s API：使用 client-go 库，通过 REST 或 protobuf 与 Kubernetes API Server 交互。