[{"data":1,"prerenderedAt":354},["ShallowReactive",2],{"blog-ja-k3s-kubeadm-ha-etcd-failover-rto-gap":3,"blog-related-ja-k3s-kubeadm-ha-etcd-failover-rto-gap":302,"blog-ja-k3s-kubeadm-ha-etcd-failover-rto-gap-alt":291},{"id":4,"title":5,"author":6,"body":7,"date":285,"description":286,"extension":287,"image":288,"locale":289,"meta":290,"navigation":291,"path":292,"seo":293,"stem":294,"tags":295,"__hash__":301},"blog\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap.md","RTO30秒のはずが3分止まった。K3sとkubeadmのHA構成で\"カタログ値\"と\"実運用\"がズレる理由","Kubo Team",{"type":8,"value":9,"toc":275},"minimark",[10,15,23,26,46,63,66,70,76,85,92,95,99,105,108,127,130,133,137,143,160,163,185,188,191,195,201,204,212,221,230,245,248,251,262],[11,12,14],"h2",{"id":13},"_1-k3sとkubeadmha構成の前提がそもそも違う","1. K3sとkubeadm、HA構成の前提がそもそも違う",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Fsection01.webp",[16,24,25],{},"「k3s vs k8s、本番でどちらを選ぶべきか」という検討で意外と見落とされがちなのが、HA（高可用性）構成の前提条件の違いです。K3sとkubeadm（標準Kubernetes）は、同じ\"3台構成\"と言っても中身がまったく異なります。",[16,27,28,29,33,34,41,42,45],{},"K3sのHA構成は",[30,31,32],"strong",{},"embedded etcd","（組み込みetcd）が基本です。",[35,36,40],"a",{"href":37,"rel":38},"https:\u002F\u002Fdocumentation.suse.com\u002Fen-us\u002Fcloudnative\u002Fk3s\u002Flatest\u002Fja\u002Fdatastore\u002Fha-embedded.html",[39],"nofollow","K3s公式ドキュメント","によれば、HA embedded etcdクラスタはetcdが過半数（クォーラム）を維持するために",[30,43,44],{},"奇数台のサーバーノードで構成する必要があり、最小構成は3ノード","です。各サーバーノードがAPIサーバーとetcdメンバーを同時に担う、コンパクトな構成になります。",[16,47,48,49,54,55,58,59,62],{},"一方kubeadmは、",[35,50,53],{"href":51,"rel":52},"https:\u002F\u002Fv1-33.docs.kubernetes.io\u002Fdocs\u002Fsetup\u002Fproduction-environment\u002Ftools\u002Fkubeadm\u002Fhigh-availability\u002F",[39],"Kubernetes公式ドキュメント","が示す通り、",[30,56,57],{},"stacked etcd","と",[30,60,61],{},"external etcd","という2つのトポロジーを選べます。stacked etcdはコントロールプレーンノード上でetcdを静的Podとして動かす方式で、最小3ノードで構成可能です。external etcdはetcdを専用マシン群に分離する方式で、コントロールプレーン用に3台、etcd用に別途3台以上、合計最低6台が必要になります。",[16,64,65],{},"つまり「HAクラスタを組む」という同じ目的でも、K3sは3台、kubeadmは構成次第で3台〜6台と、必要なインフラ規模からして異なるのです。",[11,67,69],{"id":68},"_2-カタログ値のrtoと実運用で起きるズレ","2. カタログ値のRTOと、実運用で起きるズレ",[16,71,72],{},[19,73],{"alt":74,"src":75},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Fsection02.webp",[16,77,78,79,84],{},"HA構成を検討する際、多くのドキュメントは「リーダー選出は30秒未満」「ノード障害時のトラフィック切り替えは60秒未満」といったRTO（目標復旧時間）の目安を示します。",[35,80,83],{"href":81,"rel":82},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-02-k3s-high-availability\u002Fview",[39],"K3sの運用ガイド系情報","でも、etcdリーダー選出の許容RTOは30秒未満、単一サーバーノード障害時のトラフィック再ルーティングは60秒未満が一般的な基準とされています。",[16,86,87,88,91],{},"しかし、この数値は理想条件下でのものです。実際には、3マスター+1ワーカーという一般的な4ノード構成で単一ノード障害をテストしたところ、",[30,89,90],{},"フェイルオーバーの完了まで3〜6分を要した","という実測報告があります。カタログ値の最大6倍近い差です。",[16,93,94],{},"このズレが生まれる要因は複合的です。ロードバランサーのヘルスチェック間隔、DNS\u002Fサービスディスカバリーの反映遅延、kubeletのノード状態検知のタイムアウト設定など、etcd自体のリーダー選出時間以外の要素が積み重なることで、体感のダウンタイムは公式の目安よりずっと長くなります。「RTO30秒」という数字だけを根拠にSLAを設計すると、本番障害時に想定外の説明責任を負うことになりかねません。",[11,96,98],{"id":97},"_3-障害ドメインの結合-vs-分離-stacked-etcdとexternal-etcdの分かれ道","3. 障害ドメインの結合 vs 分離 — stacked etcdとexternal etcdの分かれ道",[16,100,101],{},[19,102],{"alt":103,"src":104},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Fsection03.webp",[16,106,107],{},"フェイルオーバーの体感時間だけでなく、「何が壊れたときに何が道連れになるか」という障害ドメインの設計も重要な判断軸です。",[16,109,110,111,116,117,120,121,126],{},"kubeadmのstacked etcd構成では、",[35,112,115],{"href":113,"rel":114},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-09-stacked-vs-external-etcd-topology\u002Fview",[39],"stacked\u002Fexternal etcdトポロジーの比較","が指摘するように、",[30,118,119],{},"コントロールプレーンノードの障害がそのままetcdメンバーの喪失を意味します","。3ノード構成なら1台の喪失は許容範囲ですが、2台目を失った瞬間にクォーラムそのものが崩れ、単なる「処理能力の低下」では済まなくなります。",[35,122,125],{"href":123,"rel":124},"https:\u002F\u002Fwww.tigera.io\u002F?p=63816",[39],"Kubernetesの高可用性設計に関する一般的な指針","でも、マスターノードは異なる障害ドメイン（アベイラビリティゾーンやラック）に分散配置すべきとされており、stacked構成はこの分散を単一ノード内で済ませてしまう点にリスクがあります。",[16,128,129],{},"external etcd構成であれば、コントロールプレーンとetcdの障害ドメインを完全に分離できます。片方の層で障害が起きても、もう片方は独立して稼働し続けられるため、大規模クラスタほどこの分離のメリットは大きくなります。ただし、その代償として必要なマシン数がstackedの2倍（3台→6台）に増え、運用対象も増えます。",[16,131,132],{},"K3sのembedded etcdは、設計思想としてはstacked etcdに近く、シンプルさと引き換えに障害ドメインが結合しています。ノード数を絞って素早く本番投入したいケースに向く一方、大規模・ミッションクリティカルな環境でどこまで通用するかは、クラスタ規模に応じて見極める必要があります。",[11,134,136],{"id":135},"_4-etcdクォーラムの計算式と奇数ノードの落とし穴","4. etcdクォーラムの計算式と、奇数ノードの落とし穴",[16,138,139],{},[19,140],{"alt":141,"src":142},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Fsection04.webp",[16,144,145,146,151,152,155,156,159],{},"K3sでもkubeadmでも、HA構成の耐障害性を決めているのは結局のところetcdのクォーラム（定足数）です。",[35,147,150],{"href":148,"rel":149},"https:\u002F\u002Fetcd.io\u002Fdocs\u002Fv3.3\u002Fop-guide\u002Ffailures\u002F",[39],"etcd公式ドキュメント","は、Raftコンセンサスアルゴリズム上、過半数のメンバーを失うとクラスタが書き込みを受け付けなくなる仕組みを説明しています。この過半数（クォーラム）の必要数は、",[35,153,40],{"href":37,"rel":154},[39],"が示す通り、N台構成で ",[30,157,158],{},"(N\u002F2)+1"," という式で計算されます。",[16,161,162],{},"具体的には次の通りです。",[164,165,166,173,179],"ul",{},[167,168,169,170],"li",{},"3ノード構成: クォーラムは2、",[30,171,172],{},"1台の障害まで許容",[167,174,175,176],{},"5ノード構成: クォーラムは3、",[30,177,178],{},"2台の障害まで許容",[167,180,181,182],{},"7ノード構成: クォーラムは4、",[30,183,184],{},"3台の障害まで許容",[16,186,187],{},"ここで見落とされがちなのが、「奇数クラスタにノードを1台追加しても、フォールトトレランスが改善するとは限らない」という点です。例えば3ノードを4ノードにしても、クォーラムは3のままで許容障害数は変わらず、むしろ必要な合意数だけが増えてしまうケースがあります。耐障害性を1段階上げたいなら、偶数1台追加ではなく奇数のまま5ノードへ拡張する必要があります。",[16,189,190],{},"また、多数派のメンバーが同時に失われた場合、etcdクラスタは新しい書き込みを一切受け付けなくなり、KubernetesのAPIサーバーは読み取り専用、最悪の場合は完全に応答不能になります。多数派が復帰すればetcdは自動的に新しいリーダーを選出して正常化しますが、復帰しない場合はディザスタリカバリの手動対応が必要です。クォーラム設計は「何台まで同時に落ちても業務影響が出ないか」を数式ベースで逆算しておくべき項目です。",[11,192,194],{"id":193},"_5-結論-本番でk3sとkubeadmどちらを選ぶか","5. 結論 — 本番でK3sとkubeadm、どちらを選ぶか",[16,196,197],{},[19,198],{"alt":199,"src":200},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Fsection05.webp",[16,202,203],{},"ここまでの比較を踏まえると、判断軸は「ノード規模」と「運用に割けるリソース」の2つに集約されます。",[16,205,206,211],{},[35,207,210],{"href":208,"rel":209},"https:\u002F\u002Flucaberton.com\u002Fblog\u002Fk3s-vs-k8s-2026\u002F",[39],"K3sとkubeadmの2026年時点の比較","でも触れられている通り、K3sはサーバー側で512MB RAM・制御プレーンメモリ約300MBという省リソースで稼働し、3コマンド程度で3ノードHAクラスタを構築できる手軽さが強みです。3〜20ノード規模の小〜中規模本番クラスタであれば、embedded etcdの障害ドメイン結合というトレードオフを受け入れてでも、構築・運用コストの低さが勝る場面は多いでしょう。",[16,213,214,215,220],{},"一方、",[35,216,219],{"href":217,"rel":218},"https:\u002F\u002Fdevopsboys.com\u002Fblog\u002Fkubeadm-vs-k3s-vs-eks-kubernetes-setup-2026",[39],"kubeadmとK3s・EKSの選定基準を整理した記事","が示すように、kubeadmは全コンポーネントを完全制御したい環境や、100ノードを超える大規模クラスタで強みを発揮します。外部etcdで障害ドメインを分離し、必要なら専用NVMeストレージでetcdのI\u002FO競合を避ける、といった本格的なチューニングもできます。",[16,222,223,224,229],{},"判断フレームとしては、「3台規模で小さく始め、運用負荷を抑えたいならK3s embedded etcd」「将来1000ノード級までスケールする可能性があり、運用チームの体制も整っているならkubeadmのexternal etcd」という整理が現実的です。なお、過去の検証記事（",[35,225,228],{"href":226,"rel":227},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison",[39],"K3sとkubeadmのメモリ使用量実測比較","）でも、リソース効率の面でK3sに分がある結果が出ており、小〜中規模での優位性は本記事のHA検証とも整合しています。",[16,231,232,233,238,239,244],{},"とはいえ、このHA設計・etcdクォーラムの運用監視・フェイルオーバーテストを自前でやり切るには、相応の知見と工数が必要です。",[35,234,237],{"href":235,"rel":236},"https:\u002F\u002Fkubo.hexabase.io\u002F",[39],"Kubo","はK3sベースのマネージドKubernetesサービスとして、こうしたクォーラム管理やフェイルオーバー監視を標準で組み込んでおり、本格的なK8sの機能はそのままに、EKS\u002FAKSより低コストで運用できます。HA構成を自前で設計・検証する工数を削減したい場合、",[35,240,243],{"href":241,"rel":242},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[39],"料金プラン","で他のマネージドK8sサービスとのコスト比較を確認してみてください。",[11,246,247],{"id":247},"まとめ",[16,249,250],{},"K3sのembedded etcdとkubeadmのstacked\u002Fexternal etcdは、カタログ上のRTOだけを見ると似たような数字に見えますが、実運用での体感時間や障害ドメインの設計には明確な違いがあります。",[164,252,253,256,259],{},[167,254,255],{},"カタログ値のRTO（30〜60秒）と実測値（3〜6分）にはギャップが生じ得る",[167,257,258],{},"stacked etcd \u002F embedded etcdは障害ドメインが結合し、external etcdは分離できる代わりにノード数が倍になる",[167,260,261],{},"クォーラムは(N\u002F2)+1で決まり、奇数ノードへの中途半端な台数追加は耐障害性を改善しない場合がある",[16,263,264,265,268,269,274],{},"HA設計は「公式のRTO目安」だけで判断せず、自分たちのクラスタ規模・運用体制に合わせてノード構成と障害ドメインを逆算することが重要です。自前でのHA設計・検証・監視の工数を減らしたいチームは、マネージドK3sである",[35,266,237],{"href":235,"rel":267},[39],"の",[35,270,273],{"href":271,"rel":272},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[39],"お問い合わせ","から、自社のクラスタ規模に合わせた構成相談も可能です。",{"title":276,"searchDepth":277,"depth":277,"links":278},"",2,[279,280,281,282,283,284],{"id":13,"depth":277,"text":14},{"id":68,"depth":277,"text":69},{"id":97,"depth":277,"text":98},{"id":135,"depth":277,"text":136},{"id":193,"depth":277,"text":194},{"id":247,"depth":277,"text":247},"2026-10-09","K3sのembedded etcdとkubeadmのstacked\u002Fexternal etcd、HA構成のフェイルオーバーは実際どれだけ時間がかかるのか。公式ドキュメントのRTO目安と実運用の体感時間のギャップを、障害ドメインの分離・必要ノード数の違いから検証する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap",{"title":5,"description":286},"blog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap",[296,297,298,299,300],"k3s","kubernetes","etcd","high-availability","kubeadm","Kz-bbhRSxajCSv46aJZpBxGxfNtUIf4s1qWxfLXzv_Y",[303,311,319,328,338,346],{"path":304,"title":305,"description":306,"date":307,"tags":308},"\u002Fblog\u002Fja\u002Fk3s-etcd-snapshot-restore-token-cluster-reset-pitfalls","自動etcdスナップショットは毎日取れていた。K3sのリストアが本番障害で動かなかった理由","K3sのetcdスナップショットは正常に取れていたのに、本番障害でリストアが失敗した——トークン管理、S3リストア事故、cluster-resetの落とし穴という3つの実例から、embedded etcdバックアップの本当のリスクを解説する。","2026-09-21",[296,297,298,309,310,299],"backup-restore","disaster-recovery",{"path":312,"title":313,"description":314,"date":315,"tags":316},"\u002Fblog\u002Fja\u002Fk3s-proxmox-live-migration-etcd-quorum-affinity-design","Proxmoxのライブマイグレーションで、K3sのetcdクォーラムが静かに崩れる。仮想化とRaftが衝突する設計","Proxmox上のK3sコントロールプレーンVMをライブマイグレーションした際にetcdクォーラムが崩れる仕組みを、heartbeat\u002Felection-timeoutとProxmoxのaffinity設計から解説。実運用で使える具体的な対策手順を紹介する。","2026-09-09",[296,297,317,298,318,299],"proxmox","live-migration",{"path":320,"title":321,"description":322,"date":323,"tags":324},"\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha","K3sをRKE2に移行して本番が2時間止まった。\"軽量K8s\"選定で見落とされがちな前提","K3s vs RKE2の選定で見落とされがちな前提を、実際の移行障害事例とCIS Hardening・HA構成・ストレージ設計の違いから整理し、本番環境でどちらのKubernetesディストリビューションを選ぶべきか判断基準を具体的に解説する。","2026-10-05",[296,325,297,326,299,327],"rke2","cis-benchmark","production-kubernetes",{"path":329,"title":330,"description":331,"date":332,"tags":333},"\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison","「K3sは軽い」は本当か。Kubernetes標準(kubeadm)とメモリ使用量を実測したら、結果が割れた","K3sは本当に軽いのか。Kubernetes標準のkubeadmとコントロールプレーンのメモリ・CPU使用量を公式データと複数の独立ベンチマークで比較。データストア選択(etcd\u002FSQLite)次第で結果が逆転する理由を解説する。","2026-10-04",[296,297,300,334,335,336,337],"resource-profiling","memory-benchmark","control-plane","datastore-comparison",{"path":339,"title":340,"description":341,"date":342,"tags":343},"\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall","Proxmoxのディスクを無停止で拡張したつもりが、K3sノードには反映されなかった。SATAコントローラという見落とし","Proxmoxで本番運用中のK3sクラスタのストレージが逼迫した時、無停止で拡張したつもりが反映されない典型的な原因(ディスクコントローラ設定)と、CephでOSDを追加する際にK3sのetcdクォーラムが受ける影響、公式ドキュメントに基づく正しい拡張手順を具体的に解説する。","2026-09-17",[296,297,317,344,345,298],"storage","ceph",{"path":347,"title":348,"description":349,"date":350,"tags":351},"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","2026-08-05",[296,297,299,352,353],"multi-az","sre",1792592607813]