How can new entries to the “Kubernetes Version” dropdown be added when provisioning a new cluster using RKE2 from the Rancher UI? Currently, the dropdown has options for RKE2 or K3s based clusters, but I am an interested in adding a different Kubernetes distribution here.
Any existing documentation on this process? I wasn’t sure how this dropdown gets populated, or how the necessary data gets pushed down to the rancher/machine job so that the node driver can install the correct version of Kubernetes.
Thanks for any input!
What you are looking is called the cluster-driver. (See link below) TLDR; Rancher supports externally managed cluster IE you build cluster and take the Kubernetes components outside of Rancher (etcd, kube-api server, etc) then you import the cluster into Rancher while provides you the dashboard, fleet controllers, authentication.
Now Rancher deployed hosted Kubernetes distributions like EKS, GKE, AKS, etc because their is cluster-drivers for them and Rancher is basically just called the cloud provider’s API and requesting a cluster just like you would do in their web console.
As far as Rancher deploying other Kubernetes distributions on generic servers using the Rancher agent. That is limited to only RKE1/2 and k3s because those are Rancher’s distributions. If you want to deploy something else like OpenShift on your own servers. That is not something Rancher can do.
Note: There is some public discussions around cluster-api that might change this statement in the future. https://twitter.com/ibuildthecloud/status/1221101286210170885?lang=en
Hi, thanks for the reply! What I want to do is use the Node Driver, but with my own Kubernetes distribution. With a node driver, you can choose some predefined Kubernetes versions - I assume they ship with the Rancher version you have installed. I need to add my own Kubernetes versions to this dropdown (included screenshot below from node driver form, see how there are RKE2 and K3s distributions included), and was wondering if there was any pointers or documentation on how to do this. If that means modifications to Rancher itself, that’s fine.
I am also curious of the interaction between the kubernetesVersion in the Cluster CRD and how Rancher processes this to get the correct bootstrapping done by the rancher/machine infrastructure provisioning job.
So this drop-down is populated by a metadata file that is baked into Rancher at build time. Now Rancher will reach out to kontainer-driver-metadata/data at dev-v2.7 · rancher/kontainer-driver-metadata · GitHub every 6 hours looking for updated RKE1/2 and k3s versions. So if this is an air gapped environment IE Rancher can’t reach the internet, that will not get updated. You can of course download that json data (it’s like ~5MB) and host it internally and go to Rancher settings and change the metadata URL. I also built a image for doing this too. support-tools/rancher-metadata-syncer at master · rancherlabs/support-tools · GitHub.
Note: 1.24.8 is the latest certified version so anything newer will need to be made manually outside of Rancher then imported but of course there is no guarantee that you won’t have problems.
You can find the official support matrix at Support matrix | SUSE
Thanks again for the info. Since I am interested in providing my own Kubernetes distribution, looks like Cluster driver implementation is a better choice than Node driver. The Rancher provisioning APIs seem tightly coupled with K3s/RKE2.
