Reputation: 5408
I have followed this tutorial https://vmguru.com/2021/04/how-to-install-rancher-on-k3s/
At the end of it I end up with a running k3s cluster with 3 nodes
kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane,etcd,master 7d20h v1.23.5+k3s1
master2 Ready control-plane,etcd,master 7d20h v1.23.5+k3s1
master3 Ready control-plane,etcd,master 7d20h v1.23.5+k3s1
The cluster is using embeded etcd datastore
I am confused because I am able to deploy to workloads to this cluster. I thought I could only deploy workload to nodes with a role of Worker
?
In other tutorials, the end result is master and worker roles on different nodes, so I am not even sure how I managed to get this combination of roles. Has something changed in the k3s distribution perhaps. The author used 1.19 I am using 1.23?
Upvotes: 0
Views: 1644
Reputation: 1051
A node role is just a label. There are no specs that define what must happen if you use a label like role=control-plane
.
While there are some well-known labels, among which you can find node role=control-plane, Kubernetes distributions (like k3s) don't have to follow these conventions.
kube-scheduler
actually uses Taints and Tolerations do prevent workloads running on specific nodes. To see if a node has taints run kubectl describe node <node_name>
and look for the taints field. If there are none, all workloads will run on them.
For single node clusters it's a necessary requirement that control plane components and normal workloads can run on the same machine. Even more so, putting cluster workloads on a different machine is just a best practice. Kubernetes distributions like k3s or microk8s were specifically build for smaller node clusters and disable taints by default.
Upvotes: 0