What's a proper way to migrate to a new cluster using Reshifter?

[virtuman]

First of all - Thank you so much for sharing such as incredibly useful project with the community. It is very easy to use and very well done! Thumbs Up!

While I managed to quickly set it up for the ongoing backups, I have a few doubts about using ReShifter to migrate the cluster and it would be greatly appreciated if you could possibly clarify on a couple of question:

What would be the best case scenario for cluster migration, such as - old cluster is completely different.

1. New cluster was already spun up and all "system resources" have already been pre-installed on the new cluster (and configured better than they were on the old cluster).

2. We would now like to migrate workloads but without overriding what's already properly configured in the "system" pods. Is it possible to use ReShifter for that? I'm guessing filtering by not only the resources types, but also NAMESPACEs, such that we can exclude "undersired" system workspaces from the backups?

3. Also, since all nodes in the cluster are named and tagged differently from the original cluster - would ReShifter ignore the node name overrides during the backup restore, otherwise i presume that etcd will lost any context of the k8s nodes on the new cluster after the backup is restored.

Thank you!

[mhausenblas]

Thanks a lot for your feedback @virtuman and in order to understand what's really going on maybe have a look at the architecture? In a nutshell: ReShifter is rather dumb, it literally just traverses etcd and dumps the content, so any kind of business logic would have to be handled via the available strategies or extensions thereof. Hope this helps?

[virtuman]

Thank you for your prompt response. Looking at architecture and the data structure clarifies everything a lot.

Just a quick couple of question:

• will it overwrite existing keys by default, and is there a way to skip existing keys?
• backup / restore - will restore wipe all new data, or will it merge backup into currently running version? is there a way to apply backup by completely re-writing running database? or should that be done with standard etcdctl tools?

[mhausenblas]

will it overwrite existing keys by default, and is there a way to skip existing keys?

This one is a little tricky. If you look at the code, for v2 API it only restores it if the node doesn't exist whereas in v3 API it overwrites it. An inconsistency, I'm afraid. As mentioned above, using a filter strategy allows you to only back up certain keys.

backup / restore - will restore wipe all new data, or will it merge backup into currently running version?

As mentioned above, depends on the API version.

is there a way to apply backup by completely re-writing running database?

I don't understand this question.

[ipochi]

@virtuman If you only want to move workloads / data , perhaps Velero will be a better option. You can restore to a different namespace and take backups using labels or only certain namespaces

github.com/heptio/velero