Allow usage of RKE2, instead of K3s

[Sironheart]

Description

K3s comes with some patches, that cause the release cycle of K3s to be slower than RKE2. Also does RKE2 come with an FIPS 140-2 compliance, and a compatible CLI to the one of K3s. I believe this change would be relatively fast to implement.
Would this be of any interest for this project?

[mysticaltech]

@Sironheart Most definitely this is something we would like to support. We actually thought about it in the past, but it requires a decent amount of work to integrating and have a switching logic between the two. If it's something you want to give a shot, me and the @kube-hetzner/core would be more than happy to assist you. PRs welcome (we can work on a draft PR together and iterate our way to supporting RKE2)!

[valkenburg-prevue-ch]

One reason which kept me from this feature, in that past, was that at that time the SELinux patches for RKE2 were not kept up to date as quickly as those for k3s. Perhaps that has changed now?

[codeagencybe]

Did somebody already start working on this? Because I'm also much interested in RKE2 over k3s.
RKE2 is way more conformant than k3s and is a lot more closer/uptodate to native Kubernetes than k3s.

I even had some people telling me for security purpose, it should be RK2E by default.
K3s has it's benefits for airgapped installs and being a tiny bit smaller than RKE2 that is beneficial to run on low power/low resource infra like Raspberry Pi's etc...

I have checked some differences about the installation process between k3s and RKE2 and so far I think @Sironheart is right about being a minimal impact to changes. It's mostly changing endpoints where to fetch the downloaders.
And one big change is that RKE2 does not autostart after installation and requires a manual "kick off".

If there is already a start somewhere, please share as I want to help to make this happen.

[mysticaltech]

@mikeywuu No progress yet, but if you want to give it a shot based on the present codebase, while @aleksasiriski works on the new architecture, please be our guest!

Since k3s and rke2 both follow the same config format and logic, having as DRY as possible code between the two with a proper switching logic should be very doable.

[mikeywuu]

@mysticaltech I would love to give it a try. Are there any special things I should consider regarding the ongoing refactoring in the background?

Also, I was wondering if the refactoring will give me the possibility to create a "management" rancher cluster which creates several "downstream" clusters. Currently, I can pass the URLs for joining / bootstrapping the management cluster for rancher to my own RKE2 installation logic.

[aleksasiriski]

I've not yet dabbled in Rancher, since I don't use it personally. The refactor should give almost zero problems for using RKE2 instead of k3s, but as for Rancher I don't really know. Anyways, since everything is modularized it will allow to easily inject whatever else is needed to make Rancher work so it shouldn't be much of a problem to add it later on :) I will be open sourcing the refactored code at the start of September.

[mikeywuu]

Hey @aleksasiriski, is there an estimate when we can expect some of the modularization? Will this be compatible with already existing clusters deployed via this project or is a re-deployment necessary? I would assume the latter?

[aleksasiriski]

No estimate yet to publish, but it's progressing very good. It will most definately have to be redeployment since the architecture is completely different and a lot of the features are missing (will have to be deployed manually, like Longhorn etc.)