Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability for a single application to deploy into multiple namespaces #696

Closed
jessesuen opened this issue Oct 17, 2018 · 9 comments
Closed

Comments

@jessesuen
Copy link
Member

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
Copy link
Contributor

mduarte commented Oct 17, 2018

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 :)

@alexmt alexmt added 5 labels Oct 17, 2018
@jessesuen jessesuen changed the title Ability to deploy single application into multiple namespaces Ability for a single application to deploy into multiple namespaces Oct 19, 2018
@jessesuen
Copy link
Member Author

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
Copy link

kuznero commented Nov 19, 2018

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
Copy link

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
Copy link
Member Author

@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
Copy link
Collaborator

alexmt commented Dec 1, 2018

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

@alexmt alexmt closed this as completed Dec 1, 2018
@pyang55
Copy link

pyang55 commented Jul 31, 2020

@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
Copy link

g8081 commented Feb 16, 2021

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants