Multi Tenancy for Development Teams #1347
-
|
What is the recommended approach for multi tenancy? Is it possible or recommended to install dedicated Argo Rollouts controllers for different development teams? Is it also possible to have a "managed-namespace" installation like Argo Events and Argo Workflows? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Actually with have dedicated ArgoCD installations for different Development Teams in the same cluster, so they can install, manage and use ArgoCD in a "team scope". Now we're thinking about adding the possibility to do the same with Argo Events, Workflows and Rollouts. Just searching for the best way to do it.... |
Beta Was this translation helpful? Give feedback.
-
|
You should consider the rollout, workflow, events controller the same as any native kubernetes controller and namespaced scope resource. The canonical unit of tenancy in Kubernetes is a namespace. The workflow, rollout, and event resource objects to not cross namespace boundary permissions (e.g. a Rollout cannot create pods or access secrets in a different namespace). While it is possible to install the rollout controller in a single namespaced mode, this is usually used in the context of testing, or when a cluster admin does not wish to grant ClusterRoles / ClusterRoleBindings to the controller. Most installations will install it cluster-wide.
IMO, while this is supported, it does seem like overkill for Argo CD, as Argo CD was designed to deal with multiple clusters and namespaces in a highly multitentant environment. As such, Argo CD has created its own Project & RBAC concept that can create boundaries across clusters and namespaces. |
Beta Was this translation helpful? Give feedback.
-
|
Even when not being the preferred deployment approach I think it would be good to update the Argo-rollouts documentation to include the "per-namespace watching " deployment mode of the controller (this question is only answered in this discussion item .. and from source code reading, of course) |
Beta Was this translation helpful? Give feedback.
You should consider the rollout, workflow, events controller the same as any native kubernetes controller and namespaced scope resource. The canonical unit of tenancy in Kubernetes is a namespace. The workflow, rollout, and event resource objects to not cross namespace boundary permissions (e.g. a Rollout cannot create pods or access secrets in a different namespace).
While it is possible to install the rollout controller in a single namespaced mode, this is usually used in the context of testing, or when a cluster admin does not wish to grant ClusterRoles / ClusterRoleBindings to the controller. Most installations will install it cluster-wide.