1. K3sとkubeadm、HA構成の前提がそもそも違う
「k3s vs k8s、本番でどちらを選ぶべきか」という検討で意外と見落とされがちなのが、HA（高可用性）構成の前提条件の違いです。K3sとkubeadm（標準Kubernetes）は、同じ"3台構成"と言っても中身がまったく異なります。
K3sのHA構成はembedded etcd（組み込みetcd）が基本です。K3s公式ドキュメントによれば、HA embedded etcdクラスタはetcdが過半数（クォーラム）を維持するために奇数台のサーバーノードで構成する必要があり、最小構成は3ノードです。各サーバーノードがAPIサーバーとetcdメンバーを同時に担う、コンパクトな構成になります。
一方kubeadmは、Kubernetes公式ドキュメントが示す通り、stacked etcdとexternal etcdという2つのトポロジーを選べます。stacked etcdはコントロールプレーンノード上でetcdを静的Podとして動かす方式で、最小3ノードで構成可能です。external etcdはetcdを専用マシン群に分離する方式で、コントロールプレーン用に3台、etcd用に別途3台以上、合計最低6台が必要になります。
つまり「HAクラスタを組む」という同じ目的でも、K3sは3台、kubeadmは構成次第で3台〜6台と、必要なインフラ規模からして異なるのです。
2. カタログ値のRTOと、実運用で起きるズレ
HA構成を検討する際、多くのドキュメントは「リーダー選出は30秒未満」「ノード障害時のトラフィック切り替えは60秒未満」といったRTO（目標復旧時間）の目安を示します。K3sの運用ガイド系情報でも、etcdリーダー選出の許容RTOは30秒未満、単一サーバーノード障害時のトラフィック再ルーティングは60秒未満が一般的な基準とされています。
しかし、この数値は理想条件下でのものです。実際には、3マスター+1ワーカーという一般的な4ノード構成で単一ノード障害をテストしたところ、フェイルオーバーの完了まで3〜6分を要したという実測報告があります。カタログ値の最大6倍近い差です。
このズレが生まれる要因は複合的です。ロードバランサーのヘルスチェック間隔、DNS/サービスディスカバリーの反映遅延、kubeletのノード状態検知のタイムアウト設定など、etcd自体のリーダー選出時間以外の要素が積み重なることで、体感のダウンタイムは公式の目安よりずっと長くなります。「RTO30秒」という数字だけを根拠にSLAを設計すると、本番障害時に想定外の説明責任を負うことになりかねません。
3. 障害ドメインの結合 vs 分離 — stacked etcdとexternal etcdの分かれ道
フェイルオーバーの体感時間だけでなく、「何が壊れたときに何が道連れになるか」という障害ドメインの設計も重要な判断軸です。
kubeadmのstacked etcd構成では、stacked/external etcdトポロジーの比較が指摘するように、コントロールプレーンノードの障害がそのままetcdメンバーの喪失を意味します。3ノード構成なら1台の喪失は許容範囲ですが、2台目を失った瞬間にクォーラムそのものが崩れ、単なる「処理能力の低下」では済まなくなります。Kubernetesの高可用性設計に関する一般的な指針でも、マスターノードは異なる障害ドメイン（アベイラビリティゾーンやラック）に分散配置すべきとされており、stacked構成はこの分散を単一ノード内で済ませてしまう点にリスクがあります。
external etcd構成であれば、コントロールプレーンとetcdの障害ドメインを完全に分離できます。片方の層で障害が起きても、もう片方は独立して稼働し続けられるため、大規模クラスタほどこの分離のメリットは大きくなります。ただし、その代償として必要なマシン数がstackedの2倍（3台→6台）に増え、運用対象も増えます。
K3sのembedded etcdは、設計思想としてはstacked etcdに近く、シンプルさと引き換えに障害ドメインが結合しています。ノード数を絞って素早く本番投入したいケースに向く一方、大規模・ミッションクリティカルな環境でどこまで通用するかは、クラスタ規模に応じて見極める必要があります。
4. etcdクォーラムの計算式と、奇数ノードの落とし穴
K3sでもkubeadmでも、HA構成の耐障害性を決めているのは結局のところetcdのクォーラム（定足数）です。etcd公式ドキュメントは、Raftコンセンサスアルゴリズム上、過半数のメンバーを失うとクラスタが書き込みを受け付けなくなる仕組みを説明しています。この過半数（クォーラム）の必要数は、K3s公式ドキュメントが示す通り、N台構成で (N/2)+1 という式で計算されます。
具体的には次の通りです。
- 3ノード構成: クォーラムは2、1台の障害まで許容
- 5ノード構成: クォーラムは3、2台の障害まで許容
- 7ノード構成: クォーラムは4、3台の障害まで許容
ここで見落とされがちなのが、「奇数クラスタにノードを1台追加しても、フォールトトレランスが改善するとは限らない」という点です。例えば3ノードを4ノードにしても、クォーラムは3のままで許容障害数は変わらず、むしろ必要な合意数だけが増えてしまうケースがあります。耐障害性を1段階上げたいなら、偶数1台追加ではなく奇数のまま5ノードへ拡張する必要があります。
また、多数派のメンバーが同時に失われた場合、etcdクラスタは新しい書き込みを一切受け付けなくなり、KubernetesのAPIサーバーは読み取り専用、最悪の場合は完全に応答不能になります。多数派が復帰すればetcdは自動的に新しいリーダーを選出して正常化しますが、復帰しない場合はディザスタリカバリの手動対応が必要です。クォーラム設計は「何台まで同時に落ちても業務影響が出ないか」を数式ベースで逆算しておくべき項目です。
5. 結論 — 本番でK3sとkubeadm、どちらを選ぶか
ここまでの比較を踏まえると、判断軸は「ノード規模」と「運用に割けるリソース」の2つに集約されます。
K3sとkubeadmの2026年時点の比較でも触れられている通り、K3sはサーバー側で512MB RAM・制御プレーンメモリ約300MBという省リソースで稼働し、3コマンド程度で3ノードHAクラスタを構築できる手軽さが強みです。3〜20ノード規模の小〜中規模本番クラスタであれば、embedded etcdの障害ドメイン結合というトレードオフを受け入れてでも、構築・運用コストの低さが勝る場面は多いでしょう。
一方、kubeadmとK3s・EKSの選定基準を整理した記事が示すように、kubeadmは全コンポーネントを完全制御したい環境や、100ノードを超える大規模クラスタで強みを発揮します。外部etcdで障害ドメインを分離し、必要なら専用NVMeストレージでetcdのI/O競合を避ける、といった本格的なチューニングもできます。
判断フレームとしては、「3台規模で小さく始め、運用負荷を抑えたいならK3s embedded etcd」「将来1000ノード級までスケールする可能性があり、運用チームの体制も整っているならkubeadmのexternal etcd」という整理が現実的です。なお、過去の検証記事（K3sとkubeadmのメモリ使用量実測比較）でも、リソース効率の面でK3sに分がある結果が出ており、小〜中規模での優位性は本記事のHA検証とも整合しています。
とはいえ、このHA設計・etcdクォーラムの運用監視・フェイルオーバーテストを自前でやり切るには、相応の知見と工数が必要です。KuboはK3sベースのマネージドKubernetesサービスとして、こうしたクォーラム管理やフェイルオーバー監視を標準で組み込んでおり、本格的なK8sの機能はそのままに、EKS/AKSより低コストで運用できます。HA構成を自前で設計・検証する工数を削減したい場合、料金プランで他のマネージドK8sサービスとのコスト比較を確認してみてください。
まとめ
K3sのembedded etcdとkubeadmのstacked/external etcdは、カタログ上のRTOだけを見ると似たような数字に見えますが、実運用での体感時間や障害ドメインの設計には明確な違いがあります。
- カタログ値のRTO（30〜60秒）と実測値（3〜6分）にはギャップが生じ得る
- stacked etcd / embedded etcdは障害ドメインが結合し、external etcdは分離できる代わりにノード数が倍になる
- クォーラムは(N/2)+1で決まり、奇数ノードへの中途半端な台数追加は耐障害性を改善しない場合がある
HA設計は「公式のRTO目安」だけで判断せず、自分たちのクラスタ規模・運用体制に合わせてノード構成と障害ドメインを逆算することが重要です。自前でのHA設計・検証・監視の工数を減らしたいチームは、マネージドK3sであるKuboのお問い合わせから、自社のクラスタ規模に合わせた構成相談も可能です。