Hey! I'm the author of the post, glad you enjoyed it!

Yes, you would just attach it to the network switch and have it join the cluster.

The control plane will "discover" the additional capacity and redistribute workloads if necessary.

With k3s, a new node can join the cluster with a single command (assuming you have the API token).

Something like:

  $ curl -sfL https://get.k3s.io | K3S_URL=https://$YOUR_SERVER_NODE_IP:6443 K3S_TOKEN=$YOUR_CLUSTER_TOKEN sh -

One disadvantage of k3s, is that it does not have HA control plane out of box (specifically, users are expected to bring their own HA database solution[1]). Without that, losing the single point of failure control plane node is going to give you a very bad day.

I use kubespray[2] to manage my raspberry pi based k8s homelab, and replacing any nodes, including HA control plane nodes, is as easy as swapping the board and executing an ansible playbook. The downsides of this, are that it requires the users to have more knowledge about operating k8s, and a single ansible playbook run takes 30-40 minutes...

1. https://rancher.com/docs/k3s/latest/en/installation/ha/

2. https://github.com/kubernetes-sigs/kubespray

> One disadvantage of k3s, is that it does not have HA control plane out of box

This hasn't been true for a while, since these days K3s ships with etcd embedded: https://rancher.com/docs/k3s/latest/en/installation/ha-embed...

Thanks for the info. I haven't been following k3s development after I decided to switch to kubespray. Glad that this concern has been addressed. Nice work!