major k8s upgrades using this?

[KlavsKlavsen]

I am looking into building a procedure for our Major k8s upgrades, where we simply setup a NEW cluster, so we get to test our entire recovery procedure every 6-9 months, when we need to do a major upgrade anyways - and then the plan is to connect the 2 clusters with something like liqo, and migrate ONE service at a time (or one namespace) - and if we hit any issue with newer k8s version (it does happen :) - we can just roll that one back - and the cluster would still have working services and hence we are not stressed to solve the issue.
Doing this, ofcourse IS an issue with migrating PVCs - but in this case, the clusters would be at the same provider, so the PV could be moved over - and able to connect to the resouce at AWS f.ex.
This is a little more interesting for our ceph using clusters (which currently use rook to run ceph inside cluster) - but for those, the plan would be to simply stop the pods on the source cluster (causing service down) and triggering the backup and then do recovery of pvc to new cluster - to properly test recovery procedure for pvcs if one wants.

[aleoli]

Hi @KlavsKlavsen! At the moment Liqo is not able to migrate your applications in that way.

Liqo will allow you to offload your workload and your services to the remote cluster, but at the moment it only works at the pod level: you will have your pods up and running in the remote cluster, but you will not see the deployments/statefulsets/etc, for that reason you will not be able to unjoin your "source" cluster.