Provisioning Kubernetes clusters is a fundamental task for anyone managing containerized applications, and Rancher offers two powerful, opinionated distributions for this: K3s and RKE2.
Let’s see a cluster come to life. Imagine you’ve logged into your Rancher instance, navigated to Cluster Management, and clicked "Create Cluster." You’re presented with a choice: RKE2/K3s or Hosted Kubernetes. We pick RKE2/K3s.
The first critical decision is where the cluster will run: "Cloud Providers," "VMware vSphere," or "Custom." For this demo, we’ll choose "Custom." This means Rancher won’t auto-provision infrastructure; instead, it expects you to have existing nodes ready to join.
Next, you select your Kubernetes distribution: RKE2 or K3s. RKE2 is designed for production, hardened, and has a strong focus on security. K3s is a lightweight, certified Kubernetes distribution perfect for edge, IoT, and development. We’ll select RKE2.
Now, you configure the cluster itself. You give it a name, like rke2-prod-cluster. You choose a Kubernetes version. For RKE2, the default is often the latest stable, but you can pin it to a specific version for consistency. Then, you set the CNI (Container Network Interface). The default is typically Canal (a combination of Calico and Flannel) for RKE2, which provides robust network policies.
The core of provisioning via "Custom" involves providing node registration commands. Rancher displays two sets of commands: one for the "Server" nodes (which act as control plane and etcd) and one for "Agent" nodes (which run your workloads).
Here’s a typical Server node command you’d see:
curl -sfL https://get.rke2.io | sudo INSTALL_RKE2_TYPE="server" sh -
sudo systemctl enable rke2-server
sudo systemctl start rke2-server
sudo rke2 server --cluster-init --token=YOUR_SUPER_SECRET_TOKEN --node-ip=192.168.1.100
And for an Agent node:
curl -sfL https://get.rke2.io | sudo INSTALL_RKE2_TYPE="agent" sh -
sudo systemctl enable rke2-agent
sudo systemctl start rke2-agent
sudo rke2 agent --server=https://YOUR_RANCHER_NODE_IP:9345 --token=YOUR_SUPER_SECRET_TOKEN
You’d execute these commands on your pre-provisioned VMs or bare-metal servers. The INSTALL_RKE2_TYPE variable tells the installer whether to set up a control plane/etcd node or a worker node. The --cluster-init flag on the first server node is crucial; it bootstraps the etcd cluster. Subsequent server nodes will join this existing cluster. The --token is your shared secret for node registration, and --node-ip ensures the node registers with its correct IP. The agent command points back to the Rancher server’s API port (9345) for registration.
Once the nodes are running these commands and have successfully registered, they’ll appear in the Rancher UI. Rancher then orchestrates the deployment of essential Kubernetes components like kube-apiserver, kube-controller-manager, kube-scheduler, and etcd (for RKE2 server nodes), and kubelet and kube-proxy on all nodes.
The mental model here is that Rancher acts as a sophisticated orchestrator. It doesn’t run Kubernetes itself; it tells your machines how to run it. For custom deployments, it provides the bootstrap commands and then monitors the registered nodes, ensuring the necessary Kubernetes components are installed and configured correctly. You control the cluster’s lifecycle, versioning, CNI, and node roles through the Rancher UI and the commands it generates.
What most people don’t realize is how deeply RKE2 and K3s integrate with systemd. The systemctl enable and systemctl start commands aren’t just for initial setup; they ensure that the Kubernetes components automatically restart if a node reboots. This is a core part of their resilience.
After your RKE2 cluster is up and running, the next logical step is to explore its monitoring capabilities or deploy your first application.