[{"data":1,"prerenderedAt":333},["ShallowReactive",2],{"blog-ja-k3s-vs-microk8s-ha-etcd-dqlite-edge-production":3,"blog-related-ja-k3s-vs-microk8s-ha-etcd-dqlite-edge-production":282,"blog-ja-k3s-vs-microk8s-ha-etcd-dqlite-edge-production-alt":270},{"id":4,"title":5,"author":6,"body":7,"date":264,"description":265,"extension":266,"image":267,"locale":268,"meta":269,"navigation":270,"path":271,"seo":272,"stem":273,"tags":274,"__hash__":281},"blog\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production.md","K3sとMicroK8s、同じ\"軽量\"でも本番で勝つのはどちらか。dqliteとetcdが分けるHA構成の分岐点","Kubo Team",{"type":8,"value":9,"toc":254},"minimark",[10,15,23,30,47,56,60,66,74,82,97,100,104,110,113,120,133,144,152,156,162,165,178,181,184,188,194,197,219,222,226,229,241],[11,12,14],"h2",{"id":13},"_1-なぜ軽量kubernetesを一括りにすると判断を誤るか","1. なぜ\"軽量Kubernetes\"を一括りにすると判断を誤るか",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Fsection01.webp",[16,24,25,29],{},[26,27,28],"strong",{},"K3s vs MicroK8s"," という比較は、「どちらも軽量だから好きな方で良い」という結論で終わりがちです。しかし実際にエッジや本番環境でクラスタを運用する立場からすると、この2つは思想の異なる別物です。",[16,31,32,33,40,41,46],{},"K3sはRancher（現SUSEの一部門）が開発したプロジェクトです。",[34,35,39],"a",{"href":36,"rel":37},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fk3s\u002F",[38],"nofollow","CNCF公式","によると、K3sは2020年8月19日にCNCF Sandboxプロジェクトとして受け入れられています。",[34,42,45],{"href":43,"rel":44},"https:\u002F\u002Fthenewstack.io\u002Franchers-k3s-joins-cncf-sandbox-as-first-kubernetes-distribution\u002F",[38],"The New Stackの報道","は、これをCNCF Sandboxに入った最初のKubernetesディストリビューションだと伝えています。一方のMicroK8sはCanonical（Ubuntuの開発元）が提供する、snapパッケージ前提の軽量Kubernetesです。",[16,48,49,50,55],{},"出自が違えば、リソース設計もHA（高可用性）の実装方式もアップグレードの考え方も異なります。「軽量Kubernetesなら何でも同じ」という前提のまま選定すると、本番運用に入ってから想定外の運用負荷に直面することになります。本記事では、公式ドキュメントのデータをもとに両者の実務上の差を整理します。なお、この選定そのものに時間を使いたくない場合は、",[34,51,54],{"href":52,"rel":53},"https:\u002F\u002Fkubo.hexabase.io\u002F",[38],"Kubo","のようなマネージドK3sという第三の選択肢もあります。",[11,57,59],{"id":58},"_2-k3sとmicrok8sリソース要件とインストール方式の実測差","2. K3sとMicroK8s、リソース要件とインストール方式の実測差",[16,61,62],{},[19,63],{"alt":64,"src":65},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Fsection02.webp",[16,67,68,73],{},[34,69,72],{"href":70,"rel":71},"https:\u002F\u002Fdocs.k3s.io\u002Finstallation\u002Frequirements",[38],"K3sの公式ドキュメント","によると、サーバーノードは2コア\u002F2GBのRAM、エージェントノードは1コア\u002F512MBのRAMが最小要件です。これはK3s自体とパッケージされたコンポーネントの基本要件であり、ワークロードが消費するリソースは別途必要になります。対応アーキテクチャはx86_64、armhf、arm64\u002Faarch64で、Raspberry Piのような小型デバイスでも動作します。",[16,75,76,81],{},[34,77,80],{"href":78,"rel":79},"https:\u002F\u002Francher.com\u002Fproducts\u002Fk3s",[38],"Rancherの製品ページ","では、K3sは単一バイナリとして配布され、サイズは40MB未満であると説明されています。依存コンポーネントを削減し、単一バイナリに集約する設計思想が、この軽さを実現しています。",[16,83,84,85,90,91,96],{},"一方の",[34,86,89],{"href":87,"rel":88},"https:\u002F\u002Fcanonical.com\u002Fmicrok8s",[38],"MicroK8s","は、「Zero-ops, pure-upstream, HA Kubernetes」というコンセプトで提供されており、snapパッケージとして最小限のセットアップで完全なクラスタを構築できます。Linuxではsnap経由、macOSではHomebrew経由、Windowsでは専用インストーラーでインストールできるなど、対応OSの幅広さがK3sとの違いです。",[34,92,95],{"href":93,"rel":94},"https:\u002F\u002Fcanonical.com\u002Fblog\u002Fcanonical-launches-microk8s-deploy-kubernetes-in-seconds",[38],"Canonicalの公式ブログ","では、単一コマンドでの展開とSnapストアによる自動更新が特徴として挙げられています。",[16,98,99],{},"K3sが「最小リソースでの単体動作」に振り切っているのに対し、MicroK8sは「マルチOS対応と運用の自動化」を優先した設計であることが、ここまでの比較だけでも見えてきます。",[11,101,103],{"id":102},"_3-k3s-vs-microk8sha構成の分岐点-embedded-etcdとdqlite","3. K3s vs MicroK8s、HA構成の分岐点 ― embedded etcdとdqlite",[16,105,106],{},[19,107],{"alt":108,"src":109},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Fsection03.webp",[16,111,112],{},"両者の設計思想が最もはっきり分かれるのが、HA（高可用性）構成におけるデータストアです。",[16,114,115,119],{},[34,116,72],{"href":117,"rel":118},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore",[38],"によると、K3sはシングルノード構成ではSQLiteをデフォルトのデータストアとして使用します。これは「他のデータストア構成が存在せず、ディスク上に埋め込みetcdのデータベースファイルが存在しない場合」に使われる選択肢であり、複数サーバーを持つクラスタでは使用できません。複数サーバーでのHA構成にする場合は、embedded etcd（組み込みetcd）に切り替える設計です。",[16,121,122,123,128,129,132],{},"対してMicroK8sは、",[34,124,127],{"href":125,"rel":126},"https:\u002F\u002Fcanonical.com\u002Fmicrok8s\u002Fdocs\u002Fhigh-availability",[38],"Canonicalの公式ドキュメント","によれば、3台以上のノードでクラスタを構成すると自動的にHAが有効になり、分散SQLiteである",[26,130,131],{},"dqlite","がKubernetesの状態管理を担います。ノードはVoter（投票者：データベース複製とリーダー選出に参加）、Standby（待機：複製のみ）、Spare（予備：複製に関与しない）の3役に自動分類され、リーダー障害時は最大5秒で新リーダーが選出、Standbyノードの投票者への昇格には最大30秒を要するとされています。",[16,134,135,136,139,140,143],{},"つまり、",[26,137,138],{},"K3sはHAをオプトインの構成変更（SQLite→embedded etcd）として扱う","のに対し、",[26,141,142],{},"MicroK8sはノード数という条件を満たせば自動的にHAへ移行する","設計です。前者はシングルノードから始めて必要になった時点でHA化する運用に向き、後者は最初から複数ノードでの冗長性を前提にした構成に向いています。クォーラム設計を自分たちでどこまで意識する必要があるかという運用負荷の差が、ここに表れます。",[16,145,146,147,151],{},"Kuboのようなマネージド",[34,148,150],{"href":52,"rel":149},[38],"K3s","サービスを使う場合、このembedded etcdのクォーラム管理自体を意識する必要がなくなる点は、HA構成の複雑さに悩むチームにとって検討材料になるはずです。",[11,153,155],{"id":154},"_4-アドオン運用とアップグレードの思想差","4. アドオン運用とアップグレードの思想差",[16,157,158],{},[19,159],{"alt":160,"src":161},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Fsection04.webp",[16,163,164],{},"HA構成だけでなく、日常の運用面でも両者の思想は分かれます。",[16,166,167,168,172,173,177],{},"MicroK8sは",[169,170,171],"code",{},"microk8s enable","コマンド一つで、DNS、Ingress、Dashboard、Prometheus、Istio、LinkerD、Knativeといったアドオンを有効化できます。",[34,174,176],{"href":87,"rel":175},[38],"Canonicalのドキュメント","にあるとおり、必要な機能をモジュールとして後から足していく運用が前提です。また、Snapパッケージである特性上、自動更新の仕組みが標準で組み込まれており、Ubuntu Proのサブスクリプションを契約すれば99.9%のアップタイム保証とセキュリティメンテナンスも受けられます。",[16,179,180],{},"K3sは対照的に、最小構成の単一バイナリから出発し、Helmチャートなどを使って必要なコンポーネントを自分たちで足していく思想です。アップグレードについても、Snapのような自動更新の仕組みを標準搭載せず、運用チームがタイミングを制御する前提になっています。",[16,182,183],{},"この違いは「運用を自動化に委ねるか、自分たちで制御するか」というトレードオフです。前者は初速が早く属人化しにくい一方、後者は変更点を把握しやすく意図しないタイミングでの挙動変化を防ぎやすいという利点があります。GitOpsでHelmチャートのバージョンを明示的に管理したいチームには、K3s寄りの思想が合うケースが多いでしょう。",[11,185,187],{"id":186},"_5-エッジ本番のどちらで選ぶべきか-判断フレーム","5. エッジ\u002F本番のどちらで選ぶべきか ― 判断フレーム",[16,189,190],{},[19,191],{"alt":192,"src":193},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Fsection05.webp",[16,195,196],{},"ここまでの比較を踏まえると、選定の判断軸は次の3つに整理できます。",[198,199,200,207,213],"ul",{},[201,202,203,206],"li",{},[26,204,205],{},"リソース制約が最優先か",": エッジデバイスやIoT機器のようにメモリ・CPUが限られる環境では、サーバー2コア\u002F2GB・エージェント1コア\u002F512MBというK3sの最小要件が有利です",[201,208,209,212],{},[26,210,211],{},"開発環境と本番のOSを揃えたいか",": macOSやWindowsでも同じ構成を再現したい場合は、マルチOS対応のMicroK8sが選択肢になります",[201,214,215,218],{},[26,216,217],{},"HA構成を誰がどう設計するか",": embedded etcdのクォーラム設計を自分たちで制御したいならK3s、ノード数ベースで自動化されたdqlite HAに任せたいならMicroK8sという分かれ方になります",[16,220,221],{},"どちらもCNCF Certified Kubernetes Conformance Programに適合した標準Kubernetes APIと互換性があるため、アプリケーション側の移植性で大きな差は生まれません。差が出るのは、クラスタそのものの運用をどこまで自分たちで引き受けるかという点です。",[11,223,225],{"id":224},"_6-まとめ","6. まとめ",[16,227,228],{},"K3sとMicroK8sは、どちらも「軽量Kubernetes」というカテゴリで語られがちですが、HA構成の実装（embedded etcd vs dqlite）、インストール・アップデートの思想（手動制御 vs 自動化）、対応OSの幅という3点で明確に異なります。「軽量だから」という理由だけで選ぶのではなく、自分たちのチームがHA構成の運用負荷をどこまで引き受けられるかで判断するのが、本番運用で後悔しない選び方です。",[16,230,231,232,235,236,240],{},"そのHA構成の運用負荷自体をなくしたい場合、選択肢になるのが",[34,233,54],{"href":52,"rel":234},[38],"です。KuboはK3sベースのマネージドKubernetesサービスで、embedded etcdのクォーラム設計やアップグレードのタイミング管理をKubo側が引き受けます。月額48,000円〜という、AWS EKS（月額82,700円）の約58%のコストでフルスペックのK8s機能を使える点も特徴です。K3sかMicroK8sかで迷う時間を、運用自体をなくす方向で解決したいチームは、",[34,237,239],{"href":52,"rel":238},[38],"Kubo Cloud","の構成を確認してみてください。",[16,242,243,244,247,248,253],{},"エッジ環境でのK3s活用を検討している場合は、",[34,245,54],{"href":52,"rel":246},[38],"のK3sベースの軽量構成がそのままエッジ展開にも対応できます。オンプレミスでデータ主権を維持したまま同様の比較検討をしたい場合は、",[34,249,252],{"href":250,"rel":251},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[38],"Kubo On-Premise","という選択肢もあります。",{"title":255,"searchDepth":256,"depth":256,"links":257},"",2,[258,259,260,261,262,263],{"id":13,"depth":256,"text":14},{"id":58,"depth":256,"text":59},{"id":102,"depth":256,"text":103},{"id":154,"depth":256,"text":155},{"id":186,"depth":256,"text":187},{"id":224,"depth":256,"text":225},"2026-10-25","K3sとMicroK8s、同じ軽量Kubernetesでも本番運用の明暗を分けるのはHA構成だ。K3sのembedded etcdとMicroK8sのdqlite、それぞれの最小RAM要件・アーキテクチャの違いを公式ドキュメントのデータで比較し、選定基準を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production",{"title":5,"description":265},"blog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production",[275,276,277,278,279,280],"k3s","microk8s","kubernetes","high-availability","edge-computing","comparison","Ar0zjvcz08IiOBgzieNDJJqx-QeDjkxD4tSSNa-djqk",[283,291,299,308,316,324],{"path":284,"title":285,"description":286,"date":287,"tags":288},"\u002Fblog\u002Fja\u002Fk3s-prometheus-agent-mode-stale-marker-edge-monitoring","K3sエッジのPrometheusをAgent modeにしたら、ターゲットが消えた瞬間にメトリクスも消えていた","K3sエッジクラスタでPrometheus Agent modeを使うと、ターゲット消失時のstale marker処理次第で中央監視に古い値が残り続けることがある。K3s edge環境の監視設計とつまずきポイントを解説する。","2026-11-03",[275,277,289,279,290],"prometheus","observability",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fja\u002Fk3s-system-upgrade-controller-plan-stuck-node-drain","Planは消えずに残っていた。K3sのsystem-upgrade-controllerが止まり続けた理由","K3sのsystem-upgrade-controllerで自動アップグレードを組んだら、特定ノードだけPlanが進まなくなった。原因はPodDisruptionBudgetとtaintの盲点。仕組みと復旧手順、Kuboでの解決策を解説する。","2026-10-31",[275,277,297,298,279],"system-upgrade-controller","rolling-upgrade",{"path":300,"title":301,"description":302,"date":303,"tags":304},"\u002Fblog\u002Fja\u002Fk3s-spegel-embedded-registry-mirror-airgap-node-join","K3sの組み込みレジストリミラーが効いているはずなのに、新しいエッジノードだけimage pullに失敗した","K3sの組み込みレジストリミラー（Spegel）はクラスタ全体で有効なはずが、新規追加したエッジノードだけimage pullに失敗した。原因はregistries.yamlの未配布と認証ドリフト、containerd 2.0の既知バグ。エアギャップ運用の正しい配布手順を解説する。","2026-10-30",[275,277,305,306,307,279],"spegel","registry-mirror","airgap",{"path":309,"title":310,"description":311,"date":312,"tags":313},"\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison","エッジでetcdを固定されるのは罠か前提か。K3sとMicroShift、OSTree自動ロールバックの代償を比較する","K3sとMicroShiftはどちらも「軽量Kubernetes」と語られるが、データストアとOS更新モデルの前提が根本的に違う。etcd固定とOSTree自動ロールバックの実態を比較し、エッジ本番運用でどちらを選ぶべきかを整理する。","2026-10-29",[275,314,277,279,315],"microshift","redhat",{"path":317,"title":318,"description":319,"date":320,"tags":321},"\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",[275,277,322,278,323],"etcd","kubeadm",{"path":325,"title":326,"description":327,"date":328,"tags":329},"\u002Fblog\u002Fja\u002Fk3s-rke2-migration-production-downtime-cis-ha","K3sをRKE2に移行して本番が2時間止まった。\"軽量K8s\"選定で見落とされがちな前提","K3s vs RKE2の選定で見落とされがちな前提を、実際の移行障害事例とCIS Hardening・HA構成・ストレージ設計の違いから整理し、本番環境でどちらのKubernetesディストリビューションを選ぶべきか判断基準を具体的に解説する。","2026-10-05",[275,330,277,331,278,332],"rke2","cis-benchmark","production-kubernetes",1793798698477]