[{"data":1,"prerenderedAt":337},["ShallowReactive",2],{"blog-ja-k3s-rke2-migration-production-downtime-cis-ha":3,"blog-related-ja-k3s-rke2-migration-production-downtime-cis-ha":286,"blog-ja-k3s-rke2-migration-production-downtime-cis-ha-alt":274},{"id":4,"title":5,"author":6,"body":7,"date":268,"description":269,"extension":270,"image":271,"locale":272,"meta":273,"navigation":274,"path":275,"seo":276,"stem":277,"tags":278,"__hash__":285},"blog\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha.md","K3sをRKE2に移行して本番が2時間止まった。\"軽量K8s\"選定で見落とされがちな前提","Kubo Team",{"type":8,"value":9,"toc":258},"minimark",[10,15,23,26,37,51,54,58,64,73,87,106,110,116,119,137,148,152,158,161,173,180,184,190,193,215,222,236,245,248,251],[11,12,14],"h2",{"id":13},"k3sクラスタをrke2に上げたら本番だけが落ちた","K3sクラスタをRKE2に上げたら、本番だけが落ちた",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Fsection01.webp",[16,24,25],{},"K3s vs RKE2——どちらも「軽量」「CNCF認定」という共通点を持つKubernetesディストリビューションだ。だからこそ、この比較を機能表だけで済ませ、移行や選定を軽く見てしまうケースが後を絶たない。",[16,27,28,29,36],{},"実際にあった事例を見てみよう。ある運用チームが2つのK3sクラスタをRKE2へ移行した。テスト環境(VM10台)では何の問題もなく完了した。ところが本番環境、しかもエアギャップ構成のベアメタル30台では、約2時間のダウンタイムが発生した(",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fgithub.com\u002Francher\u002Frke2\u002Fdiscussions\u002F7627",[34],"nofollow","rancher\u002Frke2 Discussion #7627",")。",[16,38,39,40,45,46,36],{},"原因は、K3sのcontrol-planeノードに付けていたtaintが、RKE2のインストール処理と非互換だったことだ。RKE2が標準で使うCanal CNI(CalicoベースのCNI)が、そのtaintのせいでインストールを拒否してしまった。別の移行事例では、RancherがRKE2クラスタを誤って「K3s」として再登録し、存在しないアップグレードを試みてクラスタがスケジュール不能状態に陥ったという報告もある(",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Fgithub.com\u002Francher\u002Francher\u002Fissues\u002F46776",[34],"rancher\u002Francher Issue #46776",")。Backup\u002FRestore Operatorを使った移行後、クラスタがActive状態に復帰するまで想定の2〜5分ではなく7〜15分かかったケースも確認されている(",[30,47,50],{"href":48,"rel":49},"https:\u002F\u002Fgithub.com\u002Francher\u002Francher\u002Fissues\u002F42834",[34],"rancher\u002Francher Issue #42834",[16,52,53],{},"どちらも「ドキュメント通りに進めた」上で起きた話だ。K3s vs RKE2の選定・移行で本当に見落とされがちなのは、機能差そのものより「前提条件の違い」であることが、ここからわかる。",[11,55,57],{"id":56},"k3s-vs-rke2そもそも何が違うのか","K3s vs RKE2、そもそも何が違うのか",[16,59,60],{},[19,61],{"alt":62,"src":63},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Fsection02.webp",[16,65,66,67,72],{},"K3s vs RKE2の違いを整理する前に、まず共通点を押さえておきたい。両者とも",[30,68,71],{"href":69,"rel":70},"https:\u002F\u002Fwww.suse.com\u002Fc\u002Francher_blog\u002Fwhen-to-use-k3s-and-rke2\u002F",[34],"CNCF認定のKubernetesディストリビューション","であり、単一バイナリでのインストール、system-upgrade-controllerによる自動アップグレードなど、運用の手軽さを重視した設計思想を共有している。",[16,74,75,76,80,81,86],{},"違いが大きく出るのはデータストアだ。K3sは",[77,78,79],"strong",{},"SQLiteがデフォルトのデータストア","で、他の設定が存在しない場合に自動的に使われる。組み込みetcdは、K3sが新規etcdクラスタの初期化やetcdクラスタへの参加を設定された場合、あるいはディスク上にetcdのデータベースファイルが存在する場合にのみ自動選択される(",[30,82,85],{"href":83,"rel":84},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore",[34],"K3s公式ドキュメント",")。つまりK3sで複数サーバーのHA構成を組むには、明示的にetcdを選択する必要がある。",[16,88,89,90,93,94,99,100,105],{},"一方RKE2は、",[77,91,92],{},"組み込みetcd一択","だ。SQLiteという選択肢自体が存在しない。これは裏を返せば、RKE2の方が「本番運用を前提にした設計」になっているとも言える。CIS Hardeningの面でも差は明確で、RKE2は",[30,95,98],{"href":96,"rel":97},"https:\u002F\u002Fdocs.rke2.io\u002Fsecurity\u002Fhardening_guide",[34],"hardened by defaultとして設計されており、CISコントロールの大多数に追加修正なしで準拠する","。K3sはCIS Benchmarkへの部分対応にとどまり、本番相当の水準に引き上げるには運用者側での追加設定が必要になる(",[30,101,104],{"href":102,"rel":103},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-rke2-vs-k3s\u002Fview",[34],"oneuptime.comの比較記事",")。FIPS 140-2準拠ビルドやDISA STIG認定も、現状RKE2のみが対応している。",[11,107,109],{"id":108},"ha構成で要求される前提条件の違い","HA構成で要求される前提条件の違い",[16,111,112],{},[19,113],{"alt":114,"src":115},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Fsection03.webp",[16,117,118],{},"HA構成を組む際の実務要件も、K3s vs RKE2で細部が異なる。",[16,120,121,122,126,127,132,133,136],{},"RKE2のHA構成では、まずサーバーノードを**奇数個(3台推奨)**用意する必要がある。これはetcdがクォーラム(過半数の合意)を維持するための制約だ。その上で、サーバーノード群の前段に「固定登録アドレス」を配置する。実装方法はレイヤー4(TCP)ロードバランサー、ラウンドロビンDNS、仮想\u002F弾性IPアドレスのいずれでもよい。",[123,124,125],"code",{},"rke2 server","プロセスはノード登録をポート9345で、Kubernetes APIをポート6443でそれぞれリッスンする(",[30,128,131],{"href":129,"rel":130},"https:\u002F\u002Fdocs.rke2.io\u002Finstall\u002Fha",[34],"RKE2公式ドキュメント",")。固定登録アドレスを使う場合は、証明書エラーを避けるために",[123,134,135],{},"tls-san","パラメータで追加のホスト名・IPをサーバー証明書のSANに含めておく必要がある。",[16,138,139,140,143,144,147],{},"K3sも組み込みetcdでHAを組む場合は同様に奇数ノードが必須で、最初のサーバーノードは",[123,141,142],{},"--cluster-init","オプションで起動しなければならない。つまり「K3sは手軽、RKE2は面倒」という単純な図式ではなく、",[77,145,146],{},"HAを前提にした瞬間、両者とも同程度の設計知識が要求される","という点は押さえておきたい。",[11,149,151],{"id":150},"ストレージとネットワークの無方針がもたらす落とし穴","ストレージとネットワークの\"無方針\"がもたらす落とし穴",[16,153,154],{},[19,155],{"alt":156,"src":157},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Fsection04.webp",[16,159,160],{},"比較表には出てこないが、実務で効いてくるのがストレージの初期設計だ。",[16,162,163,164,167,168,36],{},"K3sはデフォルトで",[77,165,166],{},"local-path-provisioner","が標準StorageClassとして設定される。これはノードローカルディスクを前提にした仕組みで、PersistentVolumeClaimは作成時に暗黙的に特定ノードへ紐付く。結果として、ノードのドレインやOSパッチ適用のたびに、該当Podが別ノードに移動できずダウンタイムが発生しやすくなる(",[30,169,172],{"href":170,"rel":171},"https:\u002F\u002Fsimplyblock.io\u002Fblog\u002Fk3s-vs-k8s-rke2-talos-storage-assumptions\u002F",[34],"K3s\u002FRKE2\u002FTalosのストレージ前提を比較した記事",[16,174,175,176,179],{},"一方RKE2は、CNIとIngressコントローラーはバンドルされているが、",[77,177,178],{},"ストレージについては意見を持たない","。デフォルトのStorageClassが存在しないのだ。一見するとK3sより自由度が高いように見えるが、同記事が指摘する通り、本番導入のスケジュールに追われたチームほど、結局は同じノードローカルプロビジョナーを選んでしまい、K3sと同じ落とし穴にはまるケースが多い。「RKE2だからストレージ設計を間違えない」わけではない、という点は見落とされがちだ。",[11,181,183],{"id":182},"結局本番でどちらを選ぶべきか","結局、本番でどちらを選ぶべきか",[16,185,186],{},[19,187],{"alt":188,"src":189},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Fsection05.webp",[16,191,192],{},"ここまでの違いを踏まえると、判断フレームは次のように整理できる。",[194,195,196,203,209],"ul",{},[197,198,199,202],"li",{},[77,200,201],{},"金融・医療・政府機関など、CIS Benchmark・FIPS 140-2・DISA STIGといった第三者監査基準への準拠が必須"," → RKE2が現実的な選択になる。hardened by defaultという設計が監査対応の工数を大きく下げる。",[197,204,205,208],{},[77,206,207],{},"エッジ・IoT・ARMデバイス・開発\u002FCI環境など、リソース制約が強くHA要件が緩い"," → K3sの軽量さが活きる。",[197,210,211,214],{},[77,212,213],{},"本番でHAを組む場合"," → K3s・RKE2のどちらを選んでも、奇数ノードのetcdクォーラム設計、証明書のSAN設定、ストレージのノードアフィニティ対策は避けて通れない。",[16,216,217,218,221],{},"つまり「K3s vs RKE2」という問いの本質は、技術的な優劣比較ではなく、",[77,219,220],{},"自分たちのチームがHA構成・CIS準拠・ストレージ設計を自前で運用し続けられるか","という体制の問題だ。ここを見誤ると、冒頭の事例のように「ドキュメント通りに進めたのに本番だけ落ちた」という事態を招く。",[16,223,224,225,230,231,235],{},"この運用負荷そのものを引き受ける選択肢として、マネージドK8sサービスの",[30,226,229],{"href":227,"rel":228},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","がある。KuboはK3sベースにRancher管理基盤を組み合わせており、HA構成の設計・etcdのバックアップ運用・証明書管理をマネージド側で担保する。「K3sの軽量さ」と「RKE2相当の運用品質」を自前で両立させる代わりに、",[30,232,234],{"href":227,"rel":233},[34],"Kubo Cloud","ならAI-Driven DeploymentとCaptain UIを通じて、AWS EKSの約58%・Azure AKSの約56%というコスト感覚で本番品質のK3s運用を始められる。",[16,237,238,239,244],{},"金融・医療・政府機関などCIS\u002FFIPS相当の監査対応がそもそもの前提になる環境では、データ主権を自社管理下に置ける",[30,240,243],{"href":241,"rel":242},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise","が選択肢になる。Air-Gapped環境にも対応しており、「RKE2を自前でCIS準拠運用する工数」をまるごと引き受けられる設計だ。",[11,246,247],{"id":247},"まとめ",[16,249,250],{},"K3s vs RKE2の比較は、バイナリサイズやデータストアといった機能表だけでは終わらない。CIS Hardening・FIPS対応・HA構成の前提条件・ストレージ設計、そして移行時の非互換リスクまで含めて検討して初めて、「本番で選ぶならどちらか」に答えが出せる。",[16,252,253,254,257],{},"冒頭の事例が示す通り、taintの非互換のような細部が本番障害に直結する。選定・移行を検討する際は、機能比較だけでなく実際の移行報告や公式のHardening Guideまで目を通しておくことを勧めたい。そして、その運用負荷自体を引き受けたいと感じたら、",[30,255,229],{"href":227,"rel":256},[34],"のようなマネージドK8sサービスを検討する価値は十分にある。",{"title":259,"searchDepth":260,"depth":260,"links":261},"",2,[262,263,264,265,266,267],{"id":13,"depth":260,"text":14},{"id":56,"depth":260,"text":57},{"id":108,"depth":260,"text":109},{"id":150,"depth":260,"text":151},{"id":182,"depth":260,"text":183},{"id":247,"depth":260,"text":247},"2026-10-05","K3s vs RKE2の選定で見落とされがちな前提を、実際の移行障害事例とCIS Hardening・HA構成・ストレージ設計の違いから整理し、本番環境でどちらのKubernetesディストリビューションを選ぶべきか判断基準を具体的に解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha",{"title":5,"description":269},"blog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha",[279,280,281,282,283,284],"k3s","rke2","kubernetes","cis-benchmark","high-availability","production-kubernetes","3I1tFBjfOjQolovpIFjD2h6oaFLbjEGrkCg-9nwVO14",[287,295,303,311,319,327],{"path":288,"title":289,"description":290,"date":291,"tags":292},"\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap","RTO30秒のはずが3分止まった。K3sとkubeadmのHA構成で\"カタログ値\"と\"実運用\"がズレる理由","K3sのembedded etcdとkubeadmのstacked\u002Fexternal etcd、HA構成のフェイルオーバーは実際どれだけ時間がかかるのか。公式ドキュメントのRTO目安と実運用の体感時間のギャップを、障害ドメインの分離・必要ノード数の違いから検証する。","2026-10-09",[279,281,293,283,294],"etcd","kubeadm",{"path":296,"title":297,"description":298,"date":299,"tags":300},"\u002Fblog\u002Fja\u002Fk3s-etcd-snapshot-restore-token-cluster-reset-pitfalls","自動etcdスナップショットは毎日取れていた。K3sのリストアが本番障害で動かなかった理由","K3sのetcdスナップショットは正常に取れていたのに、本番障害でリストアが失敗した——トークン管理、S3リストア事故、cluster-resetの落とし穴という3つの実例から、embedded etcdバックアップの本当のリスクを解説する。","2026-09-21",[279,281,293,301,302,283],"backup-restore","disaster-recovery",{"path":304,"title":305,"description":306,"date":307,"tags":308},"\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",[279,281,309,293,310,283],"proxmox","live-migration",{"path":312,"title":313,"description":314,"date":315,"tags":316},"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","2026-08-05",[279,281,283,317,318],"multi-az","sre",{"path":320,"title":321,"description":322,"date":323,"tags":324},"\u002Fblog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design","FIFAワールドカップの中継は、なぜ絶対に途切れないのか。放送業界の二重伝送に学ぶKubernetesの本当の高可用性設計","Kubernetesの高可用性は「レプリカを増やす」だけでは実現しない。放送業界のSMPTE ST 2022-7二重伝送技術を手がかりに、Topology Spread ConstraintsとマルチAZ設計の本質を解説する。","2026-07-20",[281,279,283,325,318,326],"topology-spread-constraints","managed-kubernetes",{"path":328,"title":329,"description":330,"date":331,"tags":332},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[279,281,333,334,335,336],"hpa","containerresource","autoscaling","service-mesh",1792592610648]