Deploying software to 10,000 edge nodes requires a different paradigm than managing a centralized cloud cluster. Standard Kubernetes is too heavy for constrained edge environments.
Lightweight Kubernetes
K3s and MicroK8s strip out legacy cloud-provider integrations, providing a fully compliant Kubernetes API that runs efficiently on Raspberry Pis or industrial IPCs.
GitOps at the Edge
Edge nodes frequently lose connectivity. With GitOps (ArgoCD/Flux), edge nodes pull their desired state from a Git repo. If a node goes offline, it automatically reconciles its state the moment it reconnects.
K3s vs. Standard Kubernetes
| Aspect | Standard Kubernetes (kubeadm) | K3s |
|---|---|---|
| Binary Size | ~1+ GB across components | ~70 MB single binary |
| Memory Footprint | 512 MB+ minimum per node | As low as 250 MB per node |
| Default Datastore | etcd (multi-node cluster required) | SQLite for single-server; etcd optional for HA |
| Bundled Extras | None by default | Traefik, CoreDNS, local-path-provisioner included |
Joining an Edge Node to the Cluster
# On the server (control plane)
curl -sfL https://get.k3s.io | sh -
cat /var/lib/rancher/k3s/server/node-token
# On each edge agent node
curl -sfL https://get.k3s.io | \
K3S_URL=https://core-server:6443 \
K3S_TOKEN=<token-from-above> \
sh -GitOps Reconciliation Loop
A GitOps agent (Flux or ArgoCD) running on each edge node continuously diffs the live cluster state against the desired state declared in Git. This makes fleet management declarative and self-healing: instead of pushing updates to nodes, nodes pull their own configuration, so intermittent connectivity is a delay, not a failure.
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: edge-fleet-config
namespace: flux-system
spec:
interval: 5m
path: "./clusters/edge-retail-fleet"
prune: true
sourceRef:
kind: GitRepository
name: fleet-config-repo
targetNamespace: defaultFleet-Scale Operational Patterns
Managing 10,000 Nodes Without SSH
- Progressive rollout: Stage config changes to a canary group of edge sites (e.g. 1%) before fleet-wide rollout, since a bad manifest at 10,000 sites is a major incident.
- Zero-touch provisioning: New hardware boots with a minimal image, pulls its identity and full config from a provisioning service, and joins the cluster with no manual SSH step.
- Health aggregation: Stream node health to a central time-series store (Prometheus + remote-write) since polling 10,000 nodes individually from a dashboard does not scale.