This message was deleted.

If you reach out to SUSE sales they should be able to help you with that. They have some good material. Unless you're planning on going without support, I guess :)

jup, support isn´t something the customer is willing to pay for. I will try to scrape some material from the sales website from suse. Thanks

Over a decade ago, I installed a bunch of Linux VMs for various projects that I was maintaining but was told I'd be ramped down. At that time the three Linux distros with support were RHEL, SUSE, & Ubuntu. RHEL & SUSE required you install the support-bearing distro immediately or you'd never have support, but Ubuntu allowed same install and people could just call up for a year of support later if desired. That's why I chose Ubuntu for that customer letting them know that they had that option if they wanted/needed it later after I'd moved on. I didn't ask their sales folks if an unsupported cluster could have support turned on, but I did ask if I wanted to start out getting support the first year for both prod & dev clusters and then drop dev support after the first year and it was up and running and the sales guy said that was pretty common. I also appreciated with Rancher versus, say OpenShift, that the free version of the software can be installed without a license cost (and thus without vendor support) at development teams' shops or even more often in small clusters to prototype a feature (I currently have four small segmented cluster for different Rancher installs for some testing, $0 license fees). Another argument for a "Kubernetes distribution" such as RKE2 with Rancher, over vanilla Kubernetes is that you get a lot of bundled useful support tools that you'd otherwise have to install piece by piece. If the distribution mismatches the desired toolset, then it's not a help, but it can be worth it to find such things first. Next argument, and it's a balance, is that a distribution like Rancher & RKE2 will have integration testing for the various bundled parts. This will lead to sometimes those parts not being the very latest versions (even usually), but it also usually means less problems with them that have to be solved on the user's cluster than when you have vanilla weaving everything together. So it's a bit of a pro and a con. Final thing that RKE2 specifically gives you is a more locked down default profile than you'll get from vanilla Kubernetes. At the same time the vanilla Kubernetes docs told me I had to disable SELinux I could, and eventually did, install RKE2 with SELinux enforcing. So it's saving some work on lockdowns and security compliance checklists for you as well.

@rapid-helmet-86074 thank you for your answer. I think i will just install RKE2 with these arguments. That should suffice.

@brief-mouse-13981 And if you want something really nice and near maintenance-free, you can couple rke2 with flatcar OS (https://flatcar-linux.org/) to get an immutable OS as CoreOS is for Openshift, then add the flatcar upgrade operator (https://github.com/flatcar-linux/flatcar-linux-update-operator) to automatically maintain your OS up-to-date from a kubernetes-aware mecanism, and also the rancher system-upgrade-controller to upgrade rke2 as a workload (https://github.com/rancher/system-upgrade-controller, also mentioned here (https://docs.rke2.io/upgrade/automated_upgrade/) Nothing looking like a kubernetes cluster for developers only! 🙂