2. Argo CD 基础回顾：核心概念、架构组件与工作流程
在深入资源配额校准与性能调优之前，必须牢固掌握 Argo CD 的基础知识。本章将系统回顾 Argo CD 的三大核心概念（Application、Project、Repository）、三大架构组件（API Server、Repo Server、Application Controller）以及端到端的工作流程。这些内容是后续所有调优操作的基石。
2.1 核心概念
Argo CD 围绕三个核心抽象构建：Application（应用）、Project（项目）和 Repository（仓库）。理解它们之间的关系是使用 Argo CD 的第一步。
| 概念 | 定义 | 关键属性 |
|---|---|---|
| Application | 代表一个已部署或待部署的 Kubernetes 资源集合。它是 Argo CD 管理的原子单元。 | 源（Source）、目标（Destination）、同步策略（Sync Policy） |
| Project | 用于对 Application 进行逻辑分组和访问控制的容器。它定义了允许部署的目标集群、命名空间以及资源来源。 | 源仓库白名单、目标集群白名单、命名空间白名单、角色绑定 |
| Repository | 存储 Kubernetes 清单（Manifest）的 Git 仓库地址。Argo CD 通过监听仓库变化来驱动应用状态同步。 | Git URL、SSH/HTTPS 凭证、路径（Path）、分支（Branch） |
核心关系总结： 一个 Repository 可以包含多个 Application 的清单文件；每个 Application 必须属于且仅属于一个 Project；Project 通过白名单机制约束 Application 可以引用的 Repository 和目标集群。
2.1.1 Application 的声明式定义
一个典型的 Application 资源定义如下，它清晰地描述了“从哪来（Source）、到哪去（Destination）、怎么同步（Sync Policy）”：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
2.2 架构组件
Argo CD 采用微服务架构，由三个核心组件协同工作，确保 Git 仓库中的期望状态与集群中的实际状态保持一致。
2.1.2 组件职责详解
| 组件 | 核心职责 | 关键行为 |
|---|---|---|
| API Server | 暴露 REST API 和 Web UI，处理用户/CI/CD 系统的请求。管理 Application、Project 等 CRD 资源。 | 认证、授权、请求路由、事件分发 |
| Repo Server | 克隆 Git 仓库，生成 Kubernetes 清单（支持 Helm、Kustomize、Jsonnet 等）。维护本地缓存以提升性能。 | 仓库克隆、清单渲染、缓存管理、LFS 支持 |
| Application Controller | 持续监控 Application 的期望状态（来自 Repo Server）与实际状态（来自目标集群），并在检测到差异时触发同步操作。 | 状态比较、自动/手动同步、Prune、Self-Heal、健康状态评估 |
2.3 工作流程
Argo CD 遵循“GitOps 闭环”原则，其核心工作流程可以概括为以下五个步骤：
- 用户提交变更： 开发人员将 Kubernetes 清单文件的变更推送到 Git 仓库。
- Argo CD 检测变更： API Server 通过 Webhook 或轮询机制感知到仓库变更，并更新 Application 状态。
- Repo Server 生成清单： Repo Server 根据 Application 定义，从 Git 仓库拉取代码并渲染出最终的 Kubernetes 清单。
- Application Controller 比较状态： Controller 将 Repo Server 生成的期望清单与目标集群中的实际运行状态进行对比。
- 执行同步操作： 如果检测到差异（OutOfSync），Controller 根据同步策略（自动或手动）执行
kubectl apply等操作，使集群状态与 Git 仓库保持一致。