search

argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.55k stars 5.35k forks source link

[ArgoCD] Shared applicationset controller for multiple argocd Instances #20101

Open rajarshipal-lab opened 5 days ago

rajarshipal-lab commented 5 days ago

Summary

Multiple Argocd instances deployed across multiple namespaces using a single applicationset controller hosted in a central namespace

Motivation

Assuming 500 argocd instances with 1 applicationset controller pod each are running across organizations in an enterprise, where total pod count becomes 500 for only applicationset controller, also can't ensure usage of all those instances are to the fullest, may be a dedicated centralized applicationset controller would benefit...

Proposal

A new property in argocd-cm with a key named as ARGOCD_SHARED_INSTANCE_NAMESPACES and values for this would be argocdNamespace1, argocdNamespace2, etc..

Also allocating appropriate rolebindings to argocd-applicationset-controller service account to access the namespaces mentioned in ARGOCD_SHARED_INSTANCE_NAMESPACE (this rolebinding should not be provided as part of the feature rather needs to be manually configured by users)

Changes required in cmd/argocd-applicationset-controller/commands/applicationset_controller.go within NewCommand function. So, upon iterating the list of namespaces we get all existing details from the existing argocd-cm and argocd-cmd-params which are already deployed in argocd namespaces, and spawn up informer

rajarshipal-lab commented 5 days ago

@crenshaw-dev Can you please review the proposal!

todaywasawesome commented 3 days ago

I'm not sure the juice is worth the squeeze on this one. Yes you save on pod replication but your permission structure needs to be much more complex and require a lot of additional configuration.

In this case you have 500 Argo CD instances on one cluster, wouldn't it be better to focus on making Argo CD more multi-tenant friendly? The addition of impersonation gets us pretty far down that road.

rajarshipal-lab commented 3 days ago

@todaywasawesome I agree with your proposal for multi-tenant thingy, we already tried and it did not work out well for our usecases. About the permission thingy as mentioned, if I understand correctly, it seems appropriate role binding to the service account responsible for the argocd-notifications-controller should have access to multiple namespaces, and if so it will be able to read argocd-cm and argocd-cmd-params from other namespaces where it would be able to find the details to fire the events. I agree the concern, that a single pod hosted in a central namespace will have access to secrets from multiple other namespaces, so maybe calling it a central managed argocd-notifications-controller would work..