3、Argo CD 项目架构概览：核心组件与项目级配置模型

在深入 Secrets 轮换策略之前，必须理解 Argo CD 的架构骨架。Argo CD 遵循 声明式 GitOps 模式，由三个核心控制组件和一套项目级配置模型构成。本章将拆解这些组件如何协作，以及项目模型如何为 Secrets 轮换提供隔离边界。

3.1 三大核心组件

Argo CD 的控制平面由 API Server、Repo Server 和 Application Controller 组成。它们各自承担不同职责，并通过 gRPC/REST 通信。

3.2 组件协作流程

下图展示了 Argo CD 核心组件如何协作完成一次标准的同步循环，其中包含了 Secrets 轮换场景下的数据流。

3.3 项目级配置模型

Argo CD 的 Project（项目） 是资源隔离和策略控制的核心单元。每个 Application 必须属于一个 Project。项目模型为 Secrets 轮换提供了以下关键约束：

• 源仓库限制： 指定允许哪些 Git 仓库作为 Secrets 的来源。
• 目标集群限制： 限定 Secrets 可以被部署到哪些集群或命名空间。
• 资源白名单/黑名单： 控制 Project 内允许创建或修改的 Kubernetes 资源类型（如只允许 Secret 和 ConfigMap）。
• 同步策略： 定义自动同步、自愈、修剪等行为，影响轮换后 Secrets 的生效速度。

3.4 项目 CRD 示例

以下是一个典型的 Argo CD Project 定义，展示了如何通过项目模型限制 Secrets 的源和目标：

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: secure-secrets-project
  namespace: argocd
spec:
  description: "Project for high-security Secrets rotation"
  # 允许的源仓库
  sourceRepos:
  - 'https://git.internal.company.com/team-a/secrets-repo.git'
  # 允许的目标集群和命名空间
  destinations:
  - namespace: prod-secure
    server: https://kubernetes.default.svc
  - namespace: staging-secure
    server: https://kubernetes.default.svc
  # 只允许操作 Secret 资源
  clusterResourceWhitelist:
  - group: ''
    kind: Secret
  # 禁止手动同步，强制 Git 驱动
  syncWindows:
  - kind: deny
    schedule: '* * * * *'
    duration: 1m
    applications:
    - '*'
    manualSync: true
  # 角色绑定
  roles:
  - name: rotation-admin
    description: "Can trigger sync for Secrets rotation"
    policies:
    - p, proj:secure-secrets-project:rotation-admin, applications, sync, secure-secrets-project/*, allow
    groups:
    - team-a-rotation

3.5 项目模型与 Secrets 轮换的映射关系

下表总结了项目配置项如何直接服务于 Secrets 轮换策略：