Install argo-rollout CRDs and rollout operator outside production cluster

[ikatolkar]

Hi folks,

First of all thanks for the amazing product, it will prove to be very useful for our upgrade scenarios.

My question is, would it be possible to have the argo-rollout controlplane (ie argo rollout CRD, argo rollout controller/operator and kubectl plugin) installed outside the workload cluster on a separate management cluster? Most of our customers are very reluctant when it comes to having third-party/open-source CRDs installed on their production/workload clusters.

Can we install argo-rollout controller and rollout CRD on a remote management cluster? If it needs a kubeconfig file to interface with the workload cluster we could provide that in form a k8s secret. Similar to what fluxCD does by allowing you to create HelmChart objects on management clusters which would then create deployments (and other resouces) on the workload cluster.

Is it currently possible with argo-rollouts? Is such a feature in plans?

Thanks and regards!

[jessesuen]

It is not possible to install the CRDs outside of the workload cluster, because the Rollout model is equivalent to a Deployment. Rollouts/Analysis/Experiments are considered namespaced objects which are managed by end users. They frequently perform namespace related operations, including:

• reference Secrets, ConfigMap, Analysis
• create Jobs/ReplicaSets
• manage pods

In other words, if the Rollout CRD is in cluster A namespace, how do you have it reference ConfigMap in cluster B namespace?

While, it is possible to run the actual controller in a different cluster and give it kube credentials to a workload cluster (e.g. this is in fact how we do development), you have some problems with:

1. reliability - if the controller cannot talk to the K8s cluster, then updates will not happen
2. security (credentials) - managing a set cluster credentials to the workload cluster would less secure than,
3. security (behavior) - if controller logic is controlled externally, then it could be changed at any time (perhaps maliciously). Customer would have to be willing to accept the possibility that controller logic can change at any time (even without a change in their own cluster).

I just don't see the benefit, other than perhaps centralized management. But even that is a weak argument, since new versions of CRDs would need to be installed in workload clusters, in lock-step with the remote controller version.