Which to Choose Among k3s, RKE2, and k0s: Resource Numbers, Scenario-based Tables, and Decision Flow

Status: Draft (2026-10-13), based on official documentation and release information + partial measurements. Sizes are based on GitHub release file information (retrieved 2026-10-13), requirements are from official documentation (accessed 2026-10-13), and preparation times are measured on TT Lab practice VMs. There are no measurements of the memory usage of all three distributions under the same conditions (unmeasured). The decision flow represents the author's judgment based on the above facts. Writing rules: Measured data is the default, unmeasurable items are marked as "Unmeasured", and items not found in documentation are marked as "Unverified".

Table of Contents

• 1. Resources: What Was Measured and What Was Not
  • Download Size (GitHub Release File Information, amd64)
  • Minimum Specs Required by Documentation (Official Docs, Unmeasured)
  • Actual Measurement: Preparation Time
  • How to Measure All Three Distributions Under Identical Conditions
• 2. By Scenario
• 3. Decision Flow
• 4. Migration Bottlenecks
• 5. In TT Lab
• References

1. Resources: What Was Measured and What Was Not

While we often hear that "k3s is lightweight," we must distinguish which numbers are being referred to. Binary size, the amount of images to transfer, minimum memory required by documentation, and actual memory consumption are all different numbers.

Download Size (GitHub Release File Information, amd64)

These values were read directly from the GitHub API release file information (sizes) without downloading the files (2026-10-13). Comparing binaries alone, k3s is the smallest and k0s is the largest. However, because the RKE2 binary only acts as a supervisor and pulls the rest as images, looking at the amount to transfer for air-gapping, RKE2 is actually the heaviest.

Documentation descriptions vary. docs.k3s.io and the README state that the k3s binary is under 100MB, while the k3s.io homepage says under 70MB. The actual v1.37.1 file is 77.8 MiB (81.5MB), which matches the former description. RKE2 and k0s had no size figures in their documentation (Unverified).

There are also sizes observed directly on TT Lab practice VMs. The k0s binary was 251MB (measured, 2026-08, same size as release info above), and the extracted installation output from the RKE2 v1.36.4 installation script was 128M (measured). k3s size was not separately recorded during practices (Unmeasured).

Minimum Specs Required by Documentation (Official Docs, Unmeasured)

These values completely omit resources consumed by workloads. The reason k0s appears the smallest is partly because its controller lacks kubelet and a runtime. A fair comparison requires comparing equivalent roles.

Only k3s has provided official measurements. According to the resource profiling in the k3s documentation (v1.26.5, all package components + Prometheus · Grafana + sample app, 95th percentile in steady state), a server in a cluster with an agent attached on an x86 4-core server used 1,428M (SQLite) · 1,450M (etcd), and the agent used 275M. Because monitoring tools were included, this should not be read solely as "k3s memory." RKE2 provides node sizing guidelines (a 2-core · 4GB server supports up to 225 agents, as of v1.27.4) but no idle usage figures, and k0s also lacks measurement values.

Actual Measurement: Preparation Time

These are VM practice preparation times in TT Lab. Since the top row includes VM boot time and internet download time, it reflects the perceived time "until opening a practice session" rather than the speed of the distribution itself. Because k0s uses an etcd --enable-worker configuration, its conditions are not identical to k3s running on SQLite.

How to Measure All Three Distributions Under Identical Conditions

There are as yet no measurements comparing memory and disk under identical conditions. To measure them properly, we need to set up the three distributions with default settings on three VMs of identical size, measure the memory and disk usage of the service cgroups a few times in an idle state, and use the median values. Since this requires freshly downloading binaries and images (equal to the sizes in the table above), we plan to replace this with actual measurements in the next edition.

2. By Scenario

The last row is not among the three in this article, but is included because it is a frequently asked question. Since k3s uses SQLite as its default storage and runs the control plane as a single process, exam questions regarding "etcd backup" and "fixing static pods" do not apply directly.

3. Decision Flow

The order of questions matters. Start with conditions that are difficult to change. Compliance cannot be negotiated, and hardware must be newly purchased to be changed. On the other hand, wanting to "handpick configurations" is a preference, and you can largely accommodate it in k3s as well by using --disable to disable default components and install what you want.

This flow is the author's synthesis. If your team is already familiar with a particular distribution, that experience may outweigh the differences above.

4. Migration Bottlenecks

For example, if you use k3s for development and RKE2 for production, the same manifests must travel back and forth between the two distributions. Four things frequently cause friction here. Items 1 and 4 were experienced firsthand during practices, while items 2 and 3 stem from differences found in the default settings table (Part 1, Section 5).

1. CIDR blocks. k3s and RKE2 use 10.42/10.43, while k0s uses 10.244/10.96. Check first if they overlap with overlay environments or internal corporate networks (Part 1, Section 6).
2. Ingress classes. k3s uses Traefik, RKE2 uses Traefik or ingress-nginx depending on the build version, and k0s has none. Because annotations differ per controller, designing manifests to accept Gateway API or class names as values reduces migration costs.
3. Storage classes. k3s's local-path does not exist in RKE2 or k0s. Hardcoding names in manifests will leave PVCs stuck in Pending.
4. Pod security. Privileged pods that run under k3s and k0s defaults are rejected under the CIS profile in RKE2. However, since already running pods continue to run, this is only revealed during the next deployment (Part 2, Section 3).

5. In TT Lab

TT Lab's practice service itself runs on Kubernetes (v1.34 series) built with kubeadm. Furthermore, k3s, k0s, and RKE2 are built directly inside the course's VM practices. All "actual measurements" in this series came from those practice VMs.

If you want to try the same thing hands-on, check out TT Lab's "Kubernetes Distributions — Building from Scratch" course (search for "Distributions" in the site's course list). The modules intersecting with this article are as follows.

• "Building and Recovering with k0s": Go through a full cycle of etcd backup → modification → recovery, and verify what restoration actually rolls back.
• "k3s Storage and Snapshots": Migrate from SQLite to embedded etcd and restore using snapshots.
• "k3s Default Components": See why deleted Traefik returns, and examine the differences in --disable·.skip·HelmChartConfig.
• "Upgrades and Version Differences": Bump up a version using installation scripts and use the system-upgrade-controller Plan.
• "k0s Configuration and Dynamic Configuration": Verify whether the configuration file or the ClusterConfig object is the source of truth.
• "RKE2 and CIS Profiles": Experience the measurement scenes from Part 2 firsthand.

Titi's Note. Light isn't always k3s, and secure isn't always RKE2. Asking "What is the hardest thing to change later?" yields answers much faster. And when looking at numbers, always verify whether they are binary sizes, minimum specs, or genuinely measured memory.

References

All materials were accessed and retrieved on 2026-10-13.

• Release File Information (GitHub API): https://api.github.com/repos/k3s-io/k3s/releases/latest, https://api.github.com/repos/rancher/rke2/releases/latest, https://api.github.com/repos/k0sproject/k0s/releases/latest
• k3s: Requirements https://docs.k3s.io/installation/requirements, Resource Profiling https://docs.k3s.io/reference/resource-profiling, Documentation Landing Page https://docs.k3s.io/, Homepage https://k3s.io/
• RKE2: Requirements https://docs.rke2.io/install/requirements
• k0s: System Requirements https://docs.k0sproject.io/stable/system-requirements/, k0sctl https://docs.k0sproject.io/stable/k0sctl-install/
• Creating Clusters with Rancher: https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher
• Measurement: TT Lab "Kubernetes Distribution — Build It Yourself" course practice VM logs (preparation time, k0s binary, RKE2 installation artifacts, August–September 2026)