Why should I use k3s?

[guettli]

Please elaborate why it makes sense to use k3s and not the default bootstrap provider.

Numbers would be great, so that potential users see the benefit.

[michaelpayne02]

k3s is a single binary less than 70MB in size, and doesn't require two nodes to start a cluster. This cuts memory and cpu usage by an order of magnitude. I don't have exact numbers, but this list is explains itself.

pods required on default control plane node:

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager (optional)
• coredns

control plane & worker pods:

• kubelet
• kube-proxy
• container runtime (most likely containerd)
• kube-vip
• CNI (calico by default)

Compared to components needed to run k3s:

• k3s

The single binary includes the api-server, scheduler, controller-manager, kubelet, proxy, and flannel. Not to mention external datastore support in the future.

[mkmik]

k3s also gives you the option to use an external database for storing apiserver state, which removes the need to run a etcd cluster for control plane HA

[zawachte]

k3s also gives you the option to use an external database for storing apiserver state, which removes the need to run a etcd cluster for control plane HA

and sqllite for running on devices with lowend storage!

[mkmik]

That said, the main reason I chose cluster-api-k3s is for the simplicity of of the controller and the resulting easy of troubleshooting. The k3s distribution is designed for installation simplicity and the steps performed by the provisioner can be easily reproduced manually