Intro

• K3s is a full blown K8s distribution packaged as a single binary. It allows setting up the K8s cluster much easier as we only have to install a single binary, which installs all the required control-plane components as pods in the kube-system namespace.
• K3s uses SQLite as the storage backend by default, also supports MySQL, Postgres and ETCD as the storage backend.
• K3s automatically restarts after node reboots or if the process crashes or is killed (resilient)
• Installs the following by default:
  • containerd as the container runtime
  • Flannel (CNI)
  • CoreDNS
  • Traefik (Ingress Controller)
  • KlipperLB - load balancer solution to allow the Traefik load balancer service (Traefik proxy) to be available on port 80 and 443 on the node
• K3s monitors the manifests directory and installs all the resources present in it - /var/lib/rancher/k3s/server/manifests
• K3s comes with HelmChart CRD to automate installing Helm charts when the cluster is bootstrapped. It avoids having to install the helm chart using the command line as an additional step. HelmChartConfig CRD can be used to modify the static config (values.yaml) in the helm chart.

Architecture

• A server node is defined as a host running the k3s server command, with control-plane and datastore components managed by K3s.
• An agent node is defined as a host running the k3s agent command, without any datastore or control-plane components.
• Both servers and agents run the kubelet, container runtime, and CNI.

Single Server Setup

Single server setups use a local SQLite DB to store the cluster state. Embedded SQLite is not supported in multi-server configuration.

High Availability Setup

When using embedded etcd DB, we need at least 3 server nodes (master nodes). This is required to have quorum in case a master node goes down.

If instead, we’re using an external DB to store the cluster state, we can get away with 2 master nodes.