1. なぜ"軽量Kubernetes"を一括りにすると判断を誤るか
K3s vs MicroK8s という比較は、「どちらも軽量だから好きな方で良い」という結論で終わりがちです。しかし実際にエッジや本番環境でクラスタを運用する立場からすると、この2つは思想の異なる別物です。
K3sはRancher（現SUSEの一部門）が開発したプロジェクトです。CNCF公式によると、K3sは2020年8月19日にCNCF Sandboxプロジェクトとして受け入れられています。The New Stackの報道は、これをCNCF Sandboxに入った最初のKubernetesディストリビューションだと伝えています。一方のMicroK8sはCanonical（Ubuntuの開発元）が提供する、snapパッケージ前提の軽量Kubernetesです。
出自が違えば、リソース設計もHA（高可用性）の実装方式もアップグレードの考え方も異なります。「軽量Kubernetesなら何でも同じ」という前提のまま選定すると、本番運用に入ってから想定外の運用負荷に直面することになります。本記事では、公式ドキュメントのデータをもとに両者の実務上の差を整理します。なお、この選定そのものに時間を使いたくない場合は、KuboのようなマネージドK3sという第三の選択肢もあります。
2. K3sとMicroK8s、リソース要件とインストール方式の実測差
K3sの公式ドキュメントによると、サーバーノードは2コア/2GBのRAM、エージェントノードは1コア/512MBのRAMが最小要件です。これはK3s自体とパッケージされたコンポーネントの基本要件であり、ワークロードが消費するリソースは別途必要になります。対応アーキテクチャはx86_64、armhf、arm64/aarch64で、Raspberry Piのような小型デバイスでも動作します。
Rancherの製品ページでは、K3sは単一バイナリとして配布され、サイズは40MB未満であると説明されています。依存コンポーネントを削減し、単一バイナリに集約する設計思想が、この軽さを実現しています。
一方のMicroK8sは、「Zero-ops, pure-upstream, HA Kubernetes」というコンセプトで提供されており、snapパッケージとして最小限のセットアップで完全なクラスタを構築できます。Linuxではsnap経由、macOSではHomebrew経由、Windowsでは専用インストーラーでインストールできるなど、対応OSの幅広さがK3sとの違いです。Canonicalの公式ブログでは、単一コマンドでの展開とSnapストアによる自動更新が特徴として挙げられています。
K3sが「最小リソースでの単体動作」に振り切っているのに対し、MicroK8sは「マルチOS対応と運用の自動化」を優先した設計であることが、ここまでの比較だけでも見えてきます。
3. K3s vs MicroK8s、HA構成の分岐点 ― embedded etcdとdqlite
両者の設計思想が最もはっきり分かれるのが、HA（高可用性）構成におけるデータストアです。
K3sの公式ドキュメントによると、K3sはシングルノード構成ではSQLiteをデフォルトのデータストアとして使用します。これは「他のデータストア構成が存在せず、ディスク上に埋め込みetcdのデータベースファイルが存在しない場合」に使われる選択肢であり、複数サーバーを持つクラスタでは使用できません。複数サーバーでのHA構成にする場合は、embedded etcd（組み込みetcd）に切り替える設計です。
対してMicroK8sは、Canonicalの公式ドキュメントによれば、3台以上のノードでクラスタを構成すると自動的にHAが有効になり、分散SQLiteであるdqliteがKubernetesの状態管理を担います。ノードはVoter（投票者：データベース複製とリーダー選出に参加）、Standby（待機：複製のみ）、Spare（予備：複製に関与しない）の3役に自動分類され、リーダー障害時は最大5秒で新リーダーが選出、Standbyノードの投票者への昇格には最大30秒を要するとされています。
つまり、K3sはHAをオプトインの構成変更（SQLite→embedded etcd）として扱うのに対し、MicroK8sはノード数という条件を満たせば自動的にHAへ移行する設計です。前者はシングルノードから始めて必要になった時点でHA化する運用に向き、後者は最初から複数ノードでの冗長性を前提にした構成に向いています。クォーラム設計を自分たちでどこまで意識する必要があるかという運用負荷の差が、ここに表れます。
KuboのようなマネージドK3sサービスを使う場合、このembedded etcdのクォーラム管理自体を意識する必要がなくなる点は、HA構成の複雑さに悩むチームにとって検討材料になるはずです。
4. アドオン運用とアップグレードの思想差
HA構成だけでなく、日常の運用面でも両者の思想は分かれます。
MicroK8sはmicrok8s enableコマンド一つで、DNS、Ingress、Dashboard、Prometheus、Istio、LinkerD、Knativeといったアドオンを有効化できます。Canonicalのドキュメントにあるとおり、必要な機能をモジュールとして後から足していく運用が前提です。また、Snapパッケージである特性上、自動更新の仕組みが標準で組み込まれており、Ubuntu Proのサブスクリプションを契約すれば99.9%のアップタイム保証とセキュリティメンテナンスも受けられます。
K3sは対照的に、最小構成の単一バイナリから出発し、Helmチャートなどを使って必要なコンポーネントを自分たちで足していく思想です。アップグレードについても、Snapのような自動更新の仕組みを標準搭載せず、運用チームがタイミングを制御する前提になっています。
この違いは「運用を自動化に委ねるか、自分たちで制御するか」というトレードオフです。前者は初速が早く属人化しにくい一方、後者は変更点を把握しやすく意図しないタイミングでの挙動変化を防ぎやすいという利点があります。GitOpsでHelmチャートのバージョンを明示的に管理したいチームには、K3s寄りの思想が合うケースが多いでしょう。
5. エッジ/本番のどちらで選ぶべきか ― 判断フレーム
ここまでの比較を踏まえると、選定の判断軸は次の3つに整理できます。
- リソース制約が最優先か: エッジデバイスやIoT機器のようにメモリ・CPUが限られる環境では、サーバー2コア/2GB・エージェント1コア/512MBというK3sの最小要件が有利です
- 開発環境と本番のOSを揃えたいか: macOSやWindowsでも同じ構成を再現したい場合は、マルチOS対応のMicroK8sが選択肢になります
- HA構成を誰がどう設計するか: embedded etcdのクォーラム設計を自分たちで制御したいならK3s、ノード数ベースで自動化されたdqlite HAに任せたいならMicroK8sという分かれ方になります
どちらもCNCF Certified Kubernetes Conformance Programに適合した標準Kubernetes APIと互換性があるため、アプリケーション側の移植性で大きな差は生まれません。差が出るのは、クラスタそのものの運用をどこまで自分たちで引き受けるかという点です。
6. まとめ
K3sとMicroK8sは、どちらも「軽量Kubernetes」というカテゴリで語られがちですが、HA構成の実装（embedded etcd vs dqlite）、インストール・アップデートの思想（手動制御 vs 自動化）、対応OSの幅という3点で明確に異なります。「軽量だから」という理由だけで選ぶのではなく、自分たちのチームがHA構成の運用負荷をどこまで引き受けられるかで判断するのが、本番運用で後悔しない選び方です。
そのHA構成の運用負荷自体をなくしたい場合、選択肢になるのがKuboです。KuboはK3sベースのマネージドKubernetesサービスで、embedded etcdのクォーラム設計やアップグレードのタイミング管理をKubo側が引き受けます。月額48,000円〜という、AWS EKS（月額82,700円）の約58%のコストでフルスペックのK8s機能を使える点も特徴です。K3sかMicroK8sかで迷う時間を、運用自体をなくす方向で解決したいチームは、Kubo Cloudの構成を確認してみてください。
エッジ環境でのK3s活用を検討している場合は、KuboのK3sベースの軽量構成がそのままエッジ展開にも対応できます。オンプレミスでデータ主権を維持したまま同様の比較検討をしたい場合は、Kubo On-Premiseという選択肢もあります。