4. 项目与 Application 概念:Project 定义与作用、Application 资源模型、ApplicationSet 介绍、多租户隔离设计
4.1 Project 定义与作用
在 Argo CD 中,Project 是最高级别的逻辑隔离单元,用于对 Application 进行分组、授权和约束。每个 Application 必须属于且仅属于一个 Project。Project 的核心作用包括:
- 来源仓库白名单:限制 Application 只能从指定的 Git 仓库拉取清单。
- 目标集群白名单:限制 Application 只能部署到指定的 Kubernetes 集群和命名空间。
- 资源类型黑名单/白名单:控制 Project 内允许或禁止创建的 Kubernetes 资源类型(如禁止创建 ClusterRole)。
- 角色绑定与 RBAC:为不同团队或用户分配 Project 级别的操作权限(读、同步、管理)。
最佳实践:每个业务线或租户使用独立的 Project,并在 Project 级别配置仓库和集群白名单,实现最小权限原则。
4.2 Application 资源模型
Application 是 Argo CD 的核心自定义资源(CRD),它描述了一个部署单元的完整生命周期。一个典型的 Application 资源定义包含以下关键字段:
| 字段路径 | 说明 | 示例值 |
|---|---|---|
spec.source.repoURL |
Git 仓库地址 | https://github.com/example/helm-charts.git |
spec.source.path |
仓库内清单路径 | charts/nginx |
spec.source.targetRevision |
分支、标签或 commit | main |
spec.destination.server |
目标集群 API Server 地址 | https://kubernetes.default.svc |
spec.destination.namespace |
目标命名空间 | production |
spec.project |
所属 Project 名称 | my-project |
spec.syncPolicy |
自动同步策略配置 | automated: { prune: true, selfHeal: true } |
以下是一个完整的 Application YAML 示例:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: nginx-production
namespace: argocd
spec:
project: my-project
source:
repoURL: https://github.com/example/helm-charts.git
targetRevision: main
path: charts/nginx
helm:
values: |
replicaCount: 3
image:
tag: "1.25.0"
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
关键理解:Application 资源模型将“期望状态”(Git 仓库中的清单)与“实际状态”(Kubernetes 集群中的资源)关联起来,Argo CD 通过持续对比这两个状态来驱动同步。
4.3 ApplicationSet 介绍
ApplicationSet 是 Argo CD 的扩展 CRD,用于批量生成和管理多个 Application。它通过模板 + 生成器(Generators)的方式,从一组参数动态创建 Application,极大减少了重复配置。ApplicationSet 的核心价值在于:
- 多集群部署:基于集群列表生成器,将同一套配置部署到多个集群。
- Git 目录/文件驱动:根据 Git 仓库中的目录结构或文件内容自动生成 Application。
- GitHub/GitLab PR 生成器:为每个 Pull Request 自动创建临时环境 Application。
- 矩阵/合并生成器:组合多个生成器的输出,实现复杂的参数组合。
以下是一个使用集群生成器的 ApplicationSet 示例:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: multi-cluster-nginx
namespace: argocd
spec:
generators:
- clusters:
selector:
matchLabels:
environment: production
template:
metadata:
name: '{{name}}-nginx'
spec:
project: default
source:
repoURL: https://github.com/example/helm-charts.git
targetRevision: main
path: charts/nginx
helm:
values: |
replicaCount: 3
clusterName: '{{name}}'
destination:
server: '{{server}}'
namespace: nginx-system
syncPolicy:
automated:
prune: true
selfHeal: true
注意:ApplicationSet 的模板语法使用
{{ }} 占位符,这些占位符由生成器动态填充。确保生成器的输出字段与模板中的占位符名称完全匹配。
4.4 多租户隔离设计
在企业级服务目录中,多租户隔离是核心需求。Argo CD 通过以下层次实现租户隔离:
| 隔离层次 | 实现方式 | 适用场景 |
|---|---|---|
| Project 隔离 | 每个租户一个独立 Project,配置仓库/集群白名单 | 租户间完全隔离,禁止互相访问资源 |
| RBAC 隔离 | Argo CD 内置 RBAC,按 Project 绑定角色 | 控制租户用户对 Application 的读/写/同步权限 |
| 命名空间隔离 | 每个租户部署到独立的 Kubernetes 命名空间 | 运行时资源隔离,配合 NetworkPolicy 使用 |
| 集群隔离 | 不同租户使用不同的物理或虚拟集群 | 高安全要求场景,完全独立的控制平面 |
| ApplicationSet 租户模板 | 为每个租户生成独立的 ApplicationSet | 大规模多租户场景,自动化创建租户配置 |
以下是一个典型的多租户隔离架构 SVG 图,展示 Project、Application 和命名空间之间的关系:
4.5 多租户 RBAC 配置示例
在 Argo CD 的 argocd-rbac-cm ConfigMap 中,可以为不同 Project 配置细粒度权限:
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
namespace: argocd
data:
policy.default: role:readonly
policy.csv: |
# 租户 A 管理员
p, role:tenant-a-admin, projects, get, tenant-a, allow
p, role:tenant-a-admin, applications, *, tenant-a/*, allow
p, role:tenant-a-admin, clusters, get, *, allow
# 租户 A 开发者(仅同步权限)
p, role:tenant-a-dev, applications, sync, tenant-a/*, allow
p, role:tenant-a-dev, applications, get, tenant-a/*, allow
# 租户 B 管理员
p, role:tenant-b-admin, projects, get, tenant-b, allow
p, role:tenant-b-admin, applications, *, tenant-b/*, allow
# 用户绑定
g, alice@company.com, role:tenant-a-admin
g, bob@company.com, role:tenant-a-dev
g, charlie@company.com, role:tenant-b-admin
设计建议:在服务目录场景中,建议为每个租户创建独立的 Project,并通过 ApplicationSet 的集群生成器自动将 Application 分发到租户专属的命名空间。结合 RBAC 策略,可以实现“租户只能看到和操作自己的 Application”的完全隔离效果。