k0s: Zero-Friction Kubernetes Distribution

k0s calls itself “Zero Friction Kubernetes,” and the claim is literal: one binary, no host OS dependencies beyond the kernel, no package repository, no external datastore required. It’s a CNCF Sandbox project from Mirantis, Apache 2.0 licensed, and it competes directly with K3s for the same job — Kubernetes that installs without a planning meeting.

What “zero friction” actually buys

The pitch has three parts, and each is checkable:

1. Zero host dependencies. The binary needs only a kernel — it doesn’t link against host libraries or require a pre-installed container runtime. k0s bundles containerd as its default runtime, with BYO runtime supported.
2. Zero cost. Apache 2.0, no feature-gated “community edition,” the full Kubernetes API surface. Enterprise support and the fleet tooling are Mirantis’ commercial layer (MKE 4), not a gate on core functionality.
3. Zero-friction operations. Single binary to upgrade, built-in backup/restore, and a cluster upgrade path that doesn’t require draining your laptop’s patience.

Requirements are modest: Linux kernel ≥ 3.10, x86-64, ARM64, or ARMv7. Windows Server 2019 support exists but is explicitly experimental — fine for a test cluster, not something to bet a production Windows workload on yet.

Install walkthrough

The documented single-controller install on Linux:

curl -sSf https://get.k0s.sh | sudo sh
sudo k0s install controller --single
sudo k0s start
sudo k0s kubectl get nodes

Four commands: fetch the installer, register a controller in single-node mode, start it, and check. k0s kubectl is a bundled kubectl, so you don’t even need one on the box to verify.

--single is the equivalent of K3s’ one-command server: it configures the controller to run an in-cluster datastore instead of requiring you to point at etcd. To add worker nodes later, you generate a join token on the controller and run k0s worker <token> on the joining machine — the same token-based model K3s uses.

For anything beyond one node, you’d normally reach for k0sctl, a CLI that reads a YAML inventory and provisions controllers/workers over SSH:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: edge-fleet
spec:
  hosts:
    - role: controller
      ssh:
        address: 10.0.0.10
    - role: worker
      ssh:
        address: 10.0.0.11
    - role: worker
      ssh:
        address: 10.0.0.12

k0sctl apply -c k0s.yaml takes it from there, and the same tool handles zero-downtime cluster upgrades later.

Datastore options

The datastore choice follows cluster size, same as K3s but with etcd as the in-cluster default for multi-node:

Topology	k0s default
Single controller	In-cluster SQLite
Multi controller	In-cluster elastic etcd with TLS
External	PostgreSQL or MySQL

The wording matters: “in-cluster elastic etcd” means k0s runs etcd as part of the cluster and expands it as controllers join — versus K3s, where embedded etcd requires explicitly opting in with --cluster-init at creation. External PostgreSQL/MySQL is there for teams whose DBA story already exists.

CNI: the visible difference from K3s

k0s defaults to kube-router, providing pod networking, network policy, and service load balancing in one component. Calico is the documented alternative, and switching is a configuration choice rather than a reinstall.

This is the philosophical split between the two distributions: K3s ships flannel + Traefik and calls the opinionated bundle a feature; k0s ships a smaller default set and leaves more of the stack to you. Neither is wrong — it changes how much day-one configuration you write versus how much you override.

Built-ins

k0s bundles a substantial list out of the box:

• containerd as the default runtime (bring your own if you want)
• CoreDNS and metrics-server
• HPA and GPU support
• Network policies and RBAC, plus OIDC support for API authentication
• Cluster backup/restore as a first-class command
• kube-bench for CIS-style benchmarking against your own cluster
• Zero-downtime upgrades via k0sctl

The combination of kube-bench and OIDC in the default feature set tells you who k0s is aimed at: teams running clusters that will be audited, not just demos.

The fleet story: k0smotron and k0rdent

This is where k0s diverges most sharply from K3s. Mirantis built a management layer around the distribution:

• k0smotron — a Cluster API provider for k0s. You declare K0sControlPlane and K0sWorkerPool resources and Cluster API reconciles k0s clusters as Kubernetes objects, including control planes running inside an existing cluster as pods. That makes child clusters cheap: a test control plane is a pod, not three VMs.
• k0rdent — a declarative multi-cloud/edge fleet manager built on those primitives. One desired-state document, many clusters across clouds and sites, drift reconciled the same way Kubernetes reconciles anything else.

If you intend to run ten clusters rather than one, this is k0s’ strongest argument: the distribution is the commodity, the fleet control plane is the product. K3s/SUSE answer with Rancher; k0s answers with Cluster API-native tooling.

Choosing

Pick k0s when you want fewer baked-in opinions (CNI, ingress, storage are more yours to choose), when Cluster API-based fleet management is on your roadmap, or when zero host dependencies matters on odd base images. Pick K3s when the all-in-one bundle — flannel, Traefik, local-path, one command to a fully-loaded cluster — matches what you’d have assembled anyway, or when you’re already in the SUSE/Rancher world.

Both are CNCF Sandbox projects that ship certified Kubernetes as a single binary. The real difference isn’t the download; it’s how much of the stack each one decides for you, and what happens at cluster number ten.

Further reading

• k0s — official site
• k0s documentation