K3sクラスタをRKE2に上げたら、本番だけが落ちた
K3s vs RKE2——どちらも「軽量」「CNCF認定」という共通点を持つKubernetesディストリビューションだ。だからこそ、この比較を機能表だけで済ませ、移行や選定を軽く見てしまうケースが後を絶たない。
実際にあった事例を見てみよう。ある運用チームが2つのK3sクラスタをRKE2へ移行した。テスト環境(VM10台)では何の問題もなく完了した。ところが本番環境、しかもエアギャップ構成のベアメタル30台では、約2時間のダウンタイムが発生した(rancher/rke2 Discussion #7627)。
原因は、K3sのcontrol-planeノードに付けていたtaintが、RKE2のインストール処理と非互換だったことだ。RKE2が標準で使うCanal CNI(CalicoベースのCNI)が、そのtaintのせいでインストールを拒否してしまった。別の移行事例では、RancherがRKE2クラスタを誤って「K3s」として再登録し、存在しないアップグレードを試みてクラスタがスケジュール不能状態に陥ったという報告もある(rancher/rancher Issue #46776)。Backup/Restore Operatorを使った移行後、クラスタがActive状態に復帰するまで想定の2〜5分ではなく7〜15分かかったケースも確認されている(rancher/rancher Issue #42834)。
どちらも「ドキュメント通りに進めた」上で起きた話だ。K3s vs RKE2の選定・移行で本当に見落とされがちなのは、機能差そのものより「前提条件の違い」であることが、ここからわかる。
K3s vs RKE2、そもそも何が違うのか
K3s vs RKE2の違いを整理する前に、まず共通点を押さえておきたい。両者ともCNCF認定のKubernetesディストリビューションであり、単一バイナリでのインストール、system-upgrade-controllerによる自動アップグレードなど、運用の手軽さを重視した設計思想を共有している。
違いが大きく出るのはデータストアだ。K3sはSQLiteがデフォルトのデータストアで、他の設定が存在しない場合に自動的に使われる。組み込みetcdは、K3sが新規etcdクラスタの初期化やetcdクラスタへの参加を設定された場合、あるいはディスク上にetcdのデータベースファイルが存在する場合にのみ自動選択される(K3s公式ドキュメント)。つまりK3sで複数サーバーのHA構成を組むには、明示的にetcdを選択する必要がある。
一方RKE2は、組み込みetcd一択だ。SQLiteという選択肢自体が存在しない。これは裏を返せば、RKE2の方が「本番運用を前提にした設計」になっているとも言える。CIS Hardeningの面でも差は明確で、RKE2はhardened by defaultとして設計されており、CISコントロールの大多数に追加修正なしで準拠する。K3sはCIS Benchmarkへの部分対応にとどまり、本番相当の水準に引き上げるには運用者側での追加設定が必要になる(oneuptime.comの比較記事)。FIPS 140-2準拠ビルドやDISA STIG認定も、現状RKE2のみが対応している。
HA構成で要求される前提条件の違い
HA構成を組む際の実務要件も、K3s vs RKE2で細部が異なる。
RKE2のHA構成では、まずサーバーノードを**奇数個(3台推奨)**用意する必要がある。これはetcdがクォーラム(過半数の合意)を維持するための制約だ。その上で、サーバーノード群の前段に「固定登録アドレス」を配置する。実装方法はレイヤー4(TCP)ロードバランサー、ラウンドロビンDNS、仮想/弾性IPアドレスのいずれでもよい。rke2 serverプロセスはノード登録をポート9345で、Kubernetes APIをポート6443でそれぞれリッスンする(RKE2公式ドキュメント)。固定登録アドレスを使う場合は、証明書エラーを避けるためにtls-sanパラメータで追加のホスト名・IPをサーバー証明書のSANに含めておく必要がある。
K3sも組み込みetcdでHAを組む場合は同様に奇数ノードが必須で、最初のサーバーノードは--cluster-initオプションで起動しなければならない。つまり「K3sは手軽、RKE2は面倒」という単純な図式ではなく、HAを前提にした瞬間、両者とも同程度の設計知識が要求されるという点は押さえておきたい。
ストレージとネットワークの"無方針"がもたらす落とし穴
比較表には出てこないが、実務で効いてくるのがストレージの初期設計だ。
K3sはデフォルトでlocal-path-provisionerが標準StorageClassとして設定される。これはノードローカルディスクを前提にした仕組みで、PersistentVolumeClaimは作成時に暗黙的に特定ノードへ紐付く。結果として、ノードのドレインやOSパッチ適用のたびに、該当Podが別ノードに移動できずダウンタイムが発生しやすくなる(K3s/RKE2/Talosのストレージ前提を比較した記事)。
一方RKE2は、CNIとIngressコントローラーはバンドルされているが、ストレージについては意見を持たない。デフォルトのStorageClassが存在しないのだ。一見するとK3sより自由度が高いように見えるが、同記事が指摘する通り、本番導入のスケジュールに追われたチームほど、結局は同じノードローカルプロビジョナーを選んでしまい、K3sと同じ落とし穴にはまるケースが多い。「RKE2だからストレージ設計を間違えない」わけではない、という点は見落とされがちだ。
結局、本番でどちらを選ぶべきか
ここまでの違いを踏まえると、判断フレームは次のように整理できる。
- 金融・医療・政府機関など、CIS Benchmark・FIPS 140-2・DISA STIGといった第三者監査基準への準拠が必須 → RKE2が現実的な選択になる。hardened by defaultという設計が監査対応の工数を大きく下げる。
- エッジ・IoT・ARMデバイス・開発/CI環境など、リソース制約が強くHA要件が緩い → K3sの軽量さが活きる。
- 本番でHAを組む場合 → K3s・RKE2のどちらを選んでも、奇数ノードのetcdクォーラム設計、証明書のSAN設定、ストレージのノードアフィニティ対策は避けて通れない。
つまり「K3s vs RKE2」という問いの本質は、技術的な優劣比較ではなく、自分たちのチームがHA構成・CIS準拠・ストレージ設計を自前で運用し続けられるかという体制の問題だ。ここを見誤ると、冒頭の事例のように「ドキュメント通りに進めたのに本番だけ落ちた」という事態を招く。
この運用負荷そのものを引き受ける選択肢として、マネージドK8sサービスのKuboがある。KuboはK3sベースにRancher管理基盤を組み合わせており、HA構成の設計・etcdのバックアップ運用・証明書管理をマネージド側で担保する。「K3sの軽量さ」と「RKE2相当の運用品質」を自前で両立させる代わりに、Kubo CloudならAI-Driven DeploymentとCaptain UIを通じて、AWS EKSの約58%・Azure AKSの約56%というコスト感覚で本番品質のK3s運用を始められる。
金融・医療・政府機関などCIS/FIPS相当の監査対応がそもそもの前提になる環境では、データ主権を自社管理下に置けるKubo On-Premiseが選択肢になる。Air-Gapped環境にも対応しており、「RKE2を自前でCIS準拠運用する工数」をまるごと引き受けられる設計だ。
まとめ
K3s vs RKE2の比較は、バイナリサイズやデータストアといった機能表だけでは終わらない。CIS Hardening・FIPS対応・HA構成の前提条件・ストレージ設計、そして移行時の非互換リスクまで含めて検討して初めて、「本番で選ぶならどちらか」に答えが出せる。
冒頭の事例が示す通り、taintの非互換のような細部が本番障害に直結する。選定・移行を検討する際は、機能比較だけでなく実際の移行報告や公式のHardening Guideまで目を通しておくことを勧めたい。そして、その運用負荷自体を引き受けたいと感じたら、KuboのようなマネージドK8sサービスを検討する価値は十分にある。