K0s, pronounced kzeros, is a fully-fledged open-source Kubernetes distribution developed by team Lens - the Kubernetes IDE project. K0s is highly configurable and flexible to cover various Kubernetes uses like local and private data centers, IoT and public cloud clusters, and hybrid deployments.

K0s is a successor to the Kontena Pharos Kubernetes distribution, aiming to run at any infrastructure in scale. K0s leverages the latest version of upstream Kubernetes just like Pharos to create a more modern, robust, and versatile zero friction Kubernetes distribution.

Zero in K0s has a very special meaning. Zero refers to no compromises or ease of use in terms of installation, dependencies, and downtime.

K0s, at its core, is designed to be the lightest and smallest, which reduces the installation and maintenance complexities of a typical Kubernetes distribution. Users can deploy clusters in minutes requiring minimal resources and zero expertise to get started.

K0s distro is distributed and packaged as a single library, which does not require any host OS dependencies or installation packages besides the kernel to run and operate correctly. Performance issues of any type can be directly resolved in the distribution allowing developers to have complete control over the libraries to make the environment more secure.

K0s also makes it possible to automate cluster lifecycle management for performing cluster upgrades, which decreases the downtime and burden to upgrade clusters while the applications are running.

K0s Features

100 percent Upstream Kubernetes

K0s leverages Upstream Kubernetes, allowing developers to create a distro that can run on any operating system and supports various higher-level services and solutions. K0s is also easier to maintain as all the core upstream Kubernetes components are self-contained, making the execution of modules easier at runtime.

Based on Upstream Kubernetes, K0s has many other advanced features. For instance, support for Role-Based Access Control (RBAC), Open ID is provided out of the box, GPUs, and Horizontal Pod Autoscaling (HPA) is also available. K0s can be installed on both Intel and Arm architectures and can run on any Linux host or Windows Server worker nodes.

Single Binary

K0s is built as a single binary package of size (around 165 Mb), which means all the necessary libraries embed into a single self-extracting archive that is available to execute without any dependencies.

A single binary package of K0s can easily run on any (Linux) OS kernel eliminating the need to use different flavors of packages such as debs, RPMs which are hard to maintain and automate. A single binary package also improves functionality and decreases the hassle of maintaining the setup and packaging for various OS distros.

Being a single binary k0s consists of core components, OS dependencies, and components packaged as a FIPS-compliant distribution for safe use in highly confidential testing environments.

Support for Various container runtime, networking, and storage interfaces

K0s is a swappable Kubernetes distro with support for various Container Runtime (CRI), Container Networking (CNI), and Container Storage Interface (CSI).

By default, k0s implements the containerd runtime that manages the entire container lifecycle. But if your organization uses a particular container runtime to meet its specific needs. K0s includes support for CRI like Mirantis Container Runtime, which is FIPS compliant.

For container networking, K0s uses Calico, but it is easily compatible with other popular CNI providers like Flannel, Canal, and Weave. Developers can also implement container storage by using any CSI storage driver to expose block and file storage systems to containerized applications.

Isolated Control Plane

It is a best practice to build a boundary between the control plane and the worker node to prevent malicious workflows from running on control plane nodes.

By default in k0s, the control plane stays wholly isolated and is not directly a part of the cluster, which decreases the chances of running typical workloads on controller nodes. K0s has no container runtime or kubelet running, creating a direct connection between the control plane and the cluster workers.

Kine for Variety of Data Storage Backends

By default, K0s uses Etcd as a default datastore for Kubernetes API and provides automatic scaling of etcd cluster depending upon the storage needs. However, there are many deployment scenarios where different types of data storing mechanisms are required.

To support various data storage backends with Kubernetes. K0s embeds Kine, which enables MySQL, Postgres, and SQLite to manage and configure cluster data stores. Kine implements an etcd API, which translates etcd calls into the desired API for implementing endless storage architecture variations.

Konnectivity for Control-Plane Node Communication

By default, K0s uses a Konnectivity service responsible for indirect communication between the control plane and worker nodes. A konnectivity service implements reverse tunnels, which provides a TCP level proxy for communication between cluster and control plane.

Konnectivity service divides into two parts: Konnectivity server and agents. Konnectivity agents are responsible for maintaining and initiating connections to the Konnectivity server, whereas the Konnectivity server runs alongside the API-server and proxies call through the bidirectional tunnel. After enabling the Konnectivity service in K0s, all the traffic from the control plane to nodes goes through these connections.

Comparison with k3s

Developed by Rancher Labs, k3s is a highly available and production-ready Kubernetes distro designed for production workflows in resource-constrained Edge, ARM, and IoT environments.

Rancher Labs are already a big player in the Kubernetes arena because of their flagship Kubernetes GUI offering Rancher. With k3s, they have released a complaint distribution that provides various enhancements for Kubernetes.

K3s is a CNCF (Cloud Native Computing Foundation) certified Kubernetes distro, which ensures that every other Kubernetes version supports the required APIs, as do the open-source offerings.

K3s has a very lightweight design with its small binary size. Rancher achieved this by removing a lot of components that can be implemented easily through add-ons.

K3s has very low resource requirements, which means it can be easily run or deployed on a cluster. Both k0s adoption and growth is also happening rapidly, with more than 1700 contributors from its launch in 2019, k3s has become one of the primary options for small footprint Kubernetes.

k3s vs. k0s

Before we start with the comparison, it is important to point out that at the core of K3s and K0s distro is the same upstream, open-source version of Kubernetes. The distributions might have different release periods, but they both leverage the upstream Kubernetes and combine it with other technologies to meet the market’s desired needs.

Both k3s and k0s distros have a simplistic design, packaged and deployed as a single binary. Users might get a lighter version with k3s(50Mb) compared to k0s(~150Mb), but they both can get a fully-fledged Kubernetes cluster running in a fraction of seconds. The installation is also very simple by running scripts on the cluster nodes.

The single binary packages for k0s and k3s are self-contained. They have almost all the necessary components required to run the Kubernetes cluster, including the API server, OS dependencies, and controllers.

By default, k3s and k0s include containerd runtime, which provides enough functionality to manage the pod lifecycle. It is also possible to replace containerd, storage, and networking with various CRI. CSI and CNI providers in both k0s and k3s due to their batteries included but replaceable approach.

Compared to the k0s cluster, there is a distinction between how the control plane and worker nodes communicate in k3s. In a k3s cluster, the controller components run along with the kubelet server in a node. The kubelet server has the container runtime and a proxy that manages the cluster traffic across the network. K0s, on the other hand, does not expose the controller components and make use of the Konnectivity server instead of tunnel proxy to handle the cluster traffic.

A typical k3s environment’s footprint is one-third of K0s(50Mb vs150Mb ) when comparing their binary sizes. K3s has gotten rid of all the unnecessary components that are not needed to run a bare minimum cluster and only added some necessary add-ons, including Traefik ingress controller, Load balancer, and Helm chart out of the box.

K0s does not include any of these add-ons but contains all the upstream Kubernetes libraries like the storage volume plugins and cloud provider APIs as a self-extracting archive, contributing to its larger size.

Both K3s and K0s also use Core DNS and Metrics server. CoreDNS provides an extensible DNS server for Kubernetes to translate domain names into IP addresses. The Metrics server collects resource usage data from API exposed by container runtime on each node.

The other key difference between k0s and k3s is how the cluster states get managed. K0s distribution by default relies on Kine as data store with etcd - the distributed key-value database, whereas k3s has replaced etcd with SQLite.

K0s servers with Kine can easily swap etcd with various other databases like MySQL, Postgres, SQLite, dqlite to enable high availability of the clusters. K0s servers, on the other hand, have to be integrated with supported databases like MySQL and PostgreSQL to support multiple instances and make the cluster highly available.

Which one to choose, k3s or k0s?

If you want a stable production-ready Kubernetes distribution for lightweight environments, we will still recommend k3s. K3s is secure by default for lightweight environments and eliminates the bloatware that comes precluded with upstream Kubernetes. K3s also wraps all the Kubernetes components into a single and simple launcher, which supports various storage backends and requires minimal OS dependencies.

In contrast, if you want a Kubernetes distribution for development or staging cluster, k0s is worth giving a try. Although k0s is a young project and an early release, it is evolving rapidly as a robust and versatile way of running Kubernetes anywhere. For sure, there are some rough edges to fix, like support for add-ons out of the box and large binary size (compared to k3s), but we hope these obstacles get overcome as the project matures.

Comparison Table

	Mirantis K0s	Rancher K3s
Binary Size	~160 mb	~50 mb
Control Plane-Node Communication	Konnectivity	Tunnel Proxy
Datastore	Kine with etcd as default	SQLite
Workloads on Control Plane	No, Control Plane is Isolated	Yes
Cluster DNS and Metrics	Core DNS and Metrics Server	Core DNS and Metric Server
Add-ons	No	Helm, Traefik, and Loadbalancer
Default CNI	Calico	Flannel
OS Dependencies	No OS dependencies	Minimal to no OS dependencies
Supported Architectures	AMD64, ARM64	AMD64, ARM64, ARMHF

Mirantis k0s Future

K0s in the Kubernetes distro market directly competes with k3s from Rancher and microk8s from Canonical. K3s, a CNCF certified project, already has tremendous support from the community and is already a part of various embedded computing organizations from different domains. Microk8s from Canonical has recently added some features to make it more production-ready but compared to k3s; it is not a mature distribution for deployments on a large scale.

K0s has many stand-out features like k3s. For Instance, Kine allows integration of external databases such as MySQL and PostgreSQL, The single binary installation and architecture support is also very similar to k3s. The k0s community is also looking forward to adding support for Microsoft Windows Server 2019-based worker nodes on Linux’s control plane, which allows the running of hybrid workloads.

Mirantis with k0s has blended Pharos and Docker’s best ideas to create a very modern 100% upstream Kubernetes distribution. Mirantis has also acquired Docker Enterprise and Lens project to complete its cloud-native portfolio and compete aggressively in the market.