1. Argo CD 项目级架构概述
Argo CD 作为 Kubernetes 生态中最主流的声明式 GitOps 持续交付工具，其项目级架构设计直接决定了多团队、多环境、多应用场景下的安全边界与运维效率。本节从核心组件、项目与应用程序的关系、多租户架构基础三个维度展开，为后续准入策略评审奠定架构认知基础。
1.1 Argo CD 核心组件
Argo CD 遵循 Kubernetes 控制器模式，由以下核心组件构成，各组件通过 gRPC 和 REST API 协同工作：
| 组件 | 职责 | 部署形态 |
|---|---|---|
| API Server | 暴露 REST/gRPC 接口，处理 Web UI、CLI、CI/CD 系统请求；执行认证、授权、RBAC 校验 | Deployment（无状态） |
| Repository Server | 缓存 Git 仓库内容，生成 Kubernetes 清单（Manifest）；支持 Helm、Kustomize、Jsonnet 等模板引擎 | Deployment（无状态） |
| Application Controller | 持续对比 Git 中期望状态与集群中实际状态，触发同步、自愈、健康检查 | Deployment（有状态，需 leader election） |
| Redis | 缓存 Git 仓库元数据、应用状态、会话信息；降低 API Server 与 Repo Server 负载 | Deployment 或 StatefulSet |
| ApplicationSet Controller | 基于生成器（Generators）批量创建/管理 Application，支持多集群、多环境自动化 | Deployment（可选组件） |
| Notification Controller | 基于应用状态变化触发 Webhook、Slack、Email 等通知 | Deployment（可选组件） |
架构要点：API Server 是所有外部请求的唯一入口，Repository Server 负责清单渲染，Application Controller 负责状态调和。三者之间的权限隔离是项目级准入策略的第一道防线。
1.2 项目（Project）与应用程序（Application）的关系
在 Argo CD 中，Project 是资源隔离与策略控制的一级逻辑单元，Application 是具体的交付单元。二者构成一对多的包含关系：一个 Project 可以包含多个 Application，每个 Application 必须归属于且仅归属于一个 Project。
1.2.1 核心概念对比
| 维度 | Project（项目） | Application（应用） |
|---|---|---|
| 定位 | 租户/团队/环境的逻辑边界 | 单个 Kubernetes 工作负载的 GitOps 描述 |
| 作用域 | 跨集群、跨命名空间、跨应用 | 单个目标集群 + 单个目标命名空间 |
| 策略载体 | 准入规则、RBAC、同步策略、白名单 | 同步选项、健康检查、钩子（Hooks） |
| 资源配额 | 可限制来源仓库、目标集群、资源类型 | 继承 Project 配额，不可超越 |
| 生命周期 | 长期稳定，由平台管理员管理 | 随业务迭代频繁创建/更新/删除 |
1.2.2 典型 YAML 结构示例
# Project 定义
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-alpha
namespace: argocd
spec:
description: "Alpha 团队项目"
# 允许的来源仓库
sourceRepos:
- 'https://git.company.com/team-alpha/*'
# 允许的目标集群和目标命名空间
destinations:
- namespace: 'team-*'
server: 'https://kubernetes.default.svc'
# 允许部署的资源类型
clusterResourceWhitelist:
- group: 'apps'
kind: 'Deployment'
- group: 'apps'
kind: 'StatefulSet'
# 同步策略
syncWindows:
- kind: allow
schedule: '0 0 * * *'
duration: 8h
---
# Application 定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: team-alpha # 必须引用已存在的 Project
source:
repoURL: 'https://git.company.com/team-alpha/guestbook.git'
path: manifests
targetRevision: main
destination:
server: 'https://kubernetes.default.svc'
namespace: team-frontend
syncPolicy:
automated:
prune: true
selfHeal: true
关键约束：Application 的
spec.project 字段一旦创建，默认不可修改（除非启用 --allow-project-update 标志）。Project 的准入策略变更会立即影响其下所有 Application 的同步行为，因此策略评审必须在 Project 层面严格把关。
1.3 多租户架构基础
Argo CD 的多租户能力建立在 Project 隔离 + RBAC 授权 + 资源配额三层模型之上。企业级部署通常采用以下架构模式：
1.3.1 三层租户隔离模型
| 层级 | 隔离粒度 | 实现方式 | 典型场景 |
|---|---|---|---|
| L1：集群级 | 物理/虚拟集群 | Argo CD 管理多个集群，每个集群对应独立环境 | 开发/测试/生产环境隔离 |
| L2：项目级 | Project 逻辑边界 | 每个团队/产品线一个 Project，配置独立准入策略 | 多团队共享同一集群 |
| L3：应用级 | Application + Namespace | 每个微服务一个 Application，部署到独立 Namespace | 服务级权限与资源管控 |
1.3.2 RBAC 与 Project 的绑定关系
Argo CD 的 RBAC 策略通过 argocd-rbac-cm ConfigMap 定义，支持将用户/组绑定到特定 Project 的操作权限：
# argocd-rbac-cm 示例
data:
policy.default: role:readonly
policy.csv: |
# 管理员拥有所有 Project 的管理权限
p, admin, projects, *, *, allow
# team-alpha 的成员只能操作 team-alpha 项目
p, role:team-alpha-admin, projects, get, team-alpha, allow
p, role:team-alpha-admin, projects, update, team-alpha, allow
p, role:team-alpha-admin, applications, *, team-alpha/*, allow
g, alice, role:team-alpha-admin
g, bob, role:team-alpha-admin1.4 架构设计对准入策略的影响
核心结论：Project 是 Argo CD 准入策略的锚点。所有准入规则——包括来源仓库白名单、目标集群/命名空间约束、允许的资源类型、同步窗口、以及自定义准入 Webhook——都在 Project 的 spec 中定义。Application 只能在其所属 Project 的策略边界内运作。
在后续章节中，我们将深入剖析以下准入策略评审要点：
- 来源仓库策略：如何通过
sourceRepos限制 Git 仓库范围，防止未授权代码注入 - 目标集群策略：通过
destinations控制 Application 可部署的目标集群与命名空间 - 资源类型白名单：使用
clusterResourceWhitelist和namespaceResourceBlacklist精细管控 Kubernetes 资源 - 同步窗口策略：通过
syncWindows定义允许自动同步的时间窗口，避免生产窗口外变更 - 自定义准入 Webhook：结合 Argo CD 的 Pre-Sync / Post-Sync Hooks 或外部准入控制器实现扩展校验