K3s — Lightweight Kubernetes, from concept to production

The problem: Kubernetes is powerful, but heavy

Kubernetes has become the standard for running containerized applications. The problem isn't what it does — it's everything it drags along: a full cluster needs etcd, cloud plugins, controllers and resources that make sense in a data center, but not on a single server or a Raspberry Pi. k3s was built precisely to fix this.

What k3s is

k3s is a CNCF-certified Kubernetes distribution, developed by Rancher (now SUSE). "Certified" is the important part: it's not a stripped-down or incompatible fork — it's real Kubernetes, with the same API, the same kubectl commands, the same manifests. Anything that runs on a standard Kubernetes cluster runs on k3s.

The difference is the package: everything fits in a single ~70 MB binary, with no external dependencies.

How it works

k3s condenses the Kubernetes components (API server, scheduler, controller manager, kubelet, container runtime) into one binary. For state storage, it uses embedded SQLite by default — instead of etcd, where most of the complexity lived.

• Single-node mode: server and agents run on the same machine. Ideal for homelab, CI or edge.
• Multi-node (HA) mode: several k3s servers share state through an external database (MySQL, Postgres, etcd).
• Agents: worker machines that join the server with a token. Scale by adding nodes.

What was removed: alpha or legacy features, in-tree cloud providers, old storage drivers. What stayed: lightweight replacements (containerd instead of Docker, Traefik as the default ingress, ServiceLB for simple load balancing).

What it's for, in practice

• Edge and IoT: running Kubernetes on modest hardware, with flaky networks and no operations team.
• Homelab: having a real cluster at home — on a Pi, a NUC, an old server — to learn and host your own services.
• Small and medium production: sites, APIs, internal apps that don't justify the complexity of a full Kubernetes cluster.
• CI/CD: ephemeral instances in pipelines to test manifests before they reach production.
• ARM: first-class arm64 support — the same binary runs on a Pi or an AMD64 server.

k3s vs traditional Kubernetes (k8s)

The right question isn't "which is better" — it's "what do I need". If you have a platform team, multiple data centers and need every cloud-native feature, full k8s makes sense. If you want Kubernetes without the overhead — for a single server, a home cluster or dozens of edge nodes — k3s is the choice.

What you can run on k3s

Because it's certified Kubernetes, k3s runs virtually everything a standard Kubernetes cluster runs: websites and web platforms, APIs, containerized databases, internal tools and automation pipelines. The question isn't "what runs on it", but "how far does it scale".

On a single node, it handles institutional sites, blogs, headless CMS and internal apps with real traffic without breaking a sweat. In a multi-server setup with an external database (MySQL, Postgres or etcd), the same k3s serves medium-sized workloads — internal SaaS platforms, small and medium e-commerce, microservice suites. How far that goes depends on three concrete factors: the load you intend to serve, the resources (CPU, RAM, network) you have to distribute, and the architecture you want to implement. There's no magic number — there are engineering decisions.

Where it's used, in practice

• Retail networks: chains with hundreds or thousands of stores, each running a k3s for point-of-sale, inventory and sync with headquarters. It's the most documented edge computing pattern for k3s — SUSE/Rancher themselves position it for this scenario.
• Industry and IoT: production lines and edge devices that need local orchestration, with intermittent networking and no on-site operations team.
• Web platforms and SaaS: sites, APIs and medium-sized applications where a managed cluster would be overkill, but where you want the full Kubernetes API — volumes, ingress, secrets, autoscaling.
• Development and CI/CD: ephemeral environments in pipelines and k3d (k3s inside Docker) for local development that mirrors production.

k3s is a CNCF sandbox project with tens of thousands of stars on GitHub — adoption isn't a promise, it's a fact. And when a workload grows beyond k3s's target, the same ecosystem offers RKE2 (Rancher Kubernetes Engine 2): also from SUSE, with the same tooling, but designed for heavy production and compliance (CIS, FIPS). The transition is incremental, not a traumatic migration.

Getting started in one command

On any Linux machine:

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

When it finishes, you have a complete Kubernetes cluster running. kubectl is already installed and configured:

sudo k3s kubectl get nodes

To add a second node as an agent, run the same command with the server's token. In five minutes you're familiar with the concepts; in a day you have services running with persistent volumes and ingress.

In short

k3s is Kubernetes without the excess: the same API, CNCF-certified, in a single binary that runs from a Raspberry Pi to highly available production clusters. It is not a stripped-down version or an imitation — it is what remains of Kubernetes once you remove what most real workloads never use. For sites, platforms and medium-sized applications, it is the most direct path from needing to orchestrate containers to having them running. And when the workload outgrows it, RKE2 waits in the same ecosystem — without starting from scratch.