K3s: Lightweight Kubernetes for Dev and Edge

Kubernetes in Under 100 Megabytes

Kubernetes is powerful, but that power comes at a price: a full cluster requires etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and a whole host of additional components. For production environments in the cloud, that's acceptable. For local development, CI/CD pipelines, or edge scenarios on resource-constrained hardware, it's simply too much.

That's exactly the problem Rancher Labs addressed. About six weeks ago, in February 2019, K3s was released -- a certified Kubernetes distribution that comes as a single binary under 40 MB and can be installed with a single command. The name says it all: if Kubernetes with its ten letters is abbreviated as K8s, then the slimmed-down variant with five letters is K3s -- half the size, half the complexity.

We've been testing K3s over the past few weeks on several development machines and a handful of virtual machines. Here is our first field report.

What K3s Does Differently

K3s is not a fork of Kubernetes, nor is it a proprietary orchestration framework. It is Kubernetes -- certified by the CNCF and fully API-compatible. The difference lies in what Rancher Labs has removed and replaced.

SQLite instead of etcd: The most notable change concerns the datastore. Instead of the distributed key-value store etcd, K3s uses SQLite as its default backend. For single-node setups and smaller clusters, this is perfectly adequate and saves significant resources and complexity. If you prefer etcd or MySQL as a backend, you can still configure that.

Containerd instead of Docker: K3s ships with containerd as the container runtime built in. Docker is not needed and not required. This reduces overhead, but it means that docker ps on the host won't show K3s containers. Instead, you work with crictl or directly with kubectl.

Single binary: All Kubernetes components -- API server, scheduler, controller manager, and kubelet -- are bundled into a single binary. No separate setup of individual services, no complex certificate management during bootstrapping. One binary, one command, one running cluster.

Removed ballast: Cloud provider integrations (AWS, Azure, GCP), deprecated APIs, and non-standard storage drivers have been removed. What remains is a lean Kubernetes core that does what you actually need on local hardware or at the edge.

Installation: A Single Command

Installing K3s is almost irritatingly simple. On a Linux system, all you need is:

curl -sfL https://get.k3s.io | sh -

That's it. After a few seconds, a complete Kubernetes cluster is running. The K3s server process starts automatically as a systemd service, and kubectl is included out of the box.

You check the cluster status as usual:

# Cluster-Info abfragen
sudo kubectl cluster-info

# Nodes anzeigen
sudo kubectl get nodes

The output looks familiar -- after all, it's standard Kubernetes:

NAME        STATUS   ROLES    AGE   VERSION
my-host     Ready    master   30s   v1.13.5+k3s.1

The sudo is needed because K3s stores the kubeconfig by default at /etc/rancher/k3s/k3s.yaml. Alternatively, you can copy the file to your own ~/.kube/ directory and set the KUBECONFIG environment variable.

First Workload: Deploying nginx

To verify that the cluster actually works, we deploy a simple nginx web server:

# Deployment erstellen
sudo kubectl create deployment nginx --image=nginx

# Auf drei Replicas skalieren
sudo kubectl scale deployment nginx --replicas=3

# Service vom Typ NodePort erstellen
sudo kubectl expose deployment nginx --port=80 --type=NodePort

A look at the running pods:

sudo kubectl get pods -o wide

NAME                     READY   STATUS    RESTARTS   AGE
nginx-65f88748fd-2k7jm   1/1     Running   0          15s
nginx-65f88748fd-8xb4p   1/1     Running   0          10s
nginx-65f88748fd-wqnzl   1/1     Running   0          10s

Three pods, all Running, within seconds. On a conventional Kubernetes cluster, just setting up the cluster alone would have taken longer than this entire deployment.

You can find the assigned NodePort via:

sudo kubectl get services

The service is then accessible at http://localhost:<NodePort>. Everything behaves exactly as you'd expect from Kubernetes -- because it is Kubernetes.

Comparison with Minikube and Docker Desktop

If you've been developing locally with Kubernetes, you probably know Minikube or the Kubernetes built into Docker Desktop. How does K3s compare?

Minikube creates a full virtual machine with a Kubernetes cluster inside. That works reliably but comes with the overhead of a VM: several gigabytes of RAM allocation, longer startup times, and an additional layer of abstraction. K3s runs directly on the host or in a minimal container and starts in seconds rather than minutes.

Docker Desktop Kubernetes is convenient but tied to Docker Desktop and limited to macOS and Windows. It also uses a VM under the hood and requires significantly more resources than K3s.

K3s has a clear advantage when it comes to startup speed and resource consumption. However, K3s runs natively only on Linux. On macOS or Windows, you need a Linux VM -- which partially negates the resource advantage. For Linux-based development machines and CI servers, though, K3s is the leaner alternative.

Where K3s Truly Shines

Beyond local development, we see three scenarios where K3s fully realizes its potential.

CI/CD Pipelines: If you want to test Kubernetes manifests, Helm Charts, or operators, you need a quickly available cluster. K3s can be spun up in a CI pipeline within seconds, tests run, and then everything is torn down again. No waiting for cluster provisioning, no cloud costs.

Edge Computing: On devices with limited memory and processing power -- industrial controllers, IoT gateways, remote locations -- a full Kubernetes cluster is unrealistic. K3s runs with 512 MB of RAM and a single CPU core. This opens up Kubernetes-based deployments in places where they were previously unthinkable.

Raspberry Pi: K3s supports ARM architectures. A Kubernetes cluster made of Raspberry Pis -- as a learning environment, home lab, or for specific use cases -- is now seriously feasible. Not just as a toy, but with a certified Kubernetes distribution.

Limitations and Open Questions

K3s is only a few weeks old, and that shows in some areas. Documentation is still thin. The community is growing fast, but there are few experience reports for edge cases. High-availability setups with multiple server nodes are currently not officially supported -- for production environments with failover requirements, that is a real obstacle.

The question of upgrades and lifecycle management also remains open. With such a young distribution, there is simply no track record for how updates work in practice and what pitfalls may arise. Anyone deploying K3s in near-production environments today should be aware that they are an early adopter.

Conclusion

K3s solves a real problem: Kubernetes has been too heavyweight for many use cases beyond the cloud. Local development, CI/CD, and edge computing needed a lighter alternative -- and with K3s, Rancher Labs delivers exactly that. The CNCF certification ensures that it is real Kubernetes and not an incompatible proprietary solution.

For our daily work, we see K3s primarily as a tool for development and test environments. In CI pipelines, it is already replacing heavier alternatives. Whether and when K3s becomes viable for production workloads depends on how quickly Rancher Labs addresses the open issues -- particularly high availability and stable upgrade management.

If you use Kubernetes or plan to, you should keep K3s on your radar. The barrier to entry could not be lower: a Linux system, one command, and thirty seconds of patience. After that, you have a complete cluster that behaves exactly like any other Kubernetes. There's hardly an easier way to experiment with Kubernetes.