Today, Kubernetes is the default way to run containerized software in the data center. Teams already think in terms of manifests, overlays, and Helm charts. Deployments are declarative, rollouts are automated, and the solution is familiar enough that most engineers can operate it without a second thought. That default is now being asked to do the same job at the edge, where it was never designed to do so.
Retail chains run point-of-sale systems on Kubernetes. Manufacturers run inspection and quality control software on it. Telecom operators run network functions on it, distributed across thousands of cell sites and customer premises. In each case, the appeal is the same: keep the platform development teams already know, and extend it to hardware that lives outside the data center.
The hardware at the edge, however, does not behave like data center hardware. A single-board computer or a small industrial gateway does not have the memory or CPU headroom that Kubernetes was built around. And, unlike thousands of servers sitting within a stable, high-bandwidth network, an edge device may rely on an intermittent satellite link or sit behind a firewall the developer does not control.
Similarly, today’s edge use cases are not the focus of cloud-native management solutions, and it shows in what the workflows assume. Cloud-native delivery tools generally infer neither constraint – hardware nor access – exists. When a rollout fails on a device on the other side of the world, the standard response – SSH in, inspect the pod, redeploy – depends on a level of reachability that edge deployments, by nature, cannot guarantee.
Lightweight distributions like K3s solved the first half of this problem. Stripped down and single-binary, K3s runs Kubernetes on hardware that would never support a full Kubernetes build while preserving the API structure teams already use. The manifests, overlays, and charts still apply.
Kubernetes is now small enough to fit on a device, but how do you manage a fleet of them?
Orchestration was always the focal point
Kubernetes exists because running one container is easy, and running thousands of them is not. Containers made it possible to isolate an application and its dependencies from the underlying system – another step in a lineage that began with virtual machines, allowing a single physical machine to host multiple isolated environments. Isolation solved one problem and created another: fleet management. As the number of isolated environments grows, someone must decide where each one runs, keep it healthy, and update it without taking the entire system down. Kubernetes is the layer that took on that job. It exists to orchestrate containers at a scale no engineering team could reasonably manage by hand.
K3s applies the same design, down to a single Raspberry Pi or an industrial gateway. But shrinking Kubernetes to fit one device does not shrink the underlying problem; it just moves it. A fleet of a thousand K3s devices in the field is still a thousand independent Kubernetes instances, each running its own control plane and each capable of drifting out of sync. Without a centralized management system for all the devices as a fleet, an operator is back to updating heterogeneous devices one at a time. This already manual process runs over the same unreliable network conditions that made management hard to begin with. Without a software management solution, the fleet requires significant engineering resources to optimize and additional on-site visits from the software team, which in some cases are difficult or impossible.
K3s makes Kubernetes small enough to run at the edge. It does not, on its own, make a fleet of those devices manageable from a central source. This is where the value actually sits. Closing the management gap turns a collection of individually-running edge devices back into a single system an operator can easily manage – the same premise that made Kubernetes worth adopting in the first place, restored at the scale edge deployments actually operate at.
Top three challenges with K3s at scale
Three things tend to go wrong when teams try to run K3s fleets at the edge without a fleet-management layer built for the environment.
The first challenge is complexity. A cloud Kubernetes cluster typically lives behind consistent networking, with nodes that rarely go offline unexpectedly. An edge fleet is the opposite: heterogeneous hardware, unpredictable connectivity, and devices that may drop off the network for hours or days at a time. GitOps and CI/CD pipelines built for the former don't seamlessly accommodate the latter – they tend to assume a rollout either succeeds promptly or fails loudly, with little accounting for a device that simply isn't reachable right now but will be later.
The second problem is fleet management itself. Kubernetes gives you tools to manage workloads within a cluster. It does not give you tools to manage many independent single-node clusters, each one a K3s instance itself. Standard Kubernetes has no native concept of "the same update, delivered reliably, to a thousand disconnected clusters." That layer must be built, or the fleet drifts – different devices ending up on different versions of both the OS and the workload, with no reliable record of which device is which and where.
The third element is ecosystem integration. Real deployments are rarely container-only. A device usually needs current OS and system-level components alongside the workloads running on top of them – security patches, updates, and driver changes. Kubernetes has no opinion about the OS beneath it. That gap has to be closed by another mechanism, or the container layer ends up perfectly orchestrated while the ground it sits on quietly falls out of date.
Each of these is a scale problem before it's a technology problem. K3s allowed Kubernetes to run on lightweight devices. It didn’t account for managing thousands of them in a single centralized area.
Closing the gap: Kubernetes with fleet-level management
The fix is not to replace Kubernetes at the edge; it's to put a fleet management layer underneath and around it, purpose-built for devices that are not always reachable.
The fleet management layer needs to operate over the same unreliable networks the devices already use. Rather than requiring an inbound connection to each device, it should allow each device to initiate outbound contact, on its own schedule, over a single outbound connection. No open inbound ports, no VPN into each site to manage.
This element matters most for container images and manifests. A standard Kubernetes workflow expects a device to reach out to a remote registry and pull what it needs, a real dependency on a container registry, whether the connection is reliable enough to support it. An edge device relying on a poor cellular link or an intermittent satellite connection can’t count on that. The fleet management layer removes this dependency entirely. Workloads are delivered to the device as part of the same release process as everything else, with no registry to reach and no pull required mid-rollout. When a device is offline, it simply picks up where it left off the next time it connects. It is not treated as a failure, but as the expected behavior of an edge fleet.With the fleet management layer in place, both halves of the stack are covered from a single point of control. The OS and K3s runtime can be updated as a unit, with automatic rollback if an update fails – the same operational safety net a data-center server gets, extended to a device with no engineer standing next to it. The workloads running on top are managed as Kubernetes expects: an updated container image and manifest, delivered to the fleet as a single release rather than pushed to devices one by one.
The practical effect is that an edge device is no longer a special case. It's provisioned, updated, and observed the same way a server in a cluster would be, just reached differently, and tolerant of a network that traditional servers were never designed to run on.
Unleashed possibilities with a fleet-managed edge
Once fleet management is handled, the majority of what Kubernetes was designed to deliver actually occurs.
Update reliability stops depending on the network. A rollout to a thousand devices doesn't require a thousand devices to be simultaneously reachable; it requires each one to check in when it can and pick up what's waiting.
Fleet visibility becomes real-time, not aspirational. An operator can see which version of the OS and which version of each workload are running on every device, regardless of where the device sits or how it connects. The same inventory and compliance picture that a cloud-native team takes for granted is now extended to hardware in the field.
Resource allocation improves on both the engineering and financial fronts. Teams spend their time on the applications they’re actually trying to ship, not managing drift across a fleet of independent clusters. And the same benefits show up in the budget: fewer site visits, fewer one-off fixes, and a longer hardware lifespan overall.
K3s made Kubernetes small enough for the edge. Fleet management is what makes it worth running there.
See how it works
To understand the technical implementation in depth – from update modules and A/B partitioning to GitOps-driven container delivery and device onboarding – the full technical details are available on Mender Hub.
Explore the technical implementation on Mender Hub
