「軽量Kubernetes」という言葉でひとくくりにしてはいけない
K3sとMicroShift。どちらも「エッジ向けの軽量Kubernetes」として紹介されることが多く、比較検討の俎上に載せられがちだ。しかし実際にアーキテクチャを読み比べると、両者は「軽量化」のアプローチからして別物であることが分かる。
MicroShiftは、Red Hatがエッジ向けに提供する単一ノード向けのコンテナオーケストレーションランタイムだ。Red Hat Enterprise Linux（RHEL）上で動作する「アプリケーション」という位置づけで、ネットワーキング・Ingress・ストレージといったKubernetesの必須機能に対象を絞っている（Red Hat公式ドキュメント「Understanding MicroShift」）。重要なのは、MicroShiftがKubernetesの標準コンポーネントを置き換えないという設計方針だ。
一方K3sは、Kubernetesのコントロールプレーン全体を単一バイナリ（100MB未満）にパッケージ化した、完全準拠かつCNCF認定のディストリビューションである（K3s公式ドキュメント）。K3sは2020年8月にCNCF Sandboxプロジェクトとして受け入れられており（CNCF公式プロジェクトページ）、OSやディストリビューションを問わず単一バイナリで動く点が最大の特徴だ。
つまり、MicroShiftは「RHELというOSの上でKubernetesの必須機能だけを動かす」設計であり、K3sは「どのLinux環境でもKubernetesフルスタックを1バイナリで動かす」設計である。この出発点の違いが、以降で見るデータストア・OS更新モデル・サポート体制のすべてに波及している。クラウドだけでなくエッジでも同じK3sをマネージドで動かしたい場合、この設計思想の違いはKuboのようなK3sベースのサービスを検討する際の判断材料にもなる。
データストアの選択肢 — K3sの柔軟性とMicroShiftのetcd固定
Kubernetesのコントロールプレーンは、クラスタの全状態を保持する「唯一の真実のソース」としてetcdのようなキーバリューストアを必要とする（Kubernetes公式ドキュメント）。この部分の実装方針が、K3sとMicroShiftでは大きく異なる。
K3sのデフォルトデータストアは組み込みSQLiteだ。ただしSQLiteはマルチサーバー構成では利用できない。HA（高可用性）構成を組む場合は、組み込みetcd、あるいは外部データベース（etcd v3.5.21、MySQL 8.0/8.4、MariaDB 10.11/11.4、PostgreSQL 15.12/16.7/17.3）を選択する（K3s公式ドキュメント：データストア）。つまりK3sは、単一ノードのエッジ端末ではSQLiteで身軽に、本番のマルチサーバー構成ではetcdや既存の外部DB基盤に乗せる、という使い分けが可能だ。
対してMicroShiftは、Kubernetesの標準コンポーネントを置き換えない方針のため、データストアは常にetcdである。選択肢がない代わりに構成がシンプルになり、Kubernetes標準との互換性を保ちやすいというメリットがある。
この違いは、「エッジ端末のリソース制約に合わせてデータストアを軽くしたい」という要求に対する回答が、K3sでは「ある」、MicroShiftでは「ない」ということを意味する。シングルボードコンピュータのような極小リソース環境を想定するなら、この差は無視できない。
OS更新モデルの違い — OSTreeの自動ロールバックは「前提」か「代償」か
MicroShiftが真価を発揮するのは、RHEL for Edgeと組み合わせた「Red Hat Device Edge」構成だ。RHEL for EdgeはOSTreeベースのイミュータブルOSで、自動ロールバックや自動バックアップ/リストア機能を備えている（Red Hat公式ドキュメント）。OTA更新・モニタリング・ロギングといった運用機能はMicroShift自体ではなく、OS側（RHEL for Edge）の責務として設計されている。
これは一見すると大きなメリットに見える。クラスタの更新とOSの更新が一体化し、失敗時には自動でロールバックされる。無人運用の店舗端末や工場のエッジゲートウェイのように、人手をかけられない現場では魅力的な仕組みだ。
しかしこれは同時に、「RHEL for Edgeというエコシステムに乗ること」が前提条件になることを意味する。OS・ディストリビューション・サブスクリプションの3つがセットで決まってしまうため、既に別のLinuxディストリビューションで標準化している組織や、マルチOS環境を運用している組織にとっては、新たな依存を1つ背負うことになる。
K3sはOS非依存で、対応する任意のLinuxディストリビューション上で動く（K3s公式ドキュメント）。これはOS更新の自動化をK3s自身が提供しないことも意味する。更新戦略は利用者側で設計する必要があるが、裏を返せば既存のOS標準化方針やイメージビルドパイプラインをそのまま活かせる自由度がある。
「自動化されている」ことと「縛られている」ことは、エッジインフラの選定においてはしばしば表裏一体だ。Kubo On-Premiseのように、OS更新とK3sクラスタの更新を一体でマネージドが引き受けつつ、特定OSベンダーへの依存を増やさない構成を選べば、この表裏一体のトレードオフ自体を切り離すという選択肢も見えてくる。
見落とされがちな初期設定 — etcdの暗号化はデフォルトではない
MicroShiftのKubernetesオブジェクトはetcdデータベースに保存されるが、公式ドキュメントは「etcdデータはデフォルトで暗号化されない」ことを明記している。機密データを扱う場合は、LUKS（Linux Unified Key Setup）でディスクを暗号化する、あるいはストレージプラグイン自体を無効化するといった追加の設定判断が必要になる（Red Hat公式ドキュメント）。
「エッジ向けに最適化された製品だから、セキュリティも初期状態で安全なはず」という思い込みは禁物だ。これはMicroShift固有の弱点というより、K3sのSQLiteやetcdでも同様に、ディスク暗号化や静止時のデータ保護は利用者側の責務として残る点に注意したい。どちらのディストリビューションを選んでも、「データストアの暗号化設定を明示的に確認する」というチェック項目は本番導入のチェックリストから外せない。
商用サポートとライフサイクル — Red Hat Device EdgeとSUSE/Rancherの違い
Red Hatは「Red Hat build of MicroShift Life Cycle Policy」を公開しており、バージョンごとのFull Support Phaseやサポート終了時期が定義されている（Red Hatライフサイクルポリシー）。つまりMicroShiftは、商用プロダクトとしてサポート期間が明示的に管理される段階に入っている。RHELサブスクリプションの傘のもとで、OS・クラスタ・サポート窓口が一本化される点は、エンタープライズの調達プロセスと相性が良い。
K3sはCNCF認定のOSSであり、プロジェクト自体の商用サポートはSUSE/Rancherが提供するRancher Prime等の契約に依存する。OSSとしての開発コミュニティの透明性・ディストリビューション非依存という柔軟性を取るか、単一ベンダーのサブスクリプションに統合されたサポート体系を取るかは、組織のガバナンス方針次第だ。
学術研究の領域でも、軽量Kubernetesディストリビューションの比較は進んでいる。k0s・K3s・KubeEdge・OpenYurtを対象に、セキュリティ準拠性・ネットワーク障害への耐性・保守性の観点から比較した論文では、k3sやk0sは開発のしやすさに優れる一方でセキュリティ準拠性の面ではトレードオフを抱えることが指摘されている（arXiv:2503.04815）。この論文自体はMicroShiftを直接の比較対象にしていないが、「シンプルさ・開発容易性」と「セキュリティ・堅牢性」がトレードオフになるという指摘は、本記事で見てきたMicroShiftのetcd固定・OSTree自動化による堅牢性と、K3sの柔軟性との対比にも通じる論点だ。軽量Kubernetesの選定は、単なる「リソース使用量の比較」を超えて、こうしたトレードオフをどう評価するかというガバナンスの問題になりつつある。
まとめ：どちらを選ぶべきか
K3sとMicroShiftは、どちらも「エッジでKubernetesを動かす」という同じ目的を持ちながら、前提とする運用モデルがまったく異なる。
- RHELエコシステムに閉じた単一ノードエッジ（小売店舗のPOS端末、工場の単一ゲートウェイ等）で、OSからクラスタまで一体化した自動更新・自動ロールバックを求めるなら、MicroShiftの統合度の高さが活きる
- ディストリビューション非依存でクラウドからエッジまで同一の運用モデルを求める、あるいはマルチサーバーでのHA構成やデータストアの柔軟性を重視するなら、K3sの自由度が活きる
どちらを選んでも、「OSの更新戦略」と「クラスタの更新戦略」をどう一体運用するかという課題は残る。MicroShiftはOSTreeでそれを自動化する代わりにRHELエコシステムへの依存を引き受け、K3sは依存を増やさない代わりに運用設計を利用者に委ねる。
KuboはK3sベースのマネージドKubernetesサービスとして、まさにこの「OS更新とクラスタ更新を誰が一体で引き受けるか」という課題に向き合っている。K3sの柔軟性やディストリビューション非依存の強みを損なわずに、更新・監視・バックアップといった運用の重い部分をマネージドが引き受ける構成だ。
特にKubo On-Premiseは、エッジや自社データセンターにK3sクラスタを構築しながら、単一ベンダーのOSサブスクリプションに縛られずに済む選択肢として設計されている。すでにK3sでエッジ運用を行っている、あるいはMicroShiftの導入を検討していて「OSごとロックインされること」に懸念がある場合は、Kuboへのお問い合わせから現在の構成を相談してみてほしい。
K3sベースの軽量性と、マネージドによる運用の安心感。クラウドだけでなく、エッジにもKubernetesを届けるという発想が、工場や店舗でのAI推論や自動化ワークロードを、現実的なコストで実現する土台になる。