# Large-Scale Edge Management with Kubernetes (PowerX) > [!question] Lingering Questions > - What actually composes the ~700MB/device/day figure — control-plane chatter, metrics, or image pulls? Undecomposed, it can't be optimized. > - What does 1.4TB/day (700MB × 2,000 devices) actually cost across real connectivity types? The talk never does this multiplication. > - Was "low operational cost" — one of the four stated requirements — ever actually met? It's listed and never revisited. > [!tip] Article Ideas > - "Vary where the agent runs, not whether it runs" — the collector-placement pattern (push on-device vs. pull-from-cloud, keyed to device memory) generalizes to any heterogeneous fleet observability design, including WordPress-adjacent device/host fleets. > [!link] Cross Reference > - [[Open Source Governance MOC]] — a real production case study of CNCF-adjacent tooling (K3s, Argo CD, OpenTelemetry, Prometheus) run at fleet scale > - This talk is one of three independent KubeCon Japan 2026 talks in this batch naming physical/operational constraints on infrastructure scaling — cross-reference [[Infinite Agents, Finite Kubernetes (SoftBank)]] and [[How CNCF Projects United Two Countries' Engineers (NTT-SK Telecom)]] > [!quote] Vocabulary > - **K3s** — single-binary lightweight Kubernetes distribution, chosen here for smallest memory footprint and ARMv7 support > - **DaemonSet** — a Kubernetes workload type that runs one copy of a pod per node; used here to deploy the metrics collector to every edge device ## Author's thesis An SRE at PowerX manages 2,000+ heterogeneous EV-charging and grid-battery edge devices (500MB–4GB memory range) as K3s worker nodes inside a single hybrid Kubernetes cluster whose control plane runs on GKE — extending existing cloud Kubernetes expertise to the edge rather than adopting a separate edge-management paradigm, at a disclosed and non-trivial bandwidth cost. ## Key arguments (≤3) 1. **Extend rather than duplicate**: since the team already ran Kubernetes on GKE, edge devices join the same cluster as K3s worker nodes rather than getting a separate management stack. 2. **Vary placement, not pipeline**: metrics collection uses one design (OpenTelemetry Collector → Prometheus) in two topologies — push from on-device for roomier hardware, pull from cloud for memory-constrained hardware — selected by device memory alone. 3. **State the cost honestly**: three years in production, with declarative management and self-healing as benefits, set against ~700MB/device/day of network overhead and harder troubleshooting — disclosed rather than omitted, which is unusual for a conference talk. ## Claim atoms ### Existing Kubernetes skill extends to edge fleets > [!quote] ID:rw_01kysr2qayd4hc2ctq3vq0ys2r > If your team already knows Kubernetes, you can use it for your edge fleet too. **Where/why**: Closing message, after the good-points/bad-points summary. Conditional on team capability rather than a claim that Kubernetes is optimal for edge — backed by three years across 2,000+ devices, with ~700MB/device/day disclosed as the price. ## Permanent candidates - **Vary where the agent runs, not whether it runs** — when a fleet spans a wide capability range, keep one pipeline and move the collection point between device and center; heterogeneity changes the topology, not the design. Strong candidate — concrete, reusable pattern with a real evidence base (eightfold memory range, three years production). ## Processing checklist - [ ] Get a breakdown of the 700MB/device/day figure before citing it as a fixed cost - [ ] Check whether ARMv7 support is still a live constraint for current lightweight K8s distros - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — a disclosed, costed production case study of CNCF-adjacent tooling run at real fleet scale - [[3. Resources/Literature Notes/Large-Scale Edge Management with Kubernetes (PowerX)]] — source video (KubeCon + CloudNativeCon Japan 2026)