Ability for a single application to deploy into multiple namespaces

[jessesuen]

Currently the concept of an application is tied to a namespace, and it's not possible to deploy an application into multiple namespaces, since during deployment we append --namespace flag to all the kubectl apply commands.

However, some apps such as Traefik ingress controller may want deploy resources into two namespaces. Need to see if there is a clean way to support this.

[mduarte]

On another issue there's also a desire to expand the definition of an application: #677. I know this is not directly related, but perhaps if the application is to be extended, perhaps it can be done in a way to address both requirements :)

[jessesuen]

NOTE: the Application CRD currently also has a limit on apps belonging to a single namespace. See: kubernetes-sigs/application#67

Since we ultimately need to be compatible with the Application CRD, I would hesitate on implementing support for this until something is decided there.

[kuznero]

Is there any workaround to this issue? I can imagine that I can split up my helm chart into separate ones to be deployed to different namespaces. That will work likely, but that is not super convenient. Do you have any other way to work it around perhaps?

[janbrunrasmussen]

I just started looking at argocd, so I apologies if I am missing context, but one reason for us to move away from our current push based CD is to enable deploys on multiple clusters, which I guess could be somewhat similar requirement to deploying to multiple namespaces? What is the stance on this?

[jessesuen]

@janbrunrasmussen Argo CD already supports deploying to/managing multiple clusters, including the cluster Argo CD is currently running in, as well as external clusters. The request here is: currently an Argo CD application is defined as:

• a git repository
• a path in the source repo (contains manifests, helm chart, kustomize app, etc...)
• a destination cluster
• a destination namespace

The fourth item is the current limitation. Today, it is trivial to deploy many apps each to a different namespace, but we currently don’t support a single app that wants to deploy to multiple namespaces (I believe istio is an example of a helm chart that wants to deploy to two namespaces).

The technical details are that when deploying, we run kubectl apply -f manifest.yaml —namespace some-namespace, where some-namespace contains the value that user defined when creating the application. We need to intelligently decide to use that flag, depending on if the manifest has a hard-wired namespace or not.

There are other implementation details that need to be ironed out as well, including:

• honoring project restrictions on namespaces, when a hard-wired namespace is disallowed in the project
• Reworking the way we are querying applications resources (by namespace)

[alexmt]

Now argocd honor namespace specified in target resource. This is enough to support helm charts which have hardcoded namespaces for some resources (e.g. istio chart) .

If this is not enough we might support specifying target resource namespace in application spec. Closing ticket for now.

@mduarte, @kuznero please let me know if any additional enhancements are needed for multi-namespace support

[pyang55]

@alexmt you can check out https://github.com/pyang55/k8sdeploy and tell me what you think, however you must be using helm to deploy apps

[g8081]

@janbrunrasmussen Argo CD already supports deploying to/managing multiple clusters, including the cluster Argo CD is currently running in, as well as external clusters. The request here is: currently an Argo CD application is defined as:

• a git repository
• a path in the source repo (contains manifests, helm chart, kustomize app, etc...)
• a destination cluster
• a destination namespace

The fourth item is the current limitation. Today, it is trivial to deploy many apps each to a different namespace, but we currently don’t support a single app that wants to deploy to multiple namespaces (I believe istio is an example of a helm chart that wants to deploy to two namespaces).

The technical details are that when deploying, we run kubectl apply -f manifest.yaml —namespace some-namespace, where some-namespace contains the value that user defined when creating the application. We need to intelligently decide to use that flag, depending on if the manifest has a hard-wired namespace or not.

There are other implementation details that need to be ironed out as well, including:

• honoring project restrictions on namespaces, when a hard-wired namespace is disallowed in the project
• Reworking the way we are querying applications resources (by namespace).

Here is our use case. We have one app and want to deploy the same in two different name spaces (a k a environments). We created two different projects in Argo CD i.e. one Argo CD project for each name space in K8s cluster. Our App Helm charts and other configuration files are correctly referring to their destination name spaces.

ArgoCD does not distinguish the same app name defined in its two different projects going to two entire name spaces.

The extreme thing is that without giving warning it simple wipes out everything existing (hard delete of all resources) and re-create it again messing all existing deployment.

Please educate whether Argo CD supports housing the same app in two different Argo CD Projects that are targeted to two different name spaces in the same K8s cluster. FYI, we have our DEV and QA environments housed in their respective name spaces in K8s cluster.

[Chris-Carmichael]

@g8081 - If you update your helm charts or deployments to use different instance labels per installed app, ArgoCD will manage them separately. Make sure the value for the app.kubernetes.io/instance: key is different per object, and you'll be good to go.