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.

[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.)

[maggie44]

@aleksasiriski is the a branch you are working on for the refactor? Would be interested in taking a look at what a RKE2 implementation would involve, but seems not much point doing it against main branch right now if there is going to be a big refactor coming.

[tiran133]

Is there any update on this?

[mikeywuu]

@aleksasiriski can we help? Still excited to see this big chance coming :)

[mikeywuu]

Hi folks,
im actively working on this feature and have made already good progress on it. Im able to spawn a RKE2 cluster with cilium. Existing k3s clusters are unaffected as far as I could test.
Im close to opening a draft PR along some topics open for discussion. I tried / am trying to keep it as DRY as possible but unfortunately some things are bootstrapped differently with RKE2.

I would like to open this up for others to contribute to make sure other scenarios can be tested / fixed. Should I open a draft PR for this so we can work on this together?