なぜ「軽さ」だけでK3sを選ぶと痛い目を見るのか
K3sエッジ運用を検討するとき、最初に語られる理由はほぼ決まって「軽いから」だ。実際、K3sはKubernetesの全機能を単一バイナリに凝縮しており、サーバーノードはCPU 2コア・メモリ2GB、エージェントノードに至ってはCPU 1コア・メモリ512MBという最小要件で動作する（K3s公式ドキュメント）。バイナリサイズもわずか40MB程度に抑えられており、x86_64だけでなくARM64・ARMv7にも対応するため、産業用ゲートウェイやRaspberry Pi級のデバイスでも動作する（Publickey）。
この軽さは2020年8月にCNCFのサンドボックスプロジェクトとして採用されたことでも裏付けられており、現在も活発に開発が続くCNCFプロジェクトの一つとして位置づけられている（CNCF Projects: K3s）。SUSE（Rancherの開発元）も、K3sが512MBのRAMと単一CPUコアで動作できる点、単一コマンドでクラスタをセットアップできる点を、標準Kubernetesとの決定的な違いとして挙げている（SUSE公式ブログ）。
しかし、数千台規模のデバイスを実際に本番運用してみると、「軽い」という一言では説明のつかない設計判断が次々と現れてくる。ある大規模IoT運用の事例では、2000台を超えるエッジデバイス群をK3sクラスタとして統合管理する中で、選定理由として単一バイナリ・省メモリ・ARM対応の3点を挙げつつも、実際の運用フェーズで想定外のコストに直面したという報告がある。そのコストとは、CPUでもメモリでもなく「ネットワーク回線」だった。
KuboのようなK3sベースのマネージドサービスを検討する際も、この「軽さの先にある設計判断」まで踏み込んで比較検討する価値がある。
クラウドとエッジをまたぐ「ハイブリッドクラスタ」という設計
大規模エッジ運用でよく採用されるのが、コントロールプレーンをクラウド側のマネージドKubernetesサービスに置き、現場に分散する各デバイスをK3sのワーカーノードとしてそのクラスタに参加させる「ハイブリッドクラスタ」構成だ。この設計は、Rancher（SUSE）が推奨する「Hub & Spoke」アーキテクチャとも通じ、公式ドキュメントは管理系クラスタとダウンストリームのユーザークラスタを分離すべきだと明記している（Rancher公式: Architecture Recommendations）。
この構成のメリットは明確だ。コントロールプレーンの可用性・スケーリング・バックアップをクラウド側に任せられるため、運用チームはエッジ側のワーカーノード管理に集中できる。K3s組み込みの宣言的管理・自己修復機能により、デバイス障害時もコントロールプレーンが自動的に望ましい状態へ復元しようとする。
一方で見落とされがちなのが、コントロールプレーンとワーカーノードの間を流れる通信量だ。Kubernetesは本質的に「あるべき状態」を継続的に同期し続けるシステムであり、ワーカーノードの数が増えるほど、この同期トラフィックとメトリクス収集のトラフィックが積み上がっていく。クラウド側のCPU使用率やコントロールプレーンの負荷ばかりを監視していると、この「見えないネットワークコスト」に気づくのが遅れることになる。
Kuboのようなマネージド型のK3sサービスであれば、GitOps対応やPrometheus + Grafanaの標準搭載によって、こうしたハイブリッド構成の運用負荷そのものを外部化できるという選択肢も存在する。
push型メトリクスが牙を剥いた日 ── 1台あたり1日700MBの正体
Kubernetesの監視で標準的に使われるPrometheusは、本来「pull型」の設計思想を採り、サーバーが定期的に各ターゲットへスクレイピングにいく方式を採る。しかしPrometheus公式ドキュメントは、Pushgatewayの利用を「サービスレベルのバッチジョブなど、極めて限定的な場合」に留めるべきだとし、複数インスタンスを単一のPushgatewayで扱うと単一障害点になりうること、そしてPrometheusが自動生成するupメトリクス（生死監視）が失われることを明記している（Prometheus公式: When to use the Pushgateway）。
それでも、断続的な接続しか持たないエッジデバイスの世界では、pull型よりpush型が選ばれることが多い。デバイス側から能動的にメトリクスを送信するpush型は、ファイアウォールやNATの内側にいる大量のデバイスからテレメトリを収集する際に扱いやすいためだ。
しかし、このpush型の設計判断が牙を剥く瞬間がある。ある大規模エッジ運用の事例では、宣言的管理と自己修復という利点と引き換えに、push型メトリクス収集によって1デバイスあたり1日およそ700MBものネットワークオーバーヘッドが発生していたことが報告されている。2000台規模で単純計算すれば、1日あたり1.4TB前後のトラフィックがエッジからクラウドへ向けて流れ続ける計算になる。デバイス1台あたりで見れば小さな数字でも、フリート全体では回線コストと帯域設計に直結する規模になるわけだ。
さらに厄介なのは、ワーカーノードが増えるほどトラブルシューティングの難易度も上がる点だ。障害の切り分けポイントが増え、「アプリケーションの問題か、K3sの問題か、メトリクス収集経路の問題か」の判断に時間がかかるようになる。
エッジコンピューティング市場は2025年時点で約261億ドル規模とされ、2028年には約380億ドルまで拡大すると予測されている（IDC調査、The Fast Mode報道）。接続デバイス数の増加とともに、この種のネットワークコストの設計判断は今後さらに重みを増していくだろう（Edge Computing Market調査）。
大規模エッジ運用で見落とされがちな設計チェックリスト
数千台規模のK3sエッジ運用を設計する際、以下の観点をあらかじめチェックリスト化しておくと、本番稼働後の"想定外"を減らせる。
デバイス台数とメトリクス収集方式の相性
- 数十〜数百台規模: pull型でPrometheusが直接スクレイピングしても十分にスケールする範囲
- 数千台規模: push型を採用する場合、Pushgatewayの単一障害点リスク（Prometheus公式ドキュメント）を踏まえ、集約層を冗長化するか、デバイス側のメモリ容量に応じてpush/pullを混在させる設計を検討する
ネットワーク帯域のコスト試算
- push型を選ぶ場合、1デバイスあたりの想定送信量×デバイス台数×通信経路の課金単価で月間コストを事前に試算しておく
- クラウド側の受信コスト（イングレストラフィック課金の有無）もあわせて確認する
障害切り分けのレイヤー設計
- コントロールプレーン・ワーカーノード・メトリクス収集経路のどこで障害が起きているかを迅速に判定できるダッシュボード設計をあらかじめ用意しておく
- ネットワーク層が増えるほど「宣言的管理と自己修復」のメリットと「トラブルシューティングの複雑化」のデメリットはトレードオフの関係になる
K3sを選ぶ理由を「軽さ」で終わらせない
- 単一バイナリ・省メモリ・ARM対応という導入時のメリットだけでなく、運用フェーズで発生するネットワークコスト・障害対応コストまで含めて技術選定の評価軸に加える
こうした設計判断を自前で積み上げていくのは決して簡単ではない。Kubo CloudはK3sベースの管理基盤にPrometheus + Grafanaのモニタリングを標準搭載しており、GitOps（ArgoCD/Flux）連携も含めて、こうしたハイブリッドK3s運用の設計・監視をあらかじめ組み込んだ状態で始められる。EKS/AKS/GKEと比較しても、4vCPU/8GB/40GB×3ノード構成でKuboは月額48,000円からと、コスト効率の面でも選択肢になり得る。
まとめ
クラウドだけでなく、工場・店舗・車載など「どこでも動くインフラ」を実現するのがK3sの本質的な価値だ。だが本番運用で活かすには、「軽さ」という入口の理由だけでなく、通信設計・push型/pull型のトレードオフ・障害切り分けのレイヤー設計まで踏み込んで検討する必要がある。
2000台規模のエッジ運用が明らかにしたのは、K3sの軽量性そのものではなく、「軽量であることと引き換えに何を運用チームが負担するのか」という設計思想の見極めの重要性だった。これから大規模なエッジKubernetes運用を計画するなら、こうした見えないコストまで含めて技術選定を行いたい。
自前でここまでの設計・監視体制を構築するリソースがない場合は、KuboのようなK3sベースのマネージドサービスを比較検討先の一つに加えてみてほしい。ハイブリッド構成やエッジ運用の相談はお問い合わせから可能だ。