ステータス：ドラフト（2026-10-13）、公式ドキュメント・リリース情報基準 ＋ 一部実測。 サイズはGitHubリリースのファイル情報（2026-10-13取得）、要件は公式ドキュメント（2026-10-13閲覧）、準備時間はTT Labの実習VMの実測値です。 3つのディストリビューションのメモリ使用量を同一条件で測定した値はありません（未測定）。 決定フローは上記の内容に基づく筆者の判断です。 作成ルール：実測データが基本であり、測定できなかったものは「未測定」、ドキュメントから見つからなかったものは「未確認」と表示します。
目次
1. リソース：何を測定し、何を測定できなかったか
「k3sは軽い」という言葉はよく耳にしますが、どの数値を指しているのかを区別する必要があります。バイナリサイズ、転送すべきイメージの量、ドキュメントが要求する最小メモリ、実際に使用するメモリは、すべて異なる数値です。
ダウンロードサイズ（GitHubリリースファイル情報、amd64）
| k3s v1.37.1+k3s1 | RKE2 v1.37.1+rke2r1 | k0s v1.36.4+k0s.1 | |
|---|---|---|---|
| バイナリ | 77.8 MiB | 137.1 MiB（tar.gzで41.1 MiB） | 251.1 MiB |
| バイナリに含まれるもの | すべて（containerdを含む） | 監督プロセスのみ、残りはイメージ | すべて（etcdを含む） |
| エアギャップイメージバンドル | 185.4 MiB（zst） | コア 558.8 MiB + canal 227.7 MiB（zst）、全体バンドルは 787.1 MiB | 402.4 MiB |
ファイルをダウンロードせず、GitHub APIのリリースファイル情報（サイズ）のみを読み取った値です（2026-10-13）。バイナリだけで比較するとk3sが最も小さく、k0sが最も大きくなります。しかし、RKE2のバイナリは監督のみを行い、残りをイメージとして受け取るため、 エアギャップでの転送量で見るとRKE2が最も重くなります。
ドキュメントの表記はそれぞれ異なります。docs.k3s.ioとREADMEではk3sバイナリを100MB未満、k3s.ioホームページでは70MB未満と記載しています。実際のv1.37.1ファイルは77.8 MiB（81.5MB）であり、前者の表記と一致します。RKE2とk0sにはドキュメントにサイズ数値がありませんでした（未確認）。
TT Labの実習VMで直接確認したサイズもあります。k0sバイナリは251MBであり（実測、2026-08、上記のリリース情報と同じサイズ）、RKE2 v1.36.4のインストールスクリプトが展開したインストール物は128Mでした（実測）。k3sは実習でサイズを個別に記録していませんでした（未測定）。
ドキュメントが要求する最小スペック（公式ドキュメント基準、未測定）
| k3s | RKE2 | k0s | |
|---|---|---|---|
| サーバー（コントローラー） | 2コア・2GB | 2コア・4GB（推奨4コア・8GB） | 1 vCPU・1GB |
| エージェント（ワーカー） | 1コア・512MB | サーバーとは別に記載なし | 1 vCPU・0.5GB |
| 1つのノードに両方 | — | — | 1 vCPU・1GB |
| ディスク | SSD推奨、数値なし | SSD推奨、数値なし | コントローラー約0.5GB、ワーカー約1.3GB、両方で約1.7GB使用 |
ワークロードにかかるリソースはすべて除外された値です。k0sが最も小さく見えるのは、コントローラーにkubeletとランタイムがないためでもあります。同じ役割同士で比較してこそ公平です。
公式の測定値を公開しているのはk3sのみです。k3sドキュメントのリソースプロファイリング（v1.26.5、パッケージコンポーネントすべて + Prometheus・Grafana + サンプルアプリ、正常状態の95パーセンタイル）によると、x86 4コアサーバーでエージェントが1台接続されたクラスターのサーバーが1,428M（SQLite）・1,450M（etcd）、エージェントが275Mでした。監視ツールまで導入した条件であるため、「k3s独自のメモリ」として読み取ってはいけません。RKE2はノードサイズの案内（2コア・4GBサーバーがエージェント225台まで、v1.27.4基準）はあるものの、アイドル時の使用量はなく、k0sも測定値はありませんでした。
実測：準備時間
| k3s | k0s | RKE2 | |
|---|---|---|---|
| VMを作成し、ノードがReadyになるまで | 82秒（Traefik無効） | 約150秒 | 記録なし（未測定） |
| インストールスクリプト → ノードReady | インストール8秒・Ready 11秒（v1.35.8） | 記録なし | 記録なし |
TT LabのVM実習の準備時間です。前の行はVMの起動とインターネットからのダウンロード時間を含んでいるため、ディストリビューション自体の速度というよりは「1つの実習を開くまでの」体感時間です。k0sはetcdを使用する --enable-worker 構成であるため、SQLiteで起動するk3sとは条件が同じではありません。
3つのディストリビューションを同一条件で測定するには
メモリとディスクを同一条件で比較した実測値はまだありません。測定するには、同じサイズのVM 3台に3つのディストリビューションをそれぞれデフォルト値で構築し、アイドル状態でサービスcgroupのメモリとディスク使用量を数回測定して中央値を使用する必要があります。この際、バイナリとイメージ（上記の表のサイズ分）を再度ダウンロードする必要があるため、次のバージョンで実測値に変更する予定です。
2. 状況別に見る
| 状況 | 最初に確認するもの | 理由 |
|---|---|---|
| エッジ・IoT・ARMボード、単一ノード | k3s | バイナリが最も小さく、エージェント最小512MB、SQLiteによりetcdなしで開始 |
| 開発用PC、CI用の使い捨てクラスター | k3s | インストール直後にイングレス・LB・ストレージがすべて揃っており、すぐに使える |
| 規制産業（公共・金融）、監査対応 | RKE2 | profile: cis、FIPS 140-2ビルド、SELinuxポリシー |
| 最初からetcdを使用し、kubeadmに似た構成 | RKE2 | 静的ポッドのためkubeadmの経験がそのまま通用する |
| 1つのバイナリで運用し、構成は自分で選ぶ | k0s | デフォルトが空であり、コントローラーがワークロードと分離されている |
| 複数のホストを1つの設定ファイルで | k0s | k0sctlがSSHでインストール・参加を行い、autopilotがアップグレードを行う |
| Rancherで複数のクラスターを1つの画面で管理 | k3sまたはRKE2 | Rancherが両方をプロビジョニングおよび管理する |
| CKAの勉強、標準をそのまま学ぶ | kubeadm | 試験で問われる静的ポッドやetcdのバックアップがそのまま通用する |
最後の行はこの記事の3つではありませんが、よくある質問のため追加しました。k3sはデフォルトのストレージがSQLiteであり、コントロールプレーンが1つのプロセスであるため、試験で問われる「etcdのバックアップ」や「静的ポッドの修正」がそのまま通用しません。
3. 決定フロー
質問の順番が重要です。 変更しにくい条件から 尋ねます。コンプライアンスは交渉できませんし、ハードウェアは新しく購入しなければ変わりません。一方、「構成を自分で選びたい」というのは好みであるため、k3sでも --disable でデフォルトのコンポーネントを無効化し、希望のものを導入することで大部分に対応できます。
このフローは筆者の整理によるものです。チームがすでに特定のディストリビューションに慣れている場合、その経験の方が上記の差異よりも重要である場合があります。
4. 移行時の課題
例えば、開発にはk3sを、本番環境にはRKE2を分けて使用する場合、同じマニフェストが両方のディストリビューションを行き来する必要があります。この際に直面しやすい課題が4つあります。1番と4番は実習で直接経験したものであり、2番と3番はデフォルト値の表（パート1のセクション5）に現れる差異です。
- 帯域。 k3s・RKE2は10.42/10.43、k0sは10.244/10.96です。ネスト環境や社内ネットワークと重複していないかを最初に見積もります（パート1のセクション6）。
- イングレスクラス。 k3sはTraefik、RKE2は作成されたバージョンに応じてTraefikまたはingress-nginx、k0sはなしです。アノテーションがコントローラーごとに異なるため、マニフェストでGateway APIやクラスター名を値として受け取れるようにしておくと、移行コストが削減されます。
- ストレージクラス。 k3sの
local-pathはRKE2・k0sにはありません。マニフェストに名前をハードコーディングすると、PVCがPendingの状態で停止します。 - ポッドセキュリティ。 k3s・k0sのデフォルトで起動していた特権ポッドが、cisプロファイルのRKE2では拒否されます。ただし、すでに起動しているポッドは実行続けられるため、次回のデプロイ時に初めて表面化します（パート2のセクション3）。
5. TT Labでは
TT Labの実習サービス自体は、kubeadmで構築したKubernetes（v1.34系）上で稼働しています。そして、コースのVM実習内でk3s、k0s、RKE2を直接構築します。このシリーズの「実測値」はすべてその実習VMから得られたものです。
同じ内容をご自身で試してみたい場合は、TT Labの 「Kubernetesディストリビューション — ゼロからの構築」 コースを探してみてください（サイトのコース一覧から「ディストリビューション」で検索）。この記事に関連するモジュールは以下の通りです。
- 「k0sによる構築と復旧」：etcdのバックアップ → 変更 → 復旧の一連の流れを実践し、復元によって何が元に戻るのかを確認します。
- 「k3sのストレージとスナップショット」：SQLiteから組み込みetcdへ移行し、スナップショットから復元します。
- 「k3sのデフォルトコンポーネント」：削除したTraefikがなぜ復活するのか、
--disable·.skipとHelmChartConfigの違いを確認します。 - 「アップグレードとバージョンの違い」：インストールスクリプトで1段階上げ、system-upgrade-controller Planを使用します。
- 「k0sの構成と動的構成」：設定ファイルとClusterConfigオブジェクトのどちらが真実であるかを確認します。
- 「RKE2とCISプロファイル」：パート2の実測シーンをそのまま体験します。
ティティの一言。 軽いからといって常にk3s、安全だからといって常にRKE2とは限りません。「後から変更するのが一番難しいのは何か？」から問いかけると、すぐに答えが出ます。また、数値を見る時はそれがバイナリサイズなのか、最小スペックなのか、実際に測定されたメモリなのかを必ず確認してください。
参考
すべての資料は2026-10-13に閲覧・取得しました。
- リリースファイル情報（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：要件 https://docs.k3s.io/installation/requirements、リソースプロファイリング https://docs.k3s.io/reference/resource-profiling、ドキュメントのトップページ https://docs.k3s.io/、ホームページ https://k3s.io/
- RKE2：要件 https://docs.rke2.io/install/requirements
- k0s：システム要件 https://docs.k0sproject.io/stable/system-requirements/、k0sctl https://docs.k0sproject.io/stable/k0sctl-install/
- Rancherでのクラスター作成： https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher
- 実測: TT Lab 「Kubernetesディストリビューション — 自前で構築する」コースの実習VM記録（準備時間、k0sバイナリ、RKE2インストール物、2026年8〜9月）