Executive Summary
This report provides a definitive technical comparison of K3s and MicroK8s, two leading CNCF-certified Kubernetes distributions optimized for edge computing. Our analysis concludes that the choice between them is not one of superiority, but of strategic alignment with specific operational philosophies and technical requirements. K3s excels in environments demanding architectural flexibility, minimal dependencies, and granular control, making it ideal for custom, deeply integrated edge solutions. Conversely, MicroK8s offers a “low-ops,” batteries-included experience with a rich addon ecosystem and automated management, positioning it as the preferred choice for rapid deployment and ease of use, particularly within the Canonical/Ubuntu ecosystem.
The primary differentiators between the two platforms are rooted in their foundational design choices. K3s’s distribution as a single, self-contained binary grants it maximum portability across a vast range of Linux operating systems and a minimal OS footprint. This makes it exceptionally well-suited for deployments on resource-constrained or non-standard Linux environments. In contrast, MicroK8s leverages Canonical’s snap packaging system, which simplifies installation and dependency management while enabling transactional, automated updates. However, this approach introduces a hard dependency on snapd, limiting its OS portability.
These foundational differences extend to their high-availability (HA) models. K3s offers a flexible approach to HA, supporting either an embedded etcd datastore for self-contained clusters or an external SQL datastore. The latter is a significant advantage for enterprises that can integrate K3s with existing, managed database infrastructure, thereby lowering the operational burden of maintaining a resilient control plane. MicroK8s, true to its low-ops philosophy, provides automated, zero-configuration HA through its embedded Dqlite datastore, which activates seamlessly once a cluster reaches three nodes.
The ecosystems surrounding each distribution also reflect their core philosophies. MicroK8s boasts a curated, command-driven addon system that allows for the one-step activation of complex services like Istio, Kubeflow, and various networking or storage solutions. K3s maintains a leaner core, relying on a standard manifest-based approach for deploying addons. This method offers operators more granular control and transparency but requires more manual configuration and integration effort.
Ultimately, the decision hinges on organizational priorities. Organizations should select K3s for edge use cases that require deep customization, integration with existing enterprise datastores, or deployment on minimalist Linux distributions where snapd is unavailable or undesirable. MicroK8s is the recommended solution for teams prioritizing speed of deployment, automated lifecycle management for updates and high availability, and a rich, pre-packaged ecosystem of services, particularly in environments standardized on Ubuntu.
The Imperative for Lightweight Kubernetes at the Edge
Defining the Edge Computing Challenge
The paradigm of edge computing, which involves processing data near its source rather than in a centralized cloud, presents a set of challenges fundamentally distinct from those of traditional data centers. Edge environments are characterized by significant constraints on resources, including limited CPU power, memory, and electrical power. Furthermore, they often operate with unreliable, low-bandwidth, or intermittent network connectivity, making constant communication with a central management plane impractical. A defining characteristic of edge computing is the need for management at a massive scale, potentially involving thousands or tens of thousands of distributed nodes in remote locations.1
Standard Kubernetes distributions, while the de facto standard for container orchestration in the cloud, are often ill-suited for these demanding conditions. Their complex configurations, resource-intensive control plane components, and significant operational overhead make them impractical for deployment on constrained edge devices.4 This operational friction creates a critical gap in the cloud-native ecosystem, hindering the extension of Kubernetes’s powerful orchestration capabilities to the edge.
The Rise of Lightweight Distributions
To address this gap, a new class of lightweight Kubernetes distributions has emerged, with K3s and MicroK8s at the forefront. These platforms are meticulously engineered to be smaller, more economical, and significantly simpler to install and manage. They achieve this by stripping away non-essential features, replacing heavy components with more efficient alternatives, and streamlining the installation process. Crucially, they do so while retaining core Kubernetes functionality and maintaining full certification from the Cloud Native Computing Foundation (CNCF), ensuring compatibility with the broader Kubernetes ecosystem.4 This balance of minimalism and conformance makes them a viable and powerful choice for a wide array of use cases, including Internet of Things (IoT) appliances, edge gateways, continuous integration/continuous delivery (CI/CD) pipelines, local development environments, and deployments on ARM-based hardware.1
Introducing the Contenders
- K3s (Developed by Rancher, now part of SUSE): K3s is a fully conformant Kubernetes distribution packaged as a single binary of less than 100 MB. Its lightweight nature is achieved by removing legacy, alpha, and in-tree cloud provider and storage drivers, which have been superseded by out-of-tree alternatives. This results in a minimal, secure, and easy-to-operate Kubernetes cluster.1
- MicroK8s (Developed by Canonical): MicroK8s is billed as a “low-ops, minimal production” Kubernetes distribution. It is packaged as a snap, a universal application package for Linux that bundles all dependencies. This approach provides a full-featured yet small-footprint Kubernetes environment that is scalable from a single development node to a production-grade, high-availability cluster.10
Architectural Deep Dive: K3s
Core Philosophy and Design Principles
The design of K3s is guided by a philosophy of minimalism, security, and operational simplicity, tailored specifically for resource-constrained environments. Its architecture reflects a deliberate effort to reduce the complexity and footprint of Kubernetes without sacrificing its core capabilities.
Single Binary, Minimal Dependencies
The most defining characteristic of K3s is its packaging as a single, lightweight binary file.1 This binary encapsulates not only the core Kubernetes components but also all their necessary dependencies, such as a container runtime (containerd), a CNI plugin (Flannel), and a DNS provider (CoreDNS). This design choice fundamentally minimizes the distribution’s dependency on the host operating system, requiring only a modern Linux kernel and properly configured cgroups to function.7
This single-binary approach is more than a mere optimization for file size; it carries significant strategic implications for edge deployments. By bundling all essential components, K3s eliminates the complex and often brittle process of managing dependencies during installation and upgrades. This self-contained nature grants it exceptional portability across a wide spectrum of Linux distributions. It can be deployed on standard enterprise servers as easily as on minimalist operating systems like Alpine Linux, a capability that snap-dependent distributions cannot match.12 Furthermore, from a security standpoint, the reduction in moving parts and external dependencies inherently shrinks the potential attack surface. For edge devices that may be physically insecure or exposed on untrusted networks, this minimalist security posture is a critical advantage.2
Architecture and Core Components
K3s employs a classic server-agent architecture, which is both simple and scalable for edge topologies.
Server-Agent Model
A K3s cluster is composed of server nodes, which run the Kubernetes control plane, and agent nodes, which function as workers to run application pods.13 A notable architectural innovation is the use of a websocket tunnel initiated by the
k3s agent process to connect to a k3s server node. This tunnel, managed by a client-side load balancer within the agent, multiplexes all traffic between the kubelet and the API server. A key security benefit of this design is that worker nodes do not need to expose an API port to the control plane, thereby reducing the network attack surface of the cluster.9
Pluggable Datastore via Kine
Instead of relying solely on the standard etcd datastore, K3s introduces a powerful abstraction layer called Kine. Kine is a shim that translates etcd API calls, allowing K3s to use various database backends to store its cluster state.2 This flexibility is a cornerstone of its architecture.
- SQLite (Default): For single-node deployments, K3s defaults to an embedded SQLite database. This option is exceptionally lightweight and requires zero configuration, making it ideal for simple development or single-device edge deployments.9
- Embedded etcd: For multi-node high-availability (HA) clusters, K3s can manage its own embedded etcd datastore, providing a self-contained HA solution without external dependencies.14
- External SQL Databases: K3s officially supports connecting to external, production-grade SQL databases such as MySQL, PostgreSQL, and MariaDB.9
The ability to leverage an external SQL datastore is a powerful feature that facilitates enterprise adoption. Many organizations already possess mature, highly available SQL database infrastructure, complete with established operational procedures for backups, monitoring, and disaster recovery. By allowing K3s to integrate with these existing systems, the operational barrier to deploying a production-grade, resilient Kubernetes control plane is significantly lowered. This enables teams to manage the state of their Kubernetes cluster using familiar tools and practices, rather than requiring them to develop specialized and often complex expertise in managing and backing up etcd directly. Consequently, K3s’s HA model is highly adaptable to a wide range of existing enterprise environments.
Installation and Deployment
K3s is designed for rapid deployment in both online and offline environments.
- Online Installation: The most common installation method is a simple curl script available at get.k3s.io. This script automates the download of the K3s binary and sets it up as a systemd service, enabling a functional cluster to be running in minutes.2
- Air-Gapped (Offline) Installation: Recognizing the requirements of secure and disconnected edge environments, K3s provides a well-documented process for air-gapped installation. This procedure involves pre-downloading the K3s binary, a tarball containing all necessary container images, and the installation script itself. The framework supports multiple methods for distributing these images within the air-gapped network, including the use of a private registry or the manual placement of the image tarball on each node’s filesystem.18
High Availability (HA) Models
K3s offers two distinct models for achieving a highly available control plane, catering to different operational needs.
- Embedded etcd HA: This model provides a self-contained HA solution where K3s manages its own distributed etcd cluster. It requires an odd number of server nodes (three or more) to maintain quorum and ensure fault tolerance. The cluster is bootstrapped by starting the first server with a –cluster-init flag, and subsequent servers join using a shared token, forming a resilient control plane without any external dependencies.14
- External Database HA: In this configuration, two or more server nodes are configured to connect to a common external datastore, such as a managed MySQL or PostgreSQL instance. This offloads the complexity of managing the datastore to a dedicated system. To provide a stable endpoint for agent nodes, a load balancer is typically deployed in front of the server nodes to create a fixed registration address.14
Networking and Ecosystem
K3s provides a functional, out-of-the-box networking stack that can be easily customized.
- Packaged Components: By default, K3s includes Flannel as its CNI plugin, providing basic pod-to-pod networking, and Traefik as its ingress controller, enabling external access to services from day one.2
- Custom CNI Support: The default Flannel CNI can be disabled with the –flannel-backend=none flag. This allows operators to install more advanced CNI plugins, such as Calico or Cilium, to implement features like network policies for enhanced security and traffic control.22
- Addon Management: K3s features a simple yet effective mechanism for managing addons. Any Kubernetes manifest files placed in the /var/lib/rancher/k3s/server/manifests directory on a server node are automatically deployed to the cluster. K3s monitors this directory for changes, applying updates to the manifests as they occur. These deployments are tracked as AddOn custom resources within the cluster, providing a declarative way to manage custom applications and configurations.20
Architectural Deep Dive: MicroK8s
Core Philosophy and Design Principles
MicroK8s, developed and maintained by Canonical, is engineered around a “low-ops” philosophy, aiming to provide a full-featured Kubernetes experience with minimal administrative overhead.10 Its architecture is fundamentally shaped by its choice of packaging and its emphasis on automation.
“Low-Ops” and Packaged Experience
The defining characteristic of MicroK8s is its distribution as a snap package. Snaps are universal application packages for Linux that bundle an application with all of its dependencies, ensuring it runs consistently across different environments.4
This packaging model is central to the MicroK8s user experience and represents a significant trade-off between simplicity and constraint. On one hand, it simplifies installation to a single snap install command and enables transactional, automated updates for security patches and new Kubernetes versions.4 This is a major benefit for users and teams who prioritize a “hands-off” management approach, as the snap daemon handles the lifecycle of the application. On the other hand, this creates a hard dependency on the
snapd service, effectively limiting MicroK8s to Linux distributions that support it, with Ubuntu being the primary target. This excludes ultra-minimalist operating systems like Alpine Linux, making MicroK8s inherently less portable at the OS level than the self-contained K3s binary. This trade-off positions MicroK8s as a solution that favors operational simplicity on supported systems over universal applicability.
Architecture and Core Components
MicroK8s provides a self-contained Kubernetes environment where core components are managed as services within the snap’s sandboxed environment.10
Dqlite Datastore
A key architectural differentiator is MicroK8s’s use of Dqlite, a distributed, high-availability version of SQLite, as its default datastore. This lightweight, embedded datastore is the cornerstone of its automated high-availability feature, removing the need for users to manage a separate etcd cluster.27
Installation and Deployment
The installation process for MicroK8s is streamlined through its packaging format.
- Snap-based Installation: On supported Linux distributions, installation is a single command: sudo snap install microk8s –classic.4 Canonical also provides dedicated installers for Windows and macOS, which leverage virtualization technologies like Hyper-V or Multipass to run the Linux-based snap in a lightweight virtual machine, offering a consistent experience across platforms.8
- Air-Gapped (Offline) Installation: The offline installation process for MicroK8s requires downloading the microk8s and core20 snap files, along with their corresponding assertion files, from an internet-connected machine. These files are then transferred to the air-gapped nodes and installed manually using the snap ack and snap install commands. Container images required for core components and any desired addons must also be made available, either by pre-loading them into a private registry accessible within the air-gapped network or by side-loading them from a tarball directly onto the nodes.29
High Availability (HA) Model
The approach to high availability in MicroK8s is one of its most compelling features, designed for maximum simplicity.
Automatic HA with Dqlite
High availability is enabled automatically and transparently as soon as a MicroK8s cluster is formed with three or more nodes.10 The Dqlite datastore is automatically replicated across the control plane nodes, and a leader is elected through a voting process to handle write operations. This “zero-ops” approach requires no external datastore or complex configuration from the user, making it exceptionally easy to create a resilient cluster.27
While this automated HA model is a significant usability advantage, its production-readiness is entirely dependent on the stability of the underlying Dqlite datastore. The design promises self-healing capabilities and resilience to the failure of a single node.27 However, anecdotal reports from the user community suggest that some have encountered stability issues with Dqlite in long-running production environments, with some cases leading to unrecoverable cluster states that required a complete rebuild.12 This indicates a potential trade-off: MicroK8s provides unparalleled simplicity in setting up a highly available cluster, but this convenience may come with a higher risk profile compared to the industry-standard etcd or a managed external SQL database, both of which are supported by K3s.
Networking and Ecosystem
The MicroK8s ecosystem is built around a rich, curated set of addons that extend its core functionality.
Rich Addon System
A primary strength of MicroK8s is its extensive library of both core and community-maintained addons. These addons can be activated with a single, simple command: microk8s enable <addon>.5 This provides a “plug-and-play” experience for deploying and configuring complex services that would otherwise require significant manual effort. The addon repository includes solutions for DNS, storage, ingress controllers, service meshes like Istio, monitoring with Prometheus, and even support for GPU acceleration and machine learning workloads with Kubeflow.24
Default and Alternative CNIs
By default, MicroK8s clusters use the Calico CNI plugin. This is a robust choice that supports network policies out of the box, a feature essential for securing traffic within the cluster.35 For users with different networking requirements, MicroK8s offers addons for other popular CNIs, including Kube-OVN and Cilium. It also supports Multus, which enables pods to have multiple network interfaces, a requirement for certain advanced networking use cases like NFV (Network Functions Virtualization).34
Head-to-Head Comparison: A Feature-by-Feature Analysis
While both K3s and MicroK8s are designed as lightweight Kubernetes distributions, their differing architectural philosophies result in distinct operational characteristics. This section provides a direct comparison across key features relevant to deployment and management at the edge. The following table offers a high-level summary of these differences.
| Feature | K3s | MicroK8s |
| Packaging | Single binary (<100MB) | Snap package |
| Dependencies | Minimal (Linux kernel, cgroups) | snapd |
| Default Datastore | SQLite (single-node) | Dqlite |
| HA Datastore Options | Embedded etcd, External SQL (MySQL, PostgreSQL), External etcd | Dqlite (built-in) |
| HA Setup | Manual configuration (–cluster-init, –server) | Automatic on 3+ nodes |
| Installation | curl script | snap install command |
| OS Support | Any modern Linux (incl. Alpine), ARMv7/ARM64 | Linux (with snapd), Windows, macOS |
| Default CNI | Flannel | Calico |
| Addon Management | Auto-deploying YAML manifests in a directory | microk8s enable <addon> CLI command |
| Upgrade Mechanism | Manual (script/binary) or Automated (system-upgrade-controller) | Automatic via snap refresh (can be scheduled/held) |
| Security Hardening | Manual hardening guide + CIS self-assessment | cis-hardening addon + CIS compliance docs |
Installation and Usability
- Initial Setup: For users on Ubuntu or a derivative, MicroK8s offers a marginally simpler initial setup, requiring only a single snap install command.4 K3s’s
curl script is also straightforward but may require operators to be more aware of command-line flags to customize the installation from the outset.2 - CLI Experience: MicroK8s namespaces all its commands under the microk8s binary (e.g., microk8s kubectl, microk8s enable). This design choice effectively prevents conflicts with other kubectl installations on the host system but can lead to more verbose commands; creating a shell alias is a common practice among users.30 K3s, by contrast, installs its
kubectl binary in a standard system path, providing a command-line experience that is virtually indistinguishable from a standard Kubernetes environment.2 - Daily Management: The microk8s enable/disable workflow for managing addons represents a significant usability advantage, especially for teams looking to quickly deploy complex services without deep-diving into Helm charts or YAML manifests.24 Management of a K3s cluster relies on the standard Kubernetes practice of using
kubectl apply with manifest files, which offers greater flexibility and transparency but is a more manual and less guided process.20
Resource Consumption
- Minimum Requirements: On paper, K3s specifies a slightly lower minimum RAM requirement of 512 MB, compared to the 540 MB required by MicroK8s.2 However, both projects recommend significantly more memory for production workloads (K3s suggests 1 GB or more, while MicroK8s recommends at least 4 GB) to accommodate actual application pods.2
- Community Benchmarks: Anecdotal evidence and benchmarks from the user community generally suggest that K3s has a lower real-world resource footprint and is perceived as more efficient. The overhead associated with the snapd daemon and the bundled services in MicroK8s can lead to higher baseline RAM and CPU usage compared to the leaner, single-process model of K3s.12
High Availability
- K3s: The primary advantage of K3s in high availability is its flexibility. The support for an external SQL datastore is a powerful feature for enterprise environments, allowing organizations to leverage existing managed database services for the Kubernetes control plane, thereby offloading the complex task of datastore management.15 However, this flexibility comes at the cost of a fully manual setup process, which requires careful configuration of server nodes and, typically, an external load balancer to provide a stable registration endpoint.16
- MicroK8s: MicroK8s offers a “zero-ops” HA model that is a major draw for teams prioritizing simplicity. High availability is enabled automatically and without any user intervention as soon as the cluster size reaches three nodes.27 This simplicity, however, comes with a trade-off: it locks the user into the Dqlite datastore. While designed for resilience, Dqlite is less battle-tested than etcd, and some community members have reported stability issues in long-running production clusters, which presents a potential operational risk.12
Security Posture
- Default Security: K3s is designed with a “secure by default” posture. Architectural choices, such as the agent-to-server websocket tunnel, are intended to reduce the network attack surface of worker nodes by eliminating the need for an inbound port on the kubelet.9
- CIS Compliance: Both distributions provide clear pathways to achieving compliance with the Center for Internet Security (CIS) Kubernetes Benchmark. K3s offers detailed hardening guides and self-assessment documents that walk operators through the necessary manual configuration changes to secure the cluster.40 MicroK8s simplifies this process by providing a
cis-hardening addon, which automates the application of many of the CIS-recommended security controls with a single command.43
Upgrade and Maintenance
- K3s: The upgrade process in K3s offers operators a high degree of control. Upgrades can be performed manually by replacing the K3s binary and restarting the service, or they can be automated in a declarative, Kubernetes-native way using the system-upgrade-controller. This controller uses a Plan custom resource to define upgrade strategies, allowing for controlled, phased rollouts and scheduled maintenance windows.44
- MicroK8s: Upgrades are managed by the snapd daemon, which automatically checks for and applies new versions from the user-selected release channel.24 This ensures that security patches are applied promptly but can also lead to unexpected upgrades during critical periods. To mitigate this,
snapd allows refreshes to be held or scheduled within specific maintenance windows, but this global setting offers less granular control over the upgrade process compared to the plan-based approach used by K3s.25
Evaluating Suitability for Edge Computing Scenarios
The distinct architectural and operational models of K3s and MicroK8s make them better suited for different types of edge computing deployments. The optimal choice depends heavily on the specific constraints and requirements of the use case.
Resource-Constrained Devices (IoT, Raspberry Pi)
Both K3s and MicroK8s provide excellent support for ARM architectures, making them popular choices for single-board computers like the Raspberry Pi.47 For extremely resource-constrained devices where every megabyte of RAM and every CPU cycle is critical, K3s often holds an edge. Its slightly lower perceived resource footprint, minimal OS dependencies, and the ability to run on stripped-down Linux distributions give it an advantage in environments where efficiency is paramount.2 MicroK8s remains a strong contender, particularly for devices running a full version of Ubuntu, where the snap ecosystem provides a seamless experience.50
Intermittently Connected and Air-Gapped Environments
Both distributions offer robust and well-documented procedures for offline, or air-gapped, installation, a critical requirement for secure or remote edge locations with no internet access.18 The process for K3s, which involves transporting a single binary and a tarball of container images, can be marginally simpler to manage and distribute than the multiple snap packages and assertion files required for a MicroK8s offline installation. The K3s air-gap installation process is noted for its flexibility and clarity.18
Large-Scale Remote Deployments
For managing a large fleet of geographically distributed edge clusters, K3s, when paired with Rancher Manager, offers a powerful and cohesive solution. Rancher provides a centralized management plane that can provision, monitor, and manage the lifecycle of thousands of remote K3s clusters, which is a significant advantage for large-scale operational deployments.1 While MicroK8s can also be deployed at scale, its automatic update mechanism can present challenges. An unattended, problematic upgrade could simultaneously impact an entire fleet of devices. To manage this risk, organizations must implement a Snap Store Proxy, which allows them to control the rollout of updates and test new versions before they are deployed widely, adding an extra layer of infrastructure to manage.25
Developer and CI/CD Workloads
For local development and testing, MicroK8s is highly attractive. Its simple, one-command installation on Windows and macOS (via lightweight virtualization) and its easy-to-use addon system allow developers to quickly stand up a full-featured Kubernetes environment on their workstations.11 K3s is also extremely popular in the CI/CD space, often deployed using tools like k3d (which runs K3s in Docker containers). Its rapid startup times and low resource overhead make it ideal for creating and destroying ephemeral clusters for automated testing pipelines, enabling fast and efficient validation of applications.6
Strategic Recommendations and Future Outlook
The choice between K3s and MicroK8s is a strategic one, reflecting a trade-off between flexibility and simplicity. The optimal decision depends on the technical expertise of the team, the existing infrastructure, and the specific operational requirements of the edge deployment.
Guidance for the IoT/Embedded Systems Engineer
For engineers developing solutions for deeply embedded or resource-constrained IoT devices, K3s is often the superior choice. Its minimal OS dependencies allow it to run on highly customized, stripped-down Linux builds. The single, small binary is easy to integrate into a device’s firmware, and its lower perceived resource overhead provides more headroom for the actual application workload.
Guidance for the Enterprise DevOps Team
For enterprise DevOps teams managing on-premises or hybrid cloud infrastructure, the decision is more nuanced. If the organization has a mature practice around managing SQL databases and requires granular control over the cluster lifecycle, particularly upgrades, K3s with an external datastore is a compelling and robust option. It integrates well with existing enterprise infrastructure and operational patterns. Conversely, if the primary goal is to enable development teams with a self-service, easy-to-use Kubernetes platform that minimizes operational burden, MicroK8s is an excellent fit. Its automated HA, rich addon ecosystem, and seamless experience on Ubuntu make it ideal for rapid deployment and developer productivity.
Guidance for the Software Vendor
For independent software vendors (ISVs) looking to embed a Kubernetes distribution within their product, both platforms offer viable paths. K3s, with its single distributable binary, provides a straightforward way to package a Kubernetes control plane. MicroK8s, with its strictly confined snap package and transactional update mechanism, offers a robust and secure platform for embedding Kubernetes into appliances, ensuring that the underlying orchestration layer can be reliably managed and updated in the field.8
Future Outlook
Both K3s and MicroK8s are mature, CNCF-certified projects that are poised to play a pivotal role in the continued expansion of Kubernetes beyond the traditional data center. The fundamental divergence between them is likely to persist and define their respective roadmaps. K3s will probably continue to champion flexibility, modularity, and minimal dependencies, appealing to users who require deep control and customization. MicroK8s, in contrast, will likely double down on its “low-ops” philosophy, enhancing its integrated ecosystem and automated management features to deliver a seamless user experience. The choice between them will therefore remain a strategic one, dictated not by which is “better,” but by which operational model and technical philosophy best aligns with an organization’s goals at the edge.
Works cited
- Lightweight Certified Kubernetes Distribution | K3s – Rancher, accessed on August 6, 2025, https://www.rancher.com/products/k3s
- What is K3s? A Quick Installation Guide for K3s – Devtron, accessed on August 6, 2025, https://devtron.ai/blog/what-is-k3s-a-quick-installation-guide-for-k3s/
- Choose a Kubernetes at the Edge Compute Option – Azure Architecture Center, accessed on August 6, 2025, https://learn.microsoft.com/en-us/azure/architecture/operator-guides/aks/choose-kubernetes-edge-compute-option
- K3s vs MicroK8s Lightweight Kubernetes Distributions – Wallarm, accessed on August 6, 2025, https://www.wallarm.com/cloud-native-products-101/k3s-vs-microk8s-lightweight-kubernetes-distributions
- k8s vs k3s vs microk8s vs k0s – Kai Evans, accessed on August 6, 2025, https://kaievans.co/posts/zMWU0
- What Is K3s? – Sysdig, accessed on August 6, 2025, https://sysdig.com/learn-cloud-native/what-is-k3s/
- K3s-deployment-guide | openEuler documentation | v22.03_LTS_SP3, accessed on August 6, 2025, https://docs.openeuler.org/en/docs/22.03_LTS_SP3/docs/K3s/K3s-deployment-guide.html
- MicroK8s documentation – home – Discuss Kubernetes, accessed on August 6, 2025, https://discuss.kubernetes.io/t/microk8s-documentation-home/11243
- k3s-io/k3s: Lightweight Kubernetes – GitHub, accessed on August 6, 2025, https://github.com/k3s-io/k3s
- What Is MicroK8s? – Sysdig, accessed on August 6, 2025, https://www.sysdig.com/learn-cloud-native/what-is-microk8s
- Introduction to MicroK8s: Lightweight Kubernetes for Developers – Sivali Cloud Technology, accessed on August 6, 2025, https://sivali.co/en/blog/container-orchestration/introduction-to-micro-k8s-lightweight-kubernetes-for-developers
- K3s v MicroK8s : r/kubernetes – Reddit, accessed on August 6, 2025, https://www.reddit.com/r/kubernetes/comments/qhnxc7/k3s_v_microk8s/
- Architecture | K3s, accessed on August 6, 2025, https://docs.k3s.io/architecture
- High Availability Embedded etcd | K3s, accessed on August 6, 2025, https://docs.k3s.io/datastore/ha-embedded
- High Availability External DB – K3s, accessed on August 6, 2025, https://docs.k3s.io/datastore/ha
- Setting up Infrastructure for a High Availability K3s Kubernetes Cluster | Rancher, accessed on August 6, 2025, https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster
- How Can You Master Kubernetes Architecture and Setup with k3s? – Rolf Streefkerk, accessed on August 6, 2025, https://rolfstreefkerk.com/insight-prose/how-can-you-master-kubernetes-architecture-and-setup-with-k3s/
- Air-Gap Install | K3s, accessed on August 6, 2025, https://docs.k3s.io/installation/airgap
- Running When Offline – Rancher Desktop Docs, accessed on August 6, 2025, https://docs.rancherdesktop.io/how-to-guides/running-air-gapped/
- Managing Packaged Components | K3s, accessed on August 6, 2025, https://docs.k3s.io/installation/packaged-components
- Networking | K3s, accessed on August 6, 2025, https://docs.k3s.io/networking
- Basic Network Options – K3s, accessed on August 6, 2025, https://docs.k3s.io/networking/basic-network-options
- Advanced Networking & Custom CNI – K3s, accessed on August 6, 2025, http://www.kevsrobots.com/learn/k3s/15_custom_cni.html
- MicroK8s – Zero-ops Kubernetes for developers, edge and IoT, accessed on August 6, 2025, https://microk8s.io/
- Snap refreshes – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/snap-refreshes
- Configuring MicroK8s services, accessed on August 6, 2025, https://microk8s.io/docs/configuring-services
- High Availability (HA) – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/high-availability
- What’s the difference between k3 vs microk8’s? – Discuss Kubernetes, accessed on August 6, 2025, https://discuss.kubernetes.io/t/whats-the-difference-between-k3-vs-microk8s/15725
- Installing MicroK8s Offline or in an airgapped environment, accessed on August 6, 2025, https://microk8s.io/docs/install-offline
- Get started – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/getting-started
- Install Microk8s offline. Introduction : | by gajjarashish | Medium, accessed on August 6, 2025, https://medium.com/@gajjarashish/install-microk8s-offline-d16ebdb348aa
- Create a MicroK8s cluster – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/clustering
- Microk8s is it good option? : r/kubernetes – Reddit, accessed on August 6, 2025, https://www.reddit.com/r/kubernetes/comments/1i9nu3o/microk8s_is_it_good_option/
- MicroK8s Addons, accessed on August 6, 2025, https://microk8s.io/docs/addons
- MicroK8s CNI Configuration – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/configure-cni
- Addon: KubeOVN – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/addon-kube-ovn
- Add on: Multus – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/addon-multus
- Choosing Your Local Kubernetes Companion: A Developer’s Guide to Minikube, k0s, k3s, and MicroK8s – DEV Community, accessed on August 6, 2025, https://dev.to/mechcloud_academy/choosing-your-local-kubernetes-companion-a-developers-guide-to-minikube-k0s-k3s-and-microk8s-7g0
- k0s vs k3s vs microk8s — for commercial software : r/kubernetes – Reddit, accessed on August 6, 2025, https://www.reddit.com/r/kubernetes/comments/1lzwb7t/k0s_vs_k3s_vs_microk8s_for_commercial_software/
- CIS 1.24 Self Assessment Guide – K3s – Lightweight Kubernetes, accessed on August 6, 2025, https://docs.k3s.io/security/self-assessment-1.24
- CIS Hardening Guide – K3s, accessed on August 6, 2025, https://docs.k3s.io/security/hardening-guide
- K3s Hardening Guides – Rancher, accessed on August 6, 2025, https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide
- CIS cluster hardening – MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/cis-compliance
- Automated Upgrades | K3s, accessed on August 6, 2025, https://docs.k3s.io/upgrades/automated
- Manual Upgrades – K3s, accessed on August 6, 2025, https://docs.k3s.io/upgrades/manual
- Upgrading MicroK8s, accessed on August 6, 2025, https://microk8s.io/docs/upgrading
- Deploy SMARTER Demo using K3s – Arm Learning Paths, accessed on August 6, 2025, https://learn.arm.com/learning-paths/embedded-and-microcontrollers/cloud-native-deployment-on-hybrid-edge-systems/k3s/
- Deploying Kubernetes (K3S) to an ARM based VM on Oracle with ArgoCD, Cert Manager, Gitlabs CI and AWS ECR access | by Dan Bowden | Medium, accessed on August 6, 2025, https://medium.com/@danbowden/deploying-kubernetes-k3s-to-an-arm-based-vm-on-oracle-with-argocd-cert-manager-gitlabs-ci-and-2ff7e01cbbeb
- Trying K3s on ARM, Part 1 – unixorn.github.io, accessed on August 6, 2025, https://unixorn.github.io/post/k3s-on-arm/
- Installing MicroK8s on a Raspberry Pi, accessed on August 6, 2025, https://microk8s.io/docs/install-raspberry-pi
- Microk8s on armhf architecture · Issue #719 – GitHub, accessed on August 6, 2025, https://github.com/ubuntu/microk8s/issues/719
- MicroK8s – Low-ops, minimal Kubernetes, for cloud, clusters, Edge and IoT | Hacker News, accessed on August 6, 2025, https://news.ycombinator.com/item?id=27916178