[{"data":1,"prerenderedAt":327},["ShallowReactive",2],{"blog-en-k3s-microshift-etcd-ostree-edge-comparison":3,"blog-related-en-k3s-microshift-etcd-ostree-edge-comparison":275,"blog-en-k3s-microshift-etcd-ostree-edge-comparison-alt":264},{"id":4,"title":5,"author":6,"body":7,"date":258,"description":259,"extension":260,"image":261,"locale":262,"meta":263,"navigation":264,"path":265,"seo":266,"stem":267,"tags":268,"__hash__":274},"blog\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison.md","Is Pinning etcd at the Edge a Trap or a Trade-off? K3s vs MicroShift and the Real Cost of OSTree Auto-Rollback","Kubo Team",{"type":8,"value":9,"toc":248},"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,224,227,233,245],[11,12,14],"h2",{"id":13},"lightweight-kubernetes-doesnt-mean-the-same-thing-for-both","\"Lightweight Kubernetes\" Doesn't Mean the Same Thing for Both",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection01.webp",[16,24,25],{},"K3s and MicroShift are both frequently introduced as \"lightweight Kubernetes for the edge,\" and get lumped together for comparison. But once you actually read their architectures side by side, it becomes clear that the two take fundamentally different approaches to \"lightweight.\"",[16,27,28,29,36,37,41],{},"MicroShift is a single-node container orchestration runtime that Red Hat provides for edge environments. It's positioned as an \"application\" that runs on top of Red Hat Enterprise Linux (RHEL), scoped down to the essential Kubernetes capabilities — networking, ingress, and storage (",[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's official \"Understanding MicroShift\" documentation","). The key point is that MicroShift's design philosophy is to ",[38,39,40],"strong",{},"not replace"," any standard Kubernetes component.",[16,43,44,45,50,51,56],{},"K3s, on the other hand, packages the entire Kubernetes control plane into a single binary (under 100MB) as a fully conformant, CNCF-certified distribution (",[30,46,49],{"href":47,"rel":48},"https:\u002F\u002Fdocs.k3s.io\u002F",[34],"K3s official documentation","). K3s was accepted as a CNCF Sandbox project in August 2020 (",[30,52,55],{"href":53,"rel":54},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fk3s\u002F",[34],"CNCF's official project page","), and its defining trait is that it runs as a single binary regardless of OS or distribution.",[16,58,59,60,65],{},"In other words, MicroShift is designed to \"run only the essential Kubernetes functions on top of the RHEL operating system,\" while K3s is designed to \"run the full Kubernetes stack as a single binary on any Linux environment.\" This difference in starting point ripples into every topic we cover next: the datastore, the OS update model, and the support model. If you want to run the same K3s consistently across cloud and edge under a managed service, this difference in design philosophy becomes a key input when evaluating a K3s-based service like ",[30,61,64],{"href":62,"rel":63},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo",".",[11,67,69],{"id":68},"datastore-options-k3ss-flexibility-vs-microshifts-fixed-etcd","Datastore Options: K3s's Flexibility vs. MicroShift's Fixed etcd",[16,71,72],{},[19,73],{"alt":74,"src":75},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection02.webp",[16,77,78,79,84],{},"The Kubernetes control plane needs a key-value store like etcd to act as the \"single source of truth\" that holds the entire state of the cluster (",[30,80,83],{"href":81,"rel":82},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Foverview\u002Fcomponents\u002F",[34],"Kubernetes official documentation","). How this piece is implemented differs significantly between K3s and MicroShift.",[16,86,87,88,91,92,97],{},"K3s's default datastore is ",[38,89,90],{},"embedded SQLite",". However, SQLite cannot be used in multi-server configurations. For HA (high availability) setups, you choose embedded etcd or an external database (etcd v3.5.21, MySQL 8.0\u002F8.4, MariaDB 10.11\u002F11.4, or PostgreSQL 15.12\u002F16.7\u002F17.3) (",[30,93,96],{"href":94,"rel":95},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore",[34],"K3s official documentation: Datastore","). In other words, K3s lets you stay lightweight with SQLite on a single-node edge device, while scaling onto etcd or an existing external database for a production multi-server setup.",[16,99,100,101,104],{},"MicroShift, by contrast, always uses ",[38,102,103],{},"etcd"," as its datastore, consistent with its policy of not replacing standard Kubernetes components. There's no choice to make, but that also means a simpler configuration and easier compatibility with standard Kubernetes.",[16,106,107],{},"This difference means that when you ask, \"Can I lighten the datastore to fit an edge device's resource constraints?\" — the answer is \"yes\" for K3s and \"no\" for MicroShift. For extremely resource-constrained environments like single-board computers, this gap is not something you can ignore.",[11,109,111],{"id":110},"the-os-update-model-is-ostree-auto-rollback-a-given-or-a-trade-off","The OS Update Model: Is OSTree Auto-Rollback a Given or a Trade-off?",[16,113,114],{},[19,115],{"alt":116,"src":117},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection03.webp",[16,119,120,121,126],{},"MicroShift shows its real value when paired with RHEL for Edge, forming the \"Red Hat Device Edge\" configuration. RHEL for Edge is an OSTree-based immutable OS that comes with automatic rollback and automatic backup\u002Frestore capabilities (",[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 official documentation","). Operational functions like OTA updates, monitoring, and logging are designed to be the OS's responsibility (RHEL for Edge), not MicroShift's own.",[16,128,129],{},"At first glance, this looks like a major advantage. Cluster updates and OS updates become unified, and failures trigger an automatic rollback. For unattended environments like retail store devices or factory edge gateways where you can't dedicate hands-on operations staff, this is an appealing mechanism.",[16,131,132],{},"But at the same time, it means committing to the \"RHEL for Edge ecosystem\" as a precondition. Because the OS, the distribution, and the subscription are bundled together as a set, organizations that have already standardized on a different Linux distribution, or that run multi-OS environments, take on an additional dependency.",[16,134,135,136,139],{},"K3s is OS-independent and runs on any supported Linux distribution (",[30,137,49],{"href":47,"rel":138},[34],"). This also means K3s itself doesn't provide OS update automation — you need to design your own update strategy. The flip side is the freedom to keep your existing OS standardization policy and image build pipeline as-is.",[16,141,142,143,147],{},"\"Being automated\" and \"being locked in\" are often two sides of the same coin when selecting edge infrastructure. With an approach like ",[30,144,146],{"href":62,"rel":145},[34],"Kubo On-Premise",", where a managed service takes on OS updates and K3s cluster updates together without adding dependency on a specific OS vendor, you start to see an option that decouples this trade-off altogether.",[11,149,151],{"id":150},"an-easily-overlooked-default-etcd-encryption-is-not-on-by-default","An Easily Overlooked Default: etcd Encryption Is Not On by Default",[16,153,154],{},[19,155],{"alt":156,"src":157},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection04.webp",[16,159,160,161,164],{},"MicroShift's Kubernetes objects are stored in an etcd database, and the official documentation explicitly states that \"etcd data is not encrypted by default.\" If you're handling sensitive data, you need to make an additional configuration decision — encrypting the disk with LUKS (Linux Unified Key Setup), or disabling the storage plugin entirely (",[30,162,125],{"href":123,"rel":163},[34],").",[16,166,167],{},"The assumption that \"it's an edge-optimized product, so it must be secure out of the box\" is a trap. This isn't a weakness unique to MicroShift — K3s's SQLite or etcd carries the same responsibility for disk encryption and data-at-rest protection resting with the operator. Regardless of which distribution you choose, \"explicitly verify the datastore's encryption settings\" is a checklist item you can't skip before production rollout.",[11,169,171],{"id":170},"commercial-support-and-lifecycle-red-hat-device-edge-vs-suserancher","Commercial Support and Lifecycle: Red Hat Device Edge vs. SUSE\u002FRancher",[16,173,174],{},[19,175],{"alt":176,"src":177},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Fsection05.webp",[16,179,180,181,186],{},"Red Hat publishes the \"Red Hat build of MicroShift Life Cycle Policy,\" which defines the Full Support Phase and end-of-support timing for each version (",[30,182,185],{"href":183,"rel":184},"https:\u002F\u002Faccess.redhat.com\u002Fnode\u002F7086005",[34],"Red Hat Life Cycle Policy","). In other words, MicroShift has entered the stage of being explicitly managed as a commercial product with a defined support period. Having the OS, the cluster, and the support desk unified under an RHEL subscription fits well with enterprise procurement processes.",[16,188,189],{},"K3s is a CNCF-certified open source project, and commercial support for the project itself depends on contracts such as Rancher Prime offered by SUSE\u002FRancher. Whether you prioritize the transparency of an OSS community and distribution independence, or a support structure consolidated under a single vendor's subscription, comes down to your organization's governance policy.",[16,191,192,193,198],{},"Academic research is also advancing comparisons of lightweight Kubernetes distributions. A paper comparing k0s, K3s, KubeEdge, and OpenYurt on security compliance, resilience to network failures, and maintainability found that k3s and k0s excel in ease of development, while facing trade-offs on security compliance (",[30,194,197],{"href":195,"rel":196},"https:\u002F\u002Farxiv.org\u002Fabs\u002F2503.04815",[34],"arXiv:2503.04815","). The paper itself doesn't directly compare MicroShift, but the observation that \"simplicity and ease of development\" trades off against \"security and robustness\" resonates with the contrast we've drawn here between MicroShift's etcd lock-in and OSTree automation on one hand, and K3s's flexibility on the other. Choosing a lightweight Kubernetes distribution is becoming less about comparing resource footprints, and more a governance question of how to weigh these trade-offs.",[11,200,202],{"id":201},"conclusion-which-should-you-choose","Conclusion: Which Should You Choose?",[16,204,205],{},"K3s and MicroShift share the same goal — running Kubernetes at the edge — but they assume fundamentally different operating models.",[207,208,209,217],"ul",{},[210,211,212,213,216],"li",{},"If you need ",[38,214,215],{},"a single-node edge closed within the RHEL ecosystem"," (a retail POS terminal, a single factory gateway) and want OS-to-cluster unified automatic updates and rollback, MicroShift's tight integration pays off.",[210,218,219,220,223],{},"If you want ",[38,221,222],{},"a distribution-independent operating model spanning cloud to edge",", or prioritize HA flexibility and datastore choice across multiple servers, K3s's freedom pays off.",[16,225,226],{},"Either way, the challenge of unifying \"OS update strategy\" with \"cluster update strategy\" remains. MicroShift automates this through OSTree at the cost of depending on the RHEL ecosystem; K3s avoids that extra dependency but leaves the operational design up to you.",[16,228,229,232],{},[30,230,64],{"href":62,"rel":231},[34]," is a managed Kubernetes service built on K3s that directly addresses this question of \"who should take on unifying OS updates and cluster updates.\" It's built to take on the heavy lifting of updates, monitoring, and backups through a managed layer, without sacrificing K3s's flexibility or distribution independence.",[16,234,235,238,239,244],{},[30,236,146],{"href":62,"rel":237},[34]," in particular is designed as an option that lets you build a K3s cluster at the edge or in your own data center, without being locked into a single vendor's OS subscription. If you're already running K3s at the edge, or you're evaluating MicroShift and have concerns about getting locked in at the OS level, ",[30,240,243],{"href":241,"rel":242},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"reach out to Kubo"," to talk through your current setup.",[16,246,247],{},"The lightness of K3s, combined with the peace of mind of a managed operations layer. Bringing Kubernetes not just to the cloud but to the edge is what makes AI inference and automation workloads at factories and retail stores achievable at a realistic cost.",{"title":249,"searchDepth":250,"depth":250,"links":251},"",2,[252,253,254,255,256,257],{"id":13,"depth":250,"text":14},{"id":68,"depth":250,"text":69},{"id":110,"depth":250,"text":111},{"id":150,"depth":250,"text":151},{"id":170,"depth":250,"text":171},{"id":201,"depth":250,"text":202},"2026-10-29","K3s and MicroShift are both called \"lightweight Kubernetes,\" but their assumptions about datastores and OS update models are fundamentally different. We compare etcd lock-in and OSTree auto-rollback to help you choose for production edge deployments.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison",{"title":5,"description":259},"blog\u002Fen\u002Fk3s-microshift-etcd-ostree-edge-comparison",[269,270,271,272,273],"k3s","microshift","kubernetes","edge-computing","redhat","vvOVK14PkxYchPCO6c4ZSnA2gq06oHlD0iE-nklqUvw",[276,284,292,301,310,318],{"path":277,"title":278,"description":279,"date":280,"tags":281},"\u002Fblog\u002Fen\u002Fk3s-prometheus-agent-mode-stale-marker-edge-monitoring","We Switched K3s Edge Prometheus to Agent Mode. The Moment a Target Disappeared, So Did Its Metrics","Running Prometheus Agent mode on K3s edge clusters can leave stale values in your central dashboard when a target disappears, depending on how stale markers are handled. Here's how to design K3s edge monitoring correctly.","2026-11-03",[269,271,282,272,283],"prometheus","observability",{"path":285,"title":286,"description":287,"date":288,"tags":289},"\u002Fblog\u002Fen\u002Fk3s-system-upgrade-controller-plan-stuck-node-drain","The Plan Never Disappeared. Why K3s's system-upgrade-controller Got Stuck on One Node","We set up automated upgrades with K3s's system-upgrade-controller, and the Plan stopped progressing on a single node. The culprits were PodDisruptionBudgets and taints. Here's how the mechanism works, how to recover, and how Kubo helps.","2026-10-31",[269,271,290,291,272],"system-upgrade-controller","rolling-upgrade",{"path":293,"title":294,"description":295,"date":296,"tags":297},"\u002Fblog\u002Fen\u002Fk3s-spegel-embedded-registry-mirror-airgap-node-join","K3s's Embedded Registry Mirror Was Supposed to Just Work. Then a New Edge Node Couldn't Pull Images","K3s's embedded registry mirror (Spegel) is supposed to work cluster-wide, but a newly added edge node alone failed to pull images. The cause: an undistributed registries.yaml, credential drift, and a known containerd 2.0 bug. Here's the correct distribution workflow for air-gapped operations.","2026-10-30",[269,271,298,299,300,272],"spegel","registry-mirror","airgap",{"path":302,"title":303,"description":304,"date":305,"tags":306},"\u002Fblog\u002Fen\u002Fk3s-vs-microk8s-ha-etcd-dqlite-edge-production","K3s vs MicroK8s: Which One Actually Wins in Production? The HA Fork Between dqlite and etcd","K3s vs MicroK8s: both are called 'lightweight Kubernetes,' but the real production divide is HA architecture. We compare K3s's embedded etcd and MicroK8s's dqlite using official documentation data.","2026-10-25",[269,307,271,308,272,309],"microk8s","high-availability","comparison",{"path":311,"title":312,"description":313,"date":314,"tags":315},"\u002Fblog\u002Fen\u002Fedge-k3s-hardware-selection-beyond-appliance","Homelabbers Are Ditching ISP Routers for Self-Built PCs. Edge Kubernetes Should Rethink Its Appliance Habit Too","A growing number of individuals are replacing ISP-supplied routers with self-built mini PCs running open-source firmware. The same logic applies to edge Kubernetes: a hardware selection checklist and a GitOps operating model for standardizing dedicated appliances out of the fleet.","2026-08-29",[269,271,272,316,317],"hardware-selection","network-appliance",{"path":319,"title":320,"description":321,"date":322,"tags":323},"\u002Fblog\u002Fen\u002Fk3s-baremetal-loadbalancer-bgp-metallb-cilium","Bare-Metal K3s LoadBalancer: When ARP Hits Its Limit, Design for BGP","When you can't rely on a cloud load balancer for on-prem or edge K3s clusters, why does Layer2 (ARP) load balancing eventually hit a wall? A practical look at MetalLB's BGP mode vs. Cilium's BGP Control Plane, and how to decide when to migrate.","2026-08-26",[269,271,324,325,326,272],"metallb","bgp","load-balancer",1793798724222]