Does Argo Rollouts support non-deployment resource?

[morningspace]

Hi team, I have a question regarding the use of Argo Rollouts. I read through some Argo Rollouts materials where the demos always use Deployment as the rollout target. Is there a way for people to use other Kubernetes resources (or custom resources) to do the rollout. It seems the current Argo Rollouts does not support this according to the Rollouts Specification. I'd think this will greatly help people who want to try Argo Rollouts if we can support this.

[kostis-codefresh]

Hello

You can reference an existing deployment instead of converting to a rollout https://argoproj.github.io/argo-rollouts/migrating/#reference-deployment-from-rollout if you are asking this.

Is there a way for people to use other Kubernetes resources (or custom resources) to do the rollout.

What other resources do you have in mind that you would like to use Argo Rollouts for?

I'd think this will greatly help people who want to try Argo Rollouts if we can support this.

For getting started, I think deployments are the easiest way to go. No?

[morningspace]

Hi @kostis-codefresh thanks for your reply!

Yeah, I saw the doc that using reference to existing Deployment instead of converting one which is cool, and I also understand to start w/ Deployment would be the easiest way to go.

I just curious whether Argo Rollouts limits the type of Kubernetes resources to be rolled out. i.e. it has to be Deployment, or, it can be arbitrary Kubernetes resources. In my case, we use OLM (Operator Lifecycle Manager) where typically it will leverage CatalogSource, ClusterServiceVersion, Subscription, etc. to deploy the actual workloads in Kubernetes cluster. Usually, a Subscription would map to a bunch of Deployments along w/ other Kubernetes resources such as Secrets, ConfigMaps, etc.. So, these are all Kubernetes custom resources. It would be good to know if Argo Rollouts can also support Kubernetes custom resources other than Deployment.

[jessesuen]

Rollouts is not able to work with CRDs or even other native K8s kinds (StatefulSet, DaemonSet) because the implementation of a Rollout maps closely to Deployments, in that it manages ReplicaSets.

While it would be easy to add support to reference other Kubernetes kinds using the workloadRef feature, it would be for the sole purpose of obtaining the PodTemplate definition in that other kind. It would not exhibit the behaviors of that resource kind. For example, even if we added support the Rollout to reference a DamonSet, the Rollout would still not act like a DaemonSet by deploying a pod on every node. For that, we would need/want to introduce a new kind (e.g. RolloutDaemon).

[morningspace]

@jessesuen Thanks for your clarification. I can understand the situation. It looks the key point here is that Rollouts is designed to rollout the actual workloads, essentially the Pod, which needs to obtain its definition then deploy. With that, in the case of DaemonSet, after obtain PodTemplate definition from DaemonSet, and deploy it as a Pod, it has to introduce something such as RolloutDaemon, to align w/ the behavior that DaemonSet has.

Well, I'd think the original case still makes sense to me, i.e. to rollout arbitrary Kubernetes resource. But per the current design/implementation, it's not easy to support this case. I think this would be technically feasible as long as we do not tightly coupled w/ the behavior of target resource to be rolled out.

[Dentrax]

Supporting rollout for CRD or any other arbitrary Kubernetes resource would definitively a good use-case for the Argo Rollouts.

Imagine someone working on high-scale environment want to change a critical ConfigMap or CRD and should be carefully tested on each cluster/node. What I want from Rollouts is that it should completely replace the resource that I want to apply on production, in case any error observed it should rollback the previous state.

Due to restrict implementation of Rollout maps closely to Deployments, this lead us to look at what the other Argo alternatives around there are. Which actually we don't want to in the first place.

Are there any proposal or roadmap plan for this? It would be great to address this idea. @dthomson25 @jessesuen

cc @developer-guy

[romuduck]

Agreed... benefiting from the analysis part for any change would be awesome. As of today we have a custom layer on top of Argo-CD.

[Dentrax]

What kind of custom layer have you created?

[andyxning]

Native statefulset or openkruise advanced statefulset are also needed to rollout with more control, such as blue-green/halt.