search

argoproj / argo-cd

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

Application migration across clusters #1640

Open johnmarcou opened 5 years ago

johnmarcou commented 5 years ago

Is your feature request related to a problem? Please describe. Currently, when we update the cluster field on the ArgoApp manifest, ArgoCD forgets/keeps the resources on the old-cluster and recreates them on the new-cluster, which create duplicated objects on the infrastructure.

Describe the solution you'd like When we update the cluster field, ArgoCD would delete previously deployed resources on the old-cluster, then redeploy the resources to the new cluster.

Describe alternatives you've considered For now, to do this, we need to delete the app with prune mode. Then, update the cluster field, and finally reapply the ArgoCD app.

Additional context When we update the namespace field on the ArgoApp manifest, ArgoCD deletes the resources from the old-ns and recreates them to the new-ns. The exact same feature on the cluster field would be nice.

Answer on the Slack channel: "I agree this is real use case. For performance reasons we assume that app resources are deployed only to one cluster and don't check all clusters. We can solve use case by implementing 'move' action which deletes old resources and updates cluster url."

alexec commented 5 years ago

Good enhancement. One could create a list to moveTasks in this func to implement:

https://github.com/argoproj/argo-cd/blob/master/controller/sync.go#L450

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

alexec commented 5 years ago

See #1548.

ba32107 commented 2 years ago

Hi, we have just ran into this as well - has anyone managed to make any progress on this?

paragones92 commented 2 years ago

We are actually doing a bit different in our setup, as we cannot afforf to have downtime while moving applications across clusters, we actually define a new cluster where we sync the application in the new cluster while we keep it in the old one, such traffic is served at both clusters at the same time. Once we make sure the app is correctly deployed on the new cluster, we then proceed to delete the app on the old cluster before deleting the entire old cluster.

blakepettersson commented 2 years ago

We are actually doing a bit different in our setup, as we cannot afford to have downtime while moving applications across clusters, we actually define a new cluster where we sync the application in the new cluster while we keep it in the old one, such traffic is served at both clusters at the same time. Once we make sure the app is correctly deployed on the new cluster, we then proceed to delete the app on the old cluster before deleting the entire old cluster.

We do pretty much the same; all our Applications are in fact ApplicationSets. When migrating an app, the app can deploy automagically to the new cluster, and once it's provisioned we can then remove the old cluster.

ChristianZaccaria commented 1 year ago

We are actually doing a bit different in our setup, as we cannot afforf to have downtime while moving applications across clusters, we actually define a new cluster where we sync the application in the new cluster while we keep it in the old one, such traffic is served at both clusters at the same time. Once we make sure the app is correctly deployed on the new cluster, we then proceed to delete the app on the old cluster before deleting the entire old cluster.

Hi @paragones92 , that's exactly what I'm looking for with Argo CD. Is there any documents I can read more about how this can be done? Thanks so much!

cacosub7 commented 1 year ago

So, as of now, to implement resource migration (i.e., automatically clean up resources in the old destination and deploy to the new destination by modifying the destination in application.yaml and application-set.yaml), is it required to delete the old app first and then recreate it?

cdemarco-drw commented 1 year ago

This would be very nice to have, and I'd argue its absence is in fact a bug--the current behavior runs counter to users' expectations. The presence of the allowEmpty parameter suggests that Argo-CD will in fact delete ALL resources orphaned by the spec, and the "yeah but only on the currently-active destination" caveat is unmentioned.

Perhaps the performance impact could be mitigated by implementing a multiHomed flag on the Application (and its spec in ApplicationSet) which governs whether the controller looks across clusters for resources?

ak-a commented 1 year ago

As our use of ArgoCD gets bigger this will be more and more of a problem. We need to manager more clusters and will regularly need to move applications between clusters. Having this handle natively will become essential.

CHL-work commented 1 month ago

@alexec Hello, we are moving clusters frequently and manually cleaning up the the old resources is a pain. Is there any plan to fix this? Thank you.

andrii-korotkov-verkada commented 1 week ago

I think a problem is that application controller is sharded by a cluster. So once you change the cluster, app controller managing previous cluster no longer looks at that application.

Maybe we can have some parameter for migration cluster, but then there's a synchronization problem - what if the old cluster's controller tries to remove the app first? I don't know a good solution as of now yet, but it'd be good to have. I'd bring this up in the contributors meeting.

andrii-korotkov-verkada commented 1 week ago

we are moving clusters frequently

Can you describe why do you need to move clusters frequently, please?