K3s can run Kubernetes on devices with as little as 512MB RAM, making it ideal for edge computing.
Imagine you’ve got a fleet of Raspberry Pis out in a factory, or sensors scattered across a remote research station. You want to manage them like any other Kubernetes cluster, but they’re not exactly beefy servers. That’s where K3s shines. It’s a lightweight, certified Kubernetes distribution designed for resource-constrained environments.
Let’s see K3s in action on a couple of Raspberry Pis.
First, on your "master" Pi (which we’ll call k3s-master), we’ll install K3s. You can do this with a single curl command:
curl -sfL https://get.k3s.io | sh -
This downloads and runs the K3s installer. It sets up a fully functional Kubernetes control plane, including etcd (or an embedded SQLite database for simplicity), the API server, controller manager, and scheduler, all bundled into a single binary.
After installation, the K3s service starts automatically. You can check its status:
sudo systemctl status k3s
You’ll see output indicating the service is active and running. K3s defaults to using SQLite for its data store, which is perfect for single-node setups or small clusters.
Now, let’s add a "worker" Pi (k3s-worker) to this cluster. On the worker node, you’ll install K3s, but this time you need to tell it where the master is and provide a join token.
First, on the k3s-master, get the node token:
sudo cat /var/lib/rancher/k3s/server/node-token
This will output a token like K3S_TOKEN=abcdef1234567890abcdef1234567890.
On the k3s-worker, run the installer with the master’s IP address and the token:
curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.100:6443 K3S_TOKEN=K3S_TOKEN=abcdef1234567890abcdef1234567890 sh -
Replace 192.168.1.100 with the actual IP of your k3s-master. This command tells the K3s agent on the worker to connect to the specified master and join the cluster.
Back on your k3s-master, you can now check the nodes in your cluster:
sudo k3s kubectl get nodes
You should see both k3s-master and k3s-worker listed with a Ready status.
The magic behind K3s’s lightweight nature is its consolidation of components. Instead of separate processes for etcd, kube-apiserver, kube-controller-manager, and kube-scheduler, K3s bundles them into a single k3s server process. For worker nodes, it’s a single k3s agent process. It also replaces etcd with SQLite by default, which has a much lower memory footprint. When you need more robust storage for larger clusters, K3s can easily be configured to use external etcd, PostgreSQL, or MySQL.
K3s also streamlines networking. It bundles a CNI (Container Network Interface) plugin, typically Flannel, but you can easily swap it out for Calico or others. It also includes CoreDNS for service discovery and a load balancer (Klipper) for ingress and service access.
The system solves the problem of running a full-featured Kubernetes experience on devices that simply can’t handle the overhead of standard Kubernetes distributions. This opens up possibilities for managing fleets of edge devices for IoT data collection, localized AI inference, or control systems where network connectivity might be intermittent or bandwidth is limited.
The most surprising thing about K3s is how it achieves its small footprint without sacrificing core Kubernetes functionality. It’s not just a stripped-down version; it’s a re-architected one. For instance, the internal containerd runtime is configured for minimal overhead, and the bundled Traefik ingress controller is highly efficient for edge use cases.
One thing people often miss is how to correctly configure TLS bootstrapping for agent nodes when setting up a more complex multi-master or HA setup. While the basic join token works for simple cases, for production environments needing secure and automated agent onboarding, understanding the server-arg and agent-arg flags in the K3s configuration file (/etc/rancher/k3s/config.yaml) is crucial. This allows you to pass custom arguments to the server and agent processes, enabling fine-grained control over TLS certificates and discovery mechanisms, which is vital for maintaining cluster security and stability as it scales.
Next, you’ll want to explore deploying applications using Helm charts, which is a standard way to package and deploy Kubernetes applications, and K3s supports it directly.