Edge & IoT Blueprint
This blueprint is in active design. No committed timeline. Content reflects planned architecture based on platform foundation and air-gap capabilities.
Purpose: For platform engineers and IoT architects, explains the planned Edge & IoT blueprint for lightweight distributed clusters with store-and-forward GitOps and device ingestion.
Overview
Edge and IoT deployments need clusters that run on constrained hardware, operate offline for extended periods, and ingest data from device fleets. This blueprint extends the platform foundation with lightweight cluster profiles, offline-first GitOps, and device ingestion patterns (MQTT/AMQP).
Key Capabilities
| Capability | Description | Foundation Component |
|---|---|---|
| Lightweight Clusters | Right-sized profiles for constrained hardware | Kubespray with reduced resource footprint |
| Offline GitOps | Store-and-forward reconciliation during connectivity loss | FluxCD + local Gitea mirror (air-gap pattern) |
| Device Ingestion | MQTT and AMQP protocols for device fleet data | Strimzi MQTT Bridge (from streaming blueprint) |
| Air-Gap First | Signed packages for fully disconnected sites | openCenter-AirGap three-zone model |
| Fleet Management | Consistent configuration across hundreds of edge sites | Git-based overlays + FluxCD per-site reconciliation |
| ARM64 Support | Workloads on ARM-based edge hardware | Platform images built for multi-arch (planned) |
Edge Cluster Profiles
| Profile | Control Plane | Workers | Resources | Use Case |
|---|---|---|---|---|
| Micro | 1 node (combined) | 0 | 4 CPU, 8 GB RAM | Single-purpose gateway/sensor |
| Mini | 1 node (combined) | 1–2 | 8 CPU, 16 GB RAM | Small retail/branch site |
| Standard | 3 nodes (HA) | 2–4 | 16 CPU, 32 GB RAM | Medium edge site |
| HA Edge | 3 nodes (HA) | 4+ | 32+ CPU, 64+ GB RAM | Large site with high availability |
Offline Behavior
When an edge site loses connectivity:
- FluxCD continues reconciling from local Gitea mirror
- Observability stack runs locally (Prometheus, Loki)
- Alerts route to local notification channel
- Changes queue in local Git; sync when connectivity returns
- Device data buffers locally; forwards to central when available
When connectivity returns:
- Local Gitea syncs with central repository
- Queued changes reconcile
- Buffered telemetry and device data forwards to central
- Fleet management verifies site convergence
Service Comparison (Core vs Edge)
| Service | Core DC | Edge Site | Notes |
|---|---|---|---|
| Prometheus | Full | Full (local) | Federated to central when connected |
| Grafana | Full | Optional | Central dashboards aggregate edge metrics |
| Loki | Full | Full (local) | Local retention, forward when connected |
| Kyverno | Full | Full | Same policies at every site |
| FluxCD | Full | Full | Reconciles from local mirror |
| Velero | Full | Reduced | Local backup target, remote when connected |
| Harbor | Full | Not deployed | Images served from bastion registry |
| Keycloak | Full | Cached tokens | Operates with cached OIDC tokens during offline |
Composition
Relationship to Telco Blueprint
The Telco blueprint addresses similar fleet-management and edge concerns for telecommunications infrastructure. Key differences:
- Telco focuses on network function workloads, carrier-grade reliability, and central DC → edge site patterns
- Edge & IoT focuses on constrained hardware, device ingestion protocols, and extended offline operation
Both share air-gap deployment patterns and fleet-wide GitOps consistency from the platform foundation.
Further Reading
- Platform Foundation — services available at edge sites
- Telco Blueprint — fleet management for telco
- Streaming Blueprint — MQTT Bridge for device ingestion
- Blueprint Catalog — all blueprints with status