Argo CD 多团队共享集群怎么分？5 步搭好项目隔离的完整实践

Argo CD 多团队共享集群怎么分？5 步搭好项目隔离的完整实践

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd

Argo CD 是一套声明式持续部署（CD）工具，而它的「项目隔离」能力，正是给多团队协作、共享同一批 Kubernetes 集群的团队准备的。下面这套做法，帮你把"谁能动哪些应用、能往哪儿部署、能读哪个仓库"三件事一次说清。

从一块被挤爆的集群说起

先说个真实场景。你们公司只有一个生产集群，前端、后端、数据组都在里面跑。没做任何隔离之前，会发生什么？

• 数据组的新应用直接写进了前端团队正在用的命名空间，两边资源互相踩踏。
• 谁都能点「同步」按钮，误操作一次就把别人的版本打回去。
• 有人手滑把应用指向了不该碰的仓库或集群，等发现时已经上线。

这些问题的根子是：大家共用一个 Argo CD，却没有任何"边界"。Argo CD 的项目隔离解决的就是这件事——它把应用、仓库、集群、命名空间一起圈进一个个互不相干的单元，每个团队只在自己的单元里活动。你不用为每个团队再装一套 Argo CD，一套实例就能管多队。

隔离的心智模型：项目就是一堵墙

在动手之前，先在脑子里装一张概念地图，后面每一步都有地方落。

Argo CD 里，每个应用都归属且仅归属一个项目（Project）。项目就是一堵墙：墙内是这个团队能触达的一切资源，墙外谁都进不来。这堵墙不是靠某个功能点的，而是靠三样东西一起撑起来的。

• RBAC（访问控制）：管"人"。谁能看、能同步、能改哪些应用。这是墙上的门锁。
• 源仓库限制（sourceRepos）：管"从哪来"。应用只能从被批准的 Git 仓库取配置。
• 目标限制（destinations）：管"往哪去"。应用只能部署到被批准的集群和命名空间。

再加上一个可选的资源类型白/黑名单（能部署哪些 Kind），墙就完整了。记住这张"一堵墙 + 三道锁"的图，往下看你会发现，所谓配置项目，不过是把这三道锁一道道拧上。

第一步·划边界：如何创建项目并把应用圈进去

先建墙。项目在 Argo CD 里是一个叫AppProject的自定义资源（CRD），和 Application 一样，可以写进 YAML 走 GitOps 管理。

最快的方式是命令行：

argocd proj create team-alpha -s https://git.example.com/team-alpha/* -d https://kubernetes.default.svc,team-alpha-*

一条命令就定好了：项目叫team-alpha，只认team-alpha的仓库，只能往team-alpha开头的命名空间部署。建完之后，把应用挂进这个项目即可：

argocd app set my-service --project team-alpha

有一点要特别注意：系统会自动建一个default项目，而且它默认是全放行的（任何仓库、任何集群、任何资源类型都能过）。如果你不碰它，等于没设防。要么改严它，要么干脆把sourceRepos、destinations清空，强制所有应用都进你自己的项目。参考示例在 docs/operator-manual/project.yaml。

这一节你只需要确认一件事：你的应用现在归属哪个项目？圈对了，后面两把锁才有对象可锁。

第二步·发钥匙：如何用 RBAC 和角色控制谁能动哪些应用

墙立好了，现在发钥匙。Argo CD 的 RBAC 基于 Casbin 模型，核心就两种行，写在argocd-rbac-cm这个 ConfigMap 里：

• p, 主体, 资源, 动作, 对象, 效果—— 一条授权规则
• g, 主体, 角色—— 把用户或用户组绑到某个角色

举个贴合多团队的例子。让team-alpha的 OIDC 组只读本项目的全部应用，team-beta的某个 CI 角色只能同步单个应用：

# 组绑定到内置只读角色 g, my-org:team-alpha, role:readonly # 只读看本项目所有应用 p, role:readonly, applications, get, team-alpha/*, allow # CI 角色：只能同步某一个应用 p, proj:team-alpha:ci-role, applications, sync, team-alpha/my-service, allow

权限能细到哪一层？比你想的还细。applications这个资源下，对象可以写成项目/应用名，甚至精确到"只允许删这个应用里的 Pod、但不许删应用本身"这种颗粒度。两个内置角色直接能拿来用：role:readonly（全只读）和role:admin（全权限）。

这里有个多团队高频坑：给组授权前，必须先用g把组绑到角色上，否则单写p是失效的。完整规则表在 docs/operator-manual/rbac.md。

第三步·锁大门：如何限制源仓库、目标集群与命名空间

钥匙发得再准，也架不住有人拿自己的钥匙去撬墙。真正防越权部署的，是项目 spec 里的三道硬限制。它们在应用同步时强制执行，不依赖人的自觉。

源仓库，支持通配符和"取反"（!开头表示禁用）：

sourceRepos: - '!https://git.example.com/legacy/**' # 禁掉旧仓库 - 'https://git.example.com/team-alpha/*' # 其余只认本团队

目标集群与命名空间，同样的通配 + 取反逻辑：

destinations: - server: 'https://kubernetes.default.svc' namespace: 'team-alpha-*' # 只能落到本团队的命名空间

再往里一层，是资源类型限制。命名空间级资源用黑名单挡危险 Kind（比如NetworkPolicy、ResourceQuota），集群级资源用白名单只放行必要的：

clusterResourceWhitelist: - group: '' kind: Namespace name: 'team-alpha-*' # 只允许建本团队前缀的命名空间

规则是"只要有任一放行规则命中，且没有被取反规则拒绝，就算通过"。把这三段配置齐，一个应用就算被人硬改，也同步不到墙外——要么仓库不对、要么集群不对、要么命名空间不对，直接拦下。

进阶：团队规模变大后的协作技巧

基础隔离跑通后，规模一上来会遇到几类新需求，Argo CD 都有对应招数。

用标签筛选，让各团队只看各的。UI 支持按标签过滤应用列表，配合项目的sourceLabels字段，可以只展示打了对应标签的应用，团队之间互不干扰。

应用分层，基础设施与业务解耦。基础设施团队维护共享底座，业务团队通过 ApplicationSet 按模板批量生成应用，再挂到自己的项目里，依赖关系清清楚楚。

项目级同步策略，控制部署节奏。项目支持syncWindows，比如规定生产应用只能在每天 9 点到 18 点之间同步、夜间封禁default命名空间，把"发布窗口"这种团队约定直接变成系统强约束。

项目级仓库/集群，给开发者自助开洞。若担心"开发者加个仓库还得找管理员"，可以开放项目级仓库和集群：给项目管理员配上repositories的create/update权限后，开发者就能给自己项目加仓库，而无需改全局配置。

全局项目，把公共约束下放到所有项目。在argocd-cm里配globalProjects，可按标签让匹配的项目统一继承一份仓库/集群/同步窗口策略，公共底线一处维护、处处生效。

留痕兜底：如何证明隔离真的生效、出事能追溯

隔离不是配完就完，你得能证明它在工作。三条线可以交叉验证。

• 应用事件：每次同步、部署、状态变更都会产生事件，界面上可查，出问题第一时间能看到"谁、在什么时候、对哪个应用做了什么"。
• 访问日志：API Server 的日志记录所有 API 操作，是审计的直接依据，可接到你的日志系统集中留存。
• 指标监控：Prometheus 暴露了一批带project标签的指标，比如argocd_app_info（应用同步/健康状态）、argocd_app_sync_total（同步次数），可以直接按项目切片做告警和看板，哪个团队的应用在抖动、同步失败率多少，一屏看清。

建议把"按项目分维度"的同步失败率、OutOfSync 数量设成告警，隔离配置一旦被人放宽、某团队开始往墙外写，监控会先于人声给你报警。指标清单见 docs/operator-manual/metrics.md。

收尾：可直接照做的落地清单

按这个顺序走一遍，多团队的 Argo CD 隔离就立住了：

1. 拆项目：每个团队建一个AppProject，并把该团队的应用用argocd app set --project归位，别让应用赖在放行的default项目里。
2. 收默认项：把default项目的sourceRepos、destinations收紧或清空，堵住"默认全放行"的后门。
3. 发钥匙：在argocd-rbac-cm里用g把各团队 OIDC 组绑到角色，再用p精确到项目/*或项目/应用名，CI 角色单独给单应用同步权。
4. 锁大门：给每个项目配好sourceRepos、destinations和资源类型白/黑名单，把仓库、集群、命名空间三道口子都拧上。
5. 留痕：接上应用事件、API 访问日志，并给argocd_app_sync_total等指标按项目维度配告警，做到可证明、可追溯。

想继续往下挖，官方文档是权威出处：项目字段与用法看 docs/user-guide/projects.md，RBAC 全部资源与动作矩阵看 docs/operator-manual/rbac.md，完整 RBAC 配置样例在 docs/operator-manual/argocd-rbac-cm.yaml。把这几篇对照着读，你就能把上面的每道锁调到自己团队的尺度上。

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd