[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"blog-ja-k3s-microshift-etcd-ostree-edge-comparison":3,"blog-related-ja-k3s-microshift-etcd-ostree-edge-comparison":274,"blog-ja-k3s-microshift-etcd-ostree-edge-comparison-alt":263},{"id":4,"title":5,"author":6,"body":7,"date":257,"description":258,"extension":259,"image":260,"locale":261,"meta":262,"navigation":263,"path":264,"seo":265,"stem":266,"tags":267,"__hash__":273},"blog\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison.md","エッジでetcdを固定されるのは罠か前提か。K3sとMicroShift、OSTree自動ロールバックの代償を比較する","Kubo Team",{"type":8,"value":9,"toc":247},"minimark",[10,15,23,26,42,57,66,70,76,85,98,105,108,112,118,127,130,133,140,148,152,158,165,168,172,178,187,190,199,203,206,222,225,231,244],[11,12,14],"h2",{"id":13},"軽量kubernetesという言葉でひとくくりにしてはいけない","「軽量Kubernetes」という言葉でひとくくりにしてはいけない",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection01.webp",[16,24,25],{},"K3sとMicroShift。どちらも「エッジ向けの軽量Kubernetes」として紹介されることが多く、比較検討の俎上に載せられがちだ。しかし実際にアーキテクチャを読み比べると、両者は「軽量化」のアプローチからして別物であることが分かる。",[16,27,28,29,36,37,41],{},"MicroShiftは、Red Hatがエッジ向けに提供する単一ノード向けのコンテナオーケストレーションランタイムだ。Red Hat Enterprise Linux（RHEL）上で動作する「アプリケーション」という位置づけで、ネットワーキング・Ingress・ストレージといったKubernetesの必須機能に対象を絞っている（",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fdocs.redhat.com\u002Fen\u002Fdocumentation\u002Fred_hat_build_of_microshift\u002F4.19\u002Fhtml-single\u002Funderstanding_microshift\u002Funderstanding_microshift",[34],"nofollow","Red Hat公式ドキュメント「Understanding MicroShift」","）。重要なのは、MicroShiftがKubernetesの標準コンポーネントを",[38,39,40],"strong",{},"置き換えない","という設計方針だ。",[16,43,44,45,50,51,56],{},"一方K3sは、Kubernetesのコントロールプレーン全体を単一バイナリ（100MB未満）にパッケージ化した、完全準拠かつCNCF認定のディストリビューションである（",[30,46,49],{"href":47,"rel":48},"https:\u002F\u002Fdocs.k3s.io\u002F",[34],"K3s公式ドキュメント","）。K3sは2020年8月にCNCF Sandboxプロジェクトとして受け入れられており（",[30,52,55],{"href":53,"rel":54},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fk3s\u002F",[34],"CNCF公式プロジェクトページ","）、OSやディストリビューションを問わず単一バイナリで動く点が最大の特徴だ。",[16,58,59,60,65],{},"つまり、MicroShiftは「RHELというOSの上でKubernetesの必須機能だけを動かす」設計であり、K3sは「どのLinux環境でもKubernetesフルスタックを1バイナリで動かす」設計である。この出発点の違いが、以降で見るデータストア・OS更新モデル・サポート体制のすべてに波及している。クラウドだけでなくエッジでも同じK3sをマネージドで動かしたい場合、この設計思想の違いは",[30,61,64],{"href":62,"rel":63},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようなK3sベースのサービスを検討する際の判断材料にもなる。",[11,67,69],{"id":68},"データストアの選択肢-k3sの柔軟性とmicroshiftのetcd固定","データストアの選択肢 — K3sの柔軟性とMicroShiftのetcd固定",[16,71,72],{},[19,73],{"alt":74,"src":75},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection02.webp",[16,77,78,79,84],{},"Kubernetesのコントロールプレーンは、クラスタの全状態を保持する「唯一の真実のソース」としてetcdのようなキーバリューストアを必要とする（",[30,80,83],{"href":81,"rel":82},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Foverview\u002Fcomponents\u002F",[34],"Kubernetes公式ドキュメント","）。この部分の実装方針が、K3sとMicroShiftでは大きく異なる。",[16,86,87,88,91,92,97],{},"K3sのデフォルトデータストアは",[38,89,90],{},"組み込みSQLite","だ。ただしSQLiteはマルチサーバー構成では利用できない。HA（高可用性）構成を組む場合は、組み込みetcd、あるいは外部データベース（etcd v3.5.21、MySQL 8.0\u002F8.4、MariaDB 10.11\u002F11.4、PostgreSQL 15.12\u002F16.7\u002F17.3）を選択する（",[30,93,96],{"href":94,"rel":95},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore",[34],"K3s公式ドキュメント：データストア","）。つまりK3sは、単一ノードのエッジ端末ではSQLiteで身軽に、本番のマルチサーバー構成ではetcdや既存の外部DB基盤に乗せる、という使い分けが可能だ。",[16,99,100,101,104],{},"対してMicroShiftは、Kubernetesの標準コンポーネントを置き換えない方針のため、",[38,102,103],{},"データストアは常にetcd","である。選択肢がない代わりに構成がシンプルになり、Kubernetes標準との互換性を保ちやすいというメリットがある。",[16,106,107],{},"この違いは、「エッジ端末のリソース制約に合わせてデータストアを軽くしたい」という要求に対する回答が、K3sでは「ある」、MicroShiftでは「ない」ということを意味する。シングルボードコンピュータのような極小リソース環境を想定するなら、この差は無視できない。",[11,109,111],{"id":110},"os更新モデルの違い-ostreeの自動ロールバックは前提か代償か","OS更新モデルの違い — OSTreeの自動ロールバックは「前提」か「代償」か",[16,113,114],{},[19,115],{"alt":116,"src":117},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection03.webp",[16,119,120,121,126],{},"MicroShiftが真価を発揮するのは、RHEL for Edgeと組み合わせた「Red Hat Device Edge」構成だ。RHEL for EdgeはOSTreeベースのイミュータブルOSで、自動ロールバックや自動バックアップ\u002Fリストア機能を備えている（",[30,122,125],{"href":123,"rel":124},"https:\u002F\u002Fdocs.redhat.com\u002Fen\u002Fdocumentation\u002Fred_hat_build_of_microshift\u002F4.19\u002Fhtml-single\u002Fgetting_ready_to_install_microshift\u002Findex",[34],"Red Hat公式ドキュメント","）。OTA更新・モニタリング・ロギングといった運用機能はMicroShift自体ではなく、OS側（RHEL for Edge）の責務として設計されている。",[16,128,129],{},"これは一見すると大きなメリットに見える。クラスタの更新とOSの更新が一体化し、失敗時には自動でロールバックされる。無人運用の店舗端末や工場のエッジゲートウェイのように、人手をかけられない現場では魅力的な仕組みだ。",[16,131,132],{},"しかしこれは同時に、「RHEL for Edgeというエコシステムに乗ること」が前提条件になることを意味する。OS・ディストリビューション・サブスクリプションの3つがセットで決まってしまうため、既に別のLinuxディストリビューションで標準化している組織や、マルチOS環境を運用している組織にとっては、新たな依存を1つ背負うことになる。",[16,134,135,136,139],{},"K3sはOS非依存で、対応する任意のLinuxディストリビューション上で動く（",[30,137,49],{"href":47,"rel":138},[34],"）。これはOS更新の自動化をK3s自身が提供しないことも意味する。更新戦略は利用者側で設計する必要があるが、裏を返せば既存のOS標準化方針やイメージビルドパイプラインをそのまま活かせる自由度がある。",[16,141,142,143,147],{},"「自動化されている」ことと「縛られている」ことは、エッジインフラの選定においてはしばしば表裏一体だ。",[30,144,146],{"href":62,"rel":145},[34],"Kubo On-Premise","のように、OS更新とK3sクラスタの更新を一体でマネージドが引き受けつつ、特定OSベンダーへの依存を増やさない構成を選べば、この表裏一体のトレードオフ自体を切り離すという選択肢も見えてくる。",[11,149,151],{"id":150},"見落とされがちな初期設定-etcdの暗号化はデフォルトではない","見落とされがちな初期設定 — etcdの暗号化はデフォルトではない",[16,153,154],{},[19,155],{"alt":156,"src":157},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection04.webp",[16,159,160,161,164],{},"MicroShiftのKubernetesオブジェクトはetcdデータベースに保存されるが、公式ドキュメントは「etcdデータはデフォルトで暗号化されない」ことを明記している。機密データを扱う場合は、LUKS（Linux Unified Key Setup）でディスクを暗号化する、あるいはストレージプラグイン自体を無効化するといった追加の設定判断が必要になる（",[30,162,125],{"href":123,"rel":163},[34],"）。",[16,166,167],{},"「エッジ向けに最適化された製品だから、セキュリティも初期状態で安全なはず」という思い込みは禁物だ。これはMicroShift固有の弱点というより、K3sのSQLiteやetcdでも同様に、ディスク暗号化や静止時のデータ保護は利用者側の責務として残る点に注意したい。どちらのディストリビューションを選んでも、「データストアの暗号化設定を明示的に確認する」というチェック項目は本番導入のチェックリストから外せない。",[11,169,171],{"id":170},"商用サポートとライフサイクル-red-hat-device-edgeとsuserancherの違い","商用サポートとライフサイクル — Red Hat Device EdgeとSUSE\u002FRancherの違い",[16,173,174],{},[19,175],{"alt":176,"src":177},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection05.webp",[16,179,180,181,186],{},"Red Hatは「Red Hat build of MicroShift Life Cycle Policy」を公開しており、バージョンごとのFull Support Phaseやサポート終了時期が定義されている（",[30,182,185],{"href":183,"rel":184},"https:\u002F\u002Faccess.redhat.com\u002Fnode\u002F7086005",[34],"Red Hatライフサイクルポリシー","）。つまりMicroShiftは、商用プロダクトとしてサポート期間が明示的に管理される段階に入っている。RHELサブスクリプションの傘のもとで、OS・クラスタ・サポート窓口が一本化される点は、エンタープライズの調達プロセスと相性が良い。",[16,188,189],{},"K3sはCNCF認定のOSSであり、プロジェクト自体の商用サポートはSUSE\u002FRancherが提供するRancher Prime等の契約に依存する。OSSとしての開発コミュニティの透明性・ディストリビューション非依存という柔軟性を取るか、単一ベンダーのサブスクリプションに統合されたサポート体系を取るかは、組織のガバナンス方針次第だ。",[16,191,192,193,198],{},"学術研究の領域でも、軽量Kubernetesディストリビューションの比較は進んでいる。k0s・K3s・KubeEdge・OpenYurtを対象に、セキュリティ準拠性・ネットワーク障害への耐性・保守性の観点から比較した論文では、k3sやk0sは開発のしやすさに優れる一方でセキュリティ準拠性の面ではトレードオフを抱えることが指摘されている（",[30,194,197],{"href":195,"rel":196},"https:\u002F\u002Farxiv.org\u002Fabs\u002F2503.04815",[34],"arXiv:2503.04815","）。この論文自体はMicroShiftを直接の比較対象にしていないが、「シンプルさ・開発容易性」と「セキュリティ・堅牢性」がトレードオフになるという指摘は、本記事で見てきたMicroShiftのetcd固定・OSTree自動化による堅牢性と、K3sの柔軟性との対比にも通じる論点だ。軽量Kubernetesの選定は、単なる「リソース使用量の比較」を超えて、こうしたトレードオフをどう評価するかというガバナンスの問題になりつつある。",[11,200,202],{"id":201},"まとめどちらを選ぶべきか","まとめ：どちらを選ぶべきか",[16,204,205],{},"K3sとMicroShiftは、どちらも「エッジでKubernetesを動かす」という同じ目的を持ちながら、前提とする運用モデルがまったく異なる。",[207,208,209,216],"ul",{},[210,211,212,215],"li",{},[38,213,214],{},"RHELエコシステムに閉じた単一ノードエッジ","（小売店舗のPOS端末、工場の単一ゲートウェイ等）で、OSからクラスタまで一体化した自動更新・自動ロールバックを求めるなら、MicroShiftの統合度の高さが活きる",[210,217,218,221],{},[38,219,220],{},"ディストリビューション非依存でクラウドからエッジまで同一の運用モデルを求める","、あるいはマルチサーバーでのHA構成やデータストアの柔軟性を重視するなら、K3sの自由度が活きる",[16,223,224],{},"どちらを選んでも、「OSの更新戦略」と「クラスタの更新戦略」をどう一体運用するかという課題は残る。MicroShiftはOSTreeでそれを自動化する代わりにRHELエコシステムへの依存を引き受け、K3sは依存を増やさない代わりに運用設計を利用者に委ねる。",[16,226,227,230],{},[30,228,64],{"href":62,"rel":229},[34],"はK3sベースのマネージドKubernetesサービスとして、まさにこの「OS更新とクラスタ更新を誰が一体で引き受けるか」という課題に向き合っている。K3sの柔軟性やディストリビューション非依存の強みを損なわずに、更新・監視・バックアップといった運用の重い部分をマネージドが引き受ける構成だ。",[16,232,233,234,237,238,243],{},"特に",[30,235,146],{"href":62,"rel":236},[34],"は、エッジや自社データセンターにK3sクラスタを構築しながら、単一ベンダーのOSサブスクリプションに縛られずに済む選択肢として設計されている。すでにK3sでエッジ運用を行っている、あるいはMicroShiftの導入を検討していて「OSごとロックインされること」に懸念がある場合は、",[30,239,242],{"href":240,"rel":241},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"Kuboへのお問い合わせ","から現在の構成を相談してみてほしい。",[16,245,246],{},"K3sベースの軽量性と、マネージドによる運用の安心感。クラウドだけでなく、エッジにもKubernetesを届けるという発想が、工場や店舗でのAI推論や自動化ワークロードを、現実的なコストで実現する土台になる。",{"title":248,"searchDepth":249,"depth":249,"links":250},"",2,[251,252,253,254,255,256],{"id":13,"depth":249,"text":14},{"id":68,"depth":249,"text":69},{"id":110,"depth":249,"text":111},{"id":150,"depth":249,"text":151},{"id":170,"depth":249,"text":171},{"id":201,"depth":249,"text":202},"2026-10-29","K3sとMicroShiftはどちらも「軽量Kubernetes」と語られるが、データストアとOS更新モデルの前提が根本的に違う。etcd固定とOSTree自動ロールバックの実態を比較し、エッジ本番運用でどちらを選ぶべきかを整理する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison",{"title":5,"description":258},"blog\u002Fja\u002Fk3s-microshift-etcd-ostree-edge-comparison",[268,269,270,271,272],"k3s","microshift","kubernetes","edge-computing","redhat","lwvO3kegUzroq4ZYST_Vp_usjB2hBUgBPNRWw2yL4Yw",[275,283,291,300,309,317],{"path":276,"title":277,"description":278,"date":279,"tags":280},"\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",[268,270,281,271,282],"prometheus","observability",{"path":284,"title":285,"description":286,"date":287,"tags":288},"\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",[268,270,289,290,271],"system-upgrade-controller","rolling-upgrade",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\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",[268,270,297,298,299,271],"spegel","registry-mirror","airgap",{"path":301,"title":302,"description":303,"date":304,"tags":305},"\u002Fblog\u002Fja\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production","K3sとMicroK8s、同じ\"軽量\"でも本番で勝つのはどちらか。dqliteとetcdが分けるHA構成の分岐点","K3sとMicroK8s、同じ軽量Kubernetesでも本番運用の明暗を分けるのはHA構成だ。K3sのembedded etcdとMicroK8sのdqlite、それぞれの最小RAM要件・アーキテクチャの違いを公式ドキュメントのデータで比較し、選定基準を解説する。","2026-10-25",[268,306,270,307,271,308],"microk8s","high-availability","comparison",{"path":310,"title":311,"description":312,"date":313,"tags":314},"\u002Fblog\u002Fja\u002Fedge-k3s-hardware-selection-beyond-appliance","家庭用ルーターを自作PCに置き換える動きが加速。エッジKubernetesも「専用アプライアンス」依存を見直す時期だ","ISP支給ルーターを自作PC+OSSに置き換える動きが個人の間で広がっている。工場や店舗のエッジKubernetesも同じ理由で専用アプライアンス依存を見直すべき理由と、ハードウェア選定の具体的なチェックリスト、GitOpsによる拠点運用の標準化までを解説する。","2026-08-29",[268,270,271,315,316],"hardware-selection","network-appliance",{"path":318,"title":319,"description":320,"date":321,"tags":322},"\u002Fblog\u002Fja\u002Fk3s-baremetal-loadbalancer-bgp-metallb-cilium","ベアメタルK3sのLoadBalancer、ARPだけでは限界が来る。BGPで外部ルーティングを設計する","オンプレ・エッジのK3sクラスタでクラウドLBに頼れないとき、Layer2(ARP)方式のロードバランシングはなぜ限界に達するのか。MetalLB BGPモードとCilium BGP Control Planeの違い、移行の判断基準を解説する。","2026-08-26",[268,270,323,324,325,271],"metallb","bgp","load-balancer",1793798693206]