1. 「K3sは軽い」という前提を、一度疑ってみる
K3sを選ぶ理由として最初に挙がるのは、ほぼ例外なく「軽量だから」だ。公式サイトも「lightweight Kubernetes」を謳い、エッジやIoT、開発環境での採用事例の多くがこの軽さを根拠にしている。
ところが、K3sとKubernetes標準構成（kubeadmで構築するクラスタ）のメモリ使用量を比較した複数の実測データを横断して読むと、話はそれほど単純ではない。測定条件によっては、K3sの方が標準Kubernetesより重いという結果すら報告されている。
本記事では、K3s公式のリソースプロファイリングデータと、独立した第三者のベンチマーク結果を突き合わせ、「K3s vs Kubernetes(kubeadm)」のメモリ・CPU使用量比較を条件別に整理する。K3s/Kubernetesの技術選定に関わるインフラエンジニア・SREが、自分の環境に当てはめて判断できることを目指す（こうした選定・チューニングの負荷そのものを下げたいなら、KuboのようなマネージドK3sという選択肢もある）。
2. K3s公式のリソースプロファイリングを読む
まず一次情報として、K3s公式のResource Profilingドキュメントを確認する。このドキュメントはPrometheusによる定常状態の95パーセンタイル値を測定しており、曖昧な「〜MB程度」ではなく再現可能な数値を提示している点で信頼性が高い。
測定環境はAWS c6id.xlarge（8GB RAM）とRaspberry Pi 4Bの2系統。ワークロードを乗せたサーバーノード単体では、Kine/SQLite構成でIntel環境約1.6GB、Pi4B環境約1.59GB、embedded etcd構成でもほぼ同水準（Intel約1.61GB、Pi4B約1.61GB）という結果だ。一方でエージェントノード単体は両構成ともおよそ275MB前後に収まっている。
つまり公式データが示すのは、データストアの選択（etcd/SQLite）がメモリ使用量そのものを大きく左右するわけではなく、むしろディスクI/Oの要求値（IOPSやレイテンシ）に差が出る、という点だ。この構図は次のセクションでより詳しく見ていく。
3. データストア選択(embedded etcd vs SQLite)が本当に左右するもの
K3sはデフォルトでetcdの代わりにSQLiteを採用しており、この設計がバイナリサイズとシンプルさに大きく寄与している（SUSE/Rancher公式ブログによれば、K3s本体は54MBのシングルバイナリにcontainerd・Flannel・CoreDNS・Traefikまで同梱されている）。
単一ノード環境でのデータストア別オーバーヘッドを検証したBig Ironの比較ガイドによると、SQLite（kine経由）のオーバーヘッドは約50〜80MBとほぼ無視できる水準である一方、embedded etcdはアイドル状態でも300〜500MB、Secret数やCRD数、watch接続数が増えるビジーなクラスタでは1〜2GBに達することがあるという。
この差は、8GB RAM程度の環境では無視できない割合になる。K3s公式のHA構成ドキュメントでも、既存のSQLiteクラスタは--cluster-initフラグでetcdに変換できると説明されており、両者は用途に応じて後から切り替え可能な設計になっている。マルチノードHAを見据えるならetcd、単一ノードやエッジ用途でリソースを切り詰めたいならSQLite、という使い分けが現実的だ。
この「どちらを選ぶか」の判断と初期設定を自分たちで抱え込まず、Kubo CloudのAI-Driven Deploymentに任せるという選択肢もある。構成済みのK3sベース環境を前提に、運用側はアプリケーションの設計に集中できる。
4. 独立ベンチマークでは、むしろK3sの方が重いという結果も出ている
ここからが本題だ。Sidero Labsが公開した独立ベンチマークは、2 vCPU・4096MBのVM上で各ディストリビューションを1時間アイドル状態にし、Prometheus node exporterとGrafanaでメモリ使用量を計測している。
結果は直感に反するものだった。kubeadmを基準とした相対値で見ると、Talos Linuxは7%削減できた一方、K3sはむしろ15%増加。さらにRKE2は150%増、Canonical Kubernetesに至っては201%増という結果だった。同記事はこの増加要因について、embedded etcdサーバーの採用がメモリ使用量を押し上げている可能性を指摘している。
K3s公式のプロファイリング（セクション2）とこの独立ベンチマークの結果が食い違って見えるのは、測定対象が異なるからだ。公式データは「ワークロードを乗せた定常状態の95パーセンタイル」、Sidero Labsの測定は「1時間のアイドル状態」であり、データストア構成（SQLiteかetcdか）も明記されていない。「K3s vs Kubernetes」の軽さ比較は、測定条件を揃えない限り結論が逆転しうる、というのがここでの実務的な教訓だ。
5. 「4倍のRAM差」という数字の正体
「K3sはkubeadmよりメモリが4分の1で済む」という言説もよく見かけるが、これも文脈を正確に見る必要がある。Kubernetes公式のkubeadmインストールガイドは、コントロールプレーン・ワーカーを問わず全マシンに「2GB以上のRAM」「コントロールプレーンは2CPU以上」を最小要件として明記している。
一方、k3s/kubeadm/MicroK8sの公称値を比較した記事が指摘する「4倍のRAM差」は、ワーカー/エージェントノードに限った差だ。K3sのエージェントノードは512MBで動作するのに対し、kubeadmの標準ワーカーは2GBを要求する。しかしコントロールプレーン同士を比べれば、公称値はどちらも2GBで変わらない。同記事はさらに「実運用のkubeadmコントロールプレーンは、公称2GBではなく実際には4〜8GBを使うことが多い」とも補足している。
k3sとkubeadmの実運用環境でのパフォーマンス比較では、4vCPU/8GB RAM環境でのアイドルメモリがK3s約512〜700MB、kubeadm約1.5〜2GBとなり、クラスタの起動時間もK3sが60秒未満、kubeadmが5〜8分と明確な差が出ている。「軽さ」の実感は、起動時間やワーカーノードの最小要件といったどの指標を見るかによって大きく変わるということだ。
6. 結局どちらを選ぶべきか — 判断の軸
ここまでの実測データを踏まえると、判断軸は次のように整理できる。
- 単一ノード・エッジ用途で起動速度とフットプリントを優先するなら: K3s + SQLite構成。エージェントノードは512MB前後で動作し、起動も60秒未満
- マルチノードHAを前提にスケールさせたい、かつメモリに余裕があるなら: K3s + embedded etcd、または標準のetcdクラスタ構成
- 既存のkubeadmベースの運用ノウハウ・ツールチェーンをそのまま活かしたいなら: 無理にK3sへ移行せず、実運用で必要なメモリ（4〜8GB）を見込んだ上でkubeadm構成を継続
実のところ、こうしたデータストア選択・リソース設計のチューニングは、クラスタ運用の中でも地味に工数を食う領域だ。関連して、CI/CDビルドランナー基盤でのK3s選定を扱った過去記事や、クラウド側のコスト構造を比較したこちらの記事も、同じ「K3s vs 標準Kubernetes」という選定軸で書いているので合わせて参考にしてほしい。
マネージドK8sサービスのKuboは、このK3sベースの構成をあらかじめ最適化した状態で提供している。データストアの選定やリソースチューニングに工数をかけず、EKSやAKSの半額近いコストでフルスペックのKubernetesを運用できる点が特徴だ（4vCPU/8GB/40GB×3ノード構成でKubo月額48,000円、AWS EKSは82,700円という比較もある）。
まとめ
「K3sは軽い」という通説は、多くのケースで正しい。だが実測データを横断して見ると、その軽さは測定条件・データストア選択・どのノード種別を見るかに強く依存していることがわかる。独立ベンチマークではK3sがkubeadmより重くなるケースも報告されている以上、「軽いから採用する」という単純な判断ではなく、自分のワークロードに即した計測を一度は行うことをおすすめしたい。
こうした判断や構築・運用の手間を省きたい場合は、Kubo On-PremiseやKuboが提供するマネージドな選択肢も検討してみてほしい。構成の最適化はすでに済んだ状態で、本格的なKubernetesをすぐに使い始められる。気になる方はお問い合わせから相談も可能だ。