What is k3s, and how is it different from Kubernetes?
k3s is a lightweight Kubernetes distribution that packages the control plane, the kubelet and a set of default add-ons into a single binary of less than 100 MB. It is fully conformant Kubernetes, so “k3s vs k8s” is not a choice between two different systems: the same manifests, Helm charts and kubectl commands work on both. What k3s changes is the packaging, the defaults and the resource footprint, which make it a common choice for edge sites, small clusters, CI and ARM boards.
What k3s changes compared with upstream Kubernetes
Upstream Kubernetes ships separate binaries for each component and leaves networking, storage and the datastore to you. k3s makes those choices and bundles them. According to the k3s documentation and its README, k3s:
- Runs as one process. The API server, scheduler, controller manager and kubelet run inside a single binary and process, with a launcher that generates TLS certificates and handles configuration.
- Swaps the default datastore. A single server uses SQLite by default. For several servers, k3s offers embedded etcd for high availability, or an external etcd, MySQL, MariaDB or PostgreSQL database. SQL backends work through kine, a shim that translates the etcd API into SQL. See the datastore options.
- Removes in-tree drivers. In-tree cloud providers and in-tree storage drivers are left out. External cloud controller managers and CSI drivers replace them.
- Bundles add-ons. containerd, Flannel for Pod networking, the kube-router network policy controller, CoreDNS, Traefik as the ingress controller, ServiceLB for LoadBalancer Services and the local-path provisioner for storage. Each one can be turned off and replaced.
k3s was created at Rancher Labs and has been a CNCF Sandbox project since August 2020.
Resource requirements
The k3s requirements page lists these minimums:
| Node role | CPU | Memory |
|---|---|---|
| Server (control plane) | 2 cores | 2 GB |
| Agent (worker) | 1 core | 512 MB |
k3s runs on x86_64, arm64 and armhf, and the docs recommend SSDs for servers because the datastore is sensitive to disk latency. A server with 2 CPUs and 4 GB of memory is sized for up to 350 agents. Those numbers cover k3s itself, so add the memory and CPU your workloads need.
Where k3s fits
- Edge and retail sites, where each location has one to three small machines and no on-site operations staff. See edge Kubernetes.
- ARM single-board computers and IoT gateways, where full upstream components would use too much memory.
- CI pipelines and local development, where a cluster has to start in seconds and be thrown away after a test run.
- Small production clusters on a handful of virtual machines or bare-metal servers, for example on Hetzner. Our Hetzner Kubernetes guide compares k3s with other options there.
- Air-gapped environments, because one binary and a set of images are easy to move across a network boundary.
k3s compared with RKE2, k0s and MicroK8s
| Distribution | Focus | Notable defaults |
|---|---|---|
| k3s | Smallest footprint, simple install | SQLite or embedded etcd, Flannel, Traefik, ServiceLB |
| RKE2 | Security and compliance | Control plane as static Pods, CIS benchmark defaults, FIPS 140-2 builds |
| k0s | Single binary, control plane isolated from workloads by default | kube-router CNI, SQLite or etcd |
| MicroK8s | Snap package, add-ons switched on with commands | Dqlite datastore for high availability |
RKE2 is the usual alternative when security matters more than size. It comes from the same project family and inherits the k3s deployment model, but ships defaults that help a cluster pass the CIS Kubernetes Benchmark and Go builds that use a FIPS 140-2 validated crypto module. Teams in government and regulated sectors pick RKE2 for that reason. For a broader view of how packaged Kubernetes options differ, see what a Kubernetes distribution is.
Is k3s production ready?
Yes, for the workloads it is designed for. Conformance means applications behave the same as on any other certified cluster. The production questions are operational rather than about k3s itself. With k3s, you still operate:
- High availability. A single server with SQLite is a single point of failure. Production setups run three servers with embedded etcd, or an external database.
- Upgrades. You move the cluster through every minor version yourself, either by replacing the binary or with the system upgrade controller. See how to upgrade a Kubernetes cluster.
- Backups. etcd snapshots or database backups, stored off the cluster and tested by restoring them.
- The operating system. Kernel patches, OS upgrades and node reboots stay with you.
- Monitoring, certificates and access control for the control plane.
A small cluster stays small in hardware, not in responsibility. Three servers and a few agents still need the same upgrade, backup and patching routine as a larger cluster.
Cloudfleet and k3s
Cloudfleet Kubernetes Engine (CFKE) is a managed alternative to running k3s yourself: Cloudfleet operates the control plane, and your machines join the cluster as nodes. Self-managed nodes can be any Linux server running Ubuntu, Debian or the RHEL family, in a cloud or on your own hardware. See self-managed nodes.