k0s: a single-binary Kubernetes distribution for small nodes and airgapped racks

The gap k0s is trying to close between the host OS and Kubernetes

The project's own motivation section states the problem plainly: there is a gap between the host OS and the Kubernetes running on top of it, and it is unclear who owns vulnerabilities or performance issues that originate in the host and affect the cluster. k0s answers that by being fully self contained. It ships as a single binary with no host OS dependencies besides the kernel, so a fix for a vulnerability or a performance problem can land in the k0s distribution itself rather than waiting on a distribution package maintainer.

The audience follows from that. The README lists any cloud, bare metal, and edge and IoT as the target environments, and names modest system requirements of 1 vCPU and 1 GB RAM. That is a small machine. It is the kind of node you find in a retail back office, a factory floor or a lab, where nobody wants to run a package manager to keep a control plane alive. The README also claims that anyone with no special Kubernetes expertise can get started, which is a marketing claim rather than a verified property, but it does describe the intended user accurately: someone who wants a working cluster, not a control plane they tune.

One binary, embedded components, and a datastore you choose

The repository layout tells you most of the architecture. The top level contains main.go, cmd/, pkg/, internal/ and an embedded-bins/ directory. Embedded binaries are how a distribution this size stays self contained: the Kubernetes control plane components are built into the k0s binary rather than pulled from the host. The Dockerfile confirms the shape of a running controller. It adds iptables and tini, creates system users for etcd, kube-apiserver, kube-scheduler and konnectivity-server, and sets the default command to run a controller with a worker enabled in the same process. That is the single-node topology in one line.

Storage is configurable. The README documents four datastore backends under spec.storage: etcd, which is the default for multi-node clusters, SQLite, which is the default for single node clusters, MySQL and PostgreSQL. Networking defaults to Kube-Router with Calico offered as a preconfigured alternative, and the CRI defaults to containerd. Control plane isolation is described as the default, with a dedicated networking page covering controller-worker communication, and Konnectivity, CoreDNS and Metrics Server are included rather than left to you.

The practical consequence is that a k0s cluster is not assembled from parts you chose. It is a fixed set of components with a few documented swap points. That is the design, not an accident.

Installing k0s and getting a first cluster up

The README points to the Quick Start Guide at docs.k0sproject.io for a single node that acts as both controller and worker, and to the k0sctl install page for multi-node clusters. The binary is distributed from the project's GitHub releases, which is what the download badge in the README links to. The commands below follow the pattern the documentation describes: obtain the binary, install it as a service, then start the controller with a worker on the same machine.

First, download the binary for your architecture from the releases page and make it executable. The README lists x86-64, ARM64, ARMv7 and RISC-V as supported architectures, so pick the matching asset.

curl -sSLf https://github.com/k0sproject/k0s/releases/latest/download/k0s -o k0s
chmod +x k0s
sudo mv k0s /usr/local/bin/k0s

Next, install k0s as a system service. This writes the service unit and prepares the data directory under /var/lib/k0s.

sudo k0s install controller --enable-worker

Then start it and check that the control plane came up. The first start generates certificates and writes the admin kubeconfig to /var/lib/k0s/pki/admin.conf, which is also the KUBECONFIG value the Dockerfile sets for containerised runs.

sudo k0s start
sudo k0s status
sudo k0s kubeconfig admin > ~/.kube/config
kubectl get nodes

The node should appear as Ready once the embedded components finish starting. If you would rather run k0s in a container, the Dockerfile's default command is k0s controller --enable-worker, and the entrypoint is /entrypoint.sh under tini, so a plain docker run against the published image gives you the same single-node shape.

Where k0s stops being the right tool

The self-contained design is also the constraint. Because the components are embedded, you cannot upgrade the Kubernetes control plane independently of the k0s release that carries it. The release naming makes this explicit: versions such as v1.36.4+k0s.1 tie an upstream Kubernetes version to a k0s build number, so a cluster upgrade is a k0s upgrade. Teams that track upstream patch releases on their own schedule will find that cadence imposed on them.

The default datastore for a single node is SQLite. That is convenient and it is not an HA datastore. If you later want a highly available control plane, the README points to the high-availability documentation and the multi-node default of etcd, which means a migration rather than a config flag. Similarly, Kube-Router is the default CNI and Calico is the preconfigured alternative; the README does not present arbitrary CNI substitution as a supported path, and the same holds for the CRI, where containerd is the default.

Finally, the README does not document rollback for a failed upgrade. The upgrade and backup pages are linked from the feature list, but the README itself is silent on what happens when an upgrade does not complete. Treat that as something to confirm in the upgrade documentation before you touch a production cluster.

k0s compared with k3s and microk8s

The comparison people actually search for is k0s vs k3s and k0s vs microk8s, and the difference is in packaging philosophy rather than feature lists. k0s is distributed as a single binary with no host OS dependencies besides the kernel, and the README frames this as the answer to the host-OS-versus-Kubernetes gap: vulnerabilities and performance issues can be fixed in the k0s distribution itself. That is a statement about where the maintenance burden sits.

microk8s is distributed as a snap, which means the host package manager is part of the install and upgrade path. That is a real convenience on a supported Ubuntu host and a real friction point on a distribution where snapd is not present or not wanted. k3s is also a single-binary distribution, but the README's framing of k0s is about being 100 percent upstream Kubernetes with a fixed set of embedded components and a choice of four datastore backends, including MySQL and PostgreSQL alongside etcd and SQLite. If your organisation already runs MySQL or PostgreSQL and does not want to operate etcd, that choice is the concrete difference worth weighing.

None of this makes one distribution better in the abstract. It makes them differently opinionated about which parts of the stack you are allowed to own.

Maintenance, upgrades and what the licence metadata does not say

The repository is not archived, and the last push was on 2026-09-21, the day before this was written. Three releases landed on 2026-09-19: v1.36.4+k0s.1, v1.35.8+k0s.1 and v1.34.11+k0s.1. Those three version lines being maintained in parallel is the useful signal here, because it tells you the project keeps older Kubernetes minors alive rather than forcing everything onto the newest one. If you run a cluster on 1.34, you are not immediately stranded.

The upgrade path runs through k0sctl, which the README lists under automatic lifecycle management alongside backup and restore. The cost of an upgrade is therefore mostly the cost of validating that your workloads survive a control plane restart, plus whatever the embedded component versions changed. Because the components ship inside the binary, there is no separate step where you update kube-apiserver or etcd on the host. That removes a class of drift, and it also removes your ability to patch one component ahead of the rest.

On licensing, the repository metadata reports NOASSERTION rather than a recognised SPDX identifier. The README's own header carries SPDX-FileCopyrightText and SPDX-License-Identifier lines for individual files, and there is a LICENSE file at the top level, but the machine-readable licence field does not resolve to a standard identifier. Anyone embedding k0s in a commercial product should read that LICENSE file directly rather than relying on the repository metadata. That is not legal advice, it is a pointer to the file that actually governs.

What to verify before you commit to k0s

Start with the datastore decision, because it is the one that is expensive to reverse. A single node defaults to SQLite; a multi-node cluster defaults to etcd. If you expect to grow from one node to three, decide now whether you want to run etcd or point k0s at MySQL or PostgreSQL, and read the configuration documentation for spec.storage before you build anything.

Second, check the system requirements page against your actual hardware. The README quotes 1 vCPU and 1 GB RAM, which is the floor, not a recommendation for a cluster running real workloads. Third, confirm your architecture is covered: x86-64, ARM64, ARMv7 and RISC-V are listed, and the Makefile's host detection treats anything unrecognised as amd64, which is a build convenience rather than a statement about your target machine.

If you are running airgapped, the README links a dedicated airgap install page, and that is the path to follow rather than adapting the online instructions. The NanoDemo recording on the docs site is the fastest way to see the shape of a first run before you install anything.

Editorial conclusion

Adopt k0s when you need a certified Kubernetes control plane on a single small node, on bare metal you do not want to configure, or in an airgapped network, and when the default Kube-Router CNI and containerd runtime are acceptable. Do not adopt it if you depend on host packages, a specific CNI or CRI outside the preconfigured options, or a managed control plane. Before rolling it out, verify which datastore your topology needs (SQLite is the single-node default, etcd the multi-node default), check the system requirements page for your target architecture, and confirm the licence text in the repository's LICENSE file, since the metadata does not declare a standard SPDX identifier.

Frequently asked questions

Official sources

1. Issues
2. k0sproject/k0s on GitHub
3. Project website
4. README
5. Releases