K3s: Lightweight Kubernetes for Edge Computing and IoT Fleet Management

TL;DR:

• K3s is a CNCF-certified, production-grade Kubernetes distribution that fits in 70MB and runs on hardware as modest as a Raspberry Pi 4 with 512MB RAM
• It removes optional and cloud-specific Kubernetes components (no etcd by default, no cloud controller manager), replacing them with lighter alternatives suited to resource-constrained edge environments
• Organisations running distributed edge fleets — retail, manufacturing, utilities, telecoms — increasingly use K3s to standardise application deployment and lifecycle management across hundreds or thousands of sites

Running Kubernetes at the edge sounds like a contradiction. The tool that tames massive cloud clusters, running on a device with a few gigabytes of RAM and an unreliable 4G uplink. But the appeal is real: if you’re managing more than a handful of edge sites, you want consistent deployment patterns, declarative configuration, rolling updates, and health management — exactly what Kubernetes provides. K3s is how edge operators get those benefits without the operational overhead of full Kubernetes.

What K3s Is (and What It Isn’t)

K3s is a Kubernetes distribution built and maintained by Rancher (now part of SUSE), graduated to CNCF in 2023. It’s fully conformant with the Kubernetes API — anything that runs on standard K8s runs on K3s. The difference is in what it removes and what it replaces.

Removed from standard K8s:

• etcd (default persistence uses SQLite; etcd is optional for HA setups)
• Cloud controller managers (AWS, GCP, Azure integrations — not needed at edge)
• In-tree storage drivers (replaced with external CSI drivers where needed)
• Alpha and experimental features

Replaced with lighter alternatives:

• containerd instead of Docker as the container runtime
• Flannel for networking (simpler than Calico, lower overhead)
• SQLite for single-node or small cluster persistence
• Traefik as the default ingress controller

The result: a single binary under 70MB that ships everything you need to run a Kubernetes node. No separate etcd binary, no kubeadm, no separate containerd installation — just the k3s binary, a configuration file, and a systemd unit.

# Install k3s server (control plane + worker) on a single node
curl -sfL https://get.k3s.io | sh -

# On subsequent nodes, join as agents
curl -sfL https://get.k3s.io | K3S_URL=https://server-ip:6443 \
  K3S_TOKEN=<node-token> sh -

Resource Profile

The numbers that matter for edge hardware planning:

K3s runs reliably on Raspberry Pi 4 (2GB model), NVIDIA Jetson Nano, Intel NUC, and industrial x86 edge hardware. It also runs well on ARM64 — critical for the embedded and industrial edge market where ARM processors dominate.

Where Edge Operators Are Using K3s

Retail edge. Point-of-sale systems, digital signage, self-checkout kiosks, and back-of-house servers at retail locations are increasingly containerised workloads. K3s lets retailers manage application updates across thousands of store locations with the same GitOps tooling they use in their cloud. A promotion update that changes the pricing engine and the signage display can be rolled out to all stores simultaneously, with automatic rollback if health checks fail.

Industrial and manufacturing. Factory floor OT/IT edge servers running vision systems, anomaly detection models, and SCADA data collectors. K3s provides the orchestration layer; the specific industrial workloads run as containers. When a new version of the inspection model is trained centrally, it deploys to all production lines through the same Kubernetes update pipeline.

Telecoms and network edge. 5G multi-access edge compute (MEC) deployments at base stations use K3s as the orchestration layer for containerised network functions (CNFs). The lightweight footprint fits the constrained hardware at cell sites; Kubernetes-native scheduling handles workload placement decisions.

Utilities and energy. Substations, wind turbines, and solar farms increasingly have edge compute nodes running monitoring and control workloads. K3s manages these workloads in an environment where connectivity is intermittent and hardware is difficult to physically access.

Handling the Challenges of Edge Environments

Edge deployments have constraints that cloud Kubernetes doesn’t face. K3s addresses several of them directly.

Intermittent connectivity. K3s agents can operate in a disconnected state when the control plane is unreachable, continuing to run existing workloads. The synchronisation happens when connectivity is restored. For retail or utility use cases where WAN links can be flaky, this is essential.

No persistent volume infrastructure. At cloud scale, you attach EBS volumes or GCE disks. At the edge, you’re often working with local NVMe or even SD cards. K3s works with local-path provisioner out of the box, creating persistent volumes from a directory on the local disk. For edge workloads with modest storage requirements, this is sufficient.

Centralised fleet management. Managing K3s clusters across hundreds of sites requires a management layer above K3s itself. Rancher is the native choice — it’s built by the same team and provides a central management plane for multi-site K3s fleets, with unified deployment, monitoring, and upgrade management. Fleet (Rancher’s GitOps tool) handles continuous delivery of configuration changes across all sites from a single Git repository.

High Availability Configuration

Single-node K3s (one server, multiple agents) is the typical edge site configuration. For sites where uptime is critical and hardware redundancy is justified, K3s supports embedded HA using its built-in etcd:

# k3s server configuration for HA cluster
# /etc/rancher/k3s/config.yaml
cluster-init: true           # First server initialises cluster
tls-san:
  - "k3s-server.internal"
  - "192.168.1.100"

# Second and third servers join the cluster
curl -sfL https://get.k3s.io | K3S_TOKEN=<cluster-token> \
  INSTALL_K3S_EXEC="server --server https://first-server:6443" sh -

A three-node server cluster with embedded etcd gives you quorum-based HA. Practical for sites with multiple servers (industrial edge, large retail), overkill for a single-device kiosk deployment.

K3s vs Alternatives

K3s vs MicroK8s: MicroK8s (Canonical) is the main alternative, with broader snap-based addon ecosystem and tighter Ubuntu integration. K3s wins on minimum resource requirements and ARM support; MicroK8s has better tooling for single-developer local environments. Both are production-ready for edge use cases.

K3s vs KubeEdge: KubeEdge extends a cloud Kubernetes cluster out to edge nodes, with the edge nodes as leaf nodes of the central cluster. K3s is autonomous — each site runs its own cluster, potentially managed by a central Rancher instance but not dependent on cloud connectivity for basic operation. KubeEdge is better for tight cloud-edge integration; K3s is better for independent edge operation.

K3s vs raw containers (Docker/Podman Compose): For a single edge device running a few containers, Compose is simpler. K3s pays off when you have multi-node sites, need rolling updates, health-based restart, resource limits, or centralised management across many sites. The orchestration overhead is real; so are the operational benefits at scale.

Getting Production-Ready

K3s in production requires the same hygiene as any Kubernetes deployment: resource requests and limits on all workloads, liveness and readiness probes, backup of K3s state (the SQLite database or etcd snapshot), and monitoring that alerts on node failures and failed deployments.

For fleet management at scale, the combination of K3s + Rancher Fleet + a Git repository for configuration is the standard pattern. Configuration changes go into Git, Fleet picks them up and reconciles across all sites, and Rancher gives you a dashboard of deployment status across your entire fleet. It’s a significantly more manageable operational model than SSH-ing into individual edge nodes.

The CNCF certified K3s — meaning it passes the same conformance tests as standard Kubernetes. If your edge workloads run today, they’ll run on K3s.