Sailbird
Engineering Lab
Engineering Lab11 min read

Raspberry Pi as Edge Gateway and Fleet Control Node with K3s

A site-level reference: Raspberry Pi as K3s control plane, artifact cache, and telemetry gateway, with NVIDIA Jetson nodes focused on inference.

Raspberry Pi 5K3scontainerdRegistry cachePrometheusGitOpsNVIDIA Jetson
Service line: Edge AI Platform EngineeringPublished July 20, 2026

Architecture at a glance

Cloud holds desired state and observability. A Raspberry Pi runs the site gateway: K3s control plane, artifact cache, and telemetry forwarder. NVIDIA Jetson nodes stay focused on inference.

Cloud

Control and policy

  • Git-backed desired state and release promotion
  • Central artifact registry and secrets
  • Fleet observability backend and alerts
Site gateway

Raspberry Pi

  • K3s server for the site or regional cluster
  • Local image and model package cache
  • Telemetry buffer when the WAN is down
  • Optional protocol bridge (MQTT, OPC-UA, cameras)
Workers

Inference nodes

  • NVIDIA Jetson Orin Nano (and larger Jetson) agents
  • Pinned inference containers and model packages
  • Site and cohort labels for staged rollouts
Site pattern

One gateway, many workers

Pi gateway

K3s server · cache · forwarder

Jetson A

K3s agent · inference

Jetson B

K3s agent · inference

Jetson C

K3s agent · inference

The Raspberry Pi absorbs always-on site services. Jetson devices keep GPU capacity for inference instead of doubling as control-plane and cache nodes.

Gateway lifecycle

From Pi bootstrap to a site that can enroll Jetson workers, stage artifacts, and keep operating when the WAN drops.

Provision
Bootstrap Pi gateway identity
Control
Run K3s server at the site
Cache
Stage images and models
Join
Jetson agents enroll locally
Forward
Buffer and ship telemetry
Operate
Survive WAN outages

Overview

This lab documents a complementary pattern to our NVIDIA Jetson Orin Nano fleet reference. Inference belongs on GPU nodes. Always-on site services often do not. A Raspberry Pi is a practical place to run the site gateway: K3s control plane, local artifact cache, and telemetry forwarder.

The goal is a two-tier edge site. The Pi absorbs control and buffering work. Jetson devices keep thermal and memory headroom for inference. Cloud still owns desired state, promotion policy, and long-term observability storage.

Problem this reference solves

Many edge AI designs either put the control plane in the cloud only, or overload every Jetson with registry pulls, API server duties, and log shipping. Cloud-only control struggles when the factory WAN is slow or down. Jetson-as-everything wastes GPU capacity on platform chores.

A site gateway gives the fleet a local anchor. Workers join a nearby API endpoint. Releases stage once at the site. Telemetry can buffer when the uplink fails. Operators still promote through Git and cohorts; they do not invent a second operational culture for the Pi.

  • Cloud-only control planes that stall when the site is offline
  • Jetson nodes pulled into registry and control-plane roles they should not own
  • Repeated WAN downloads of the same image across every device on a site
  • No local place to enroll devices or buffer telemetry during outages

Reference architecture

Cloud holds Git-backed desired state, the source of truth for releases, and the long-term metrics backend. Each site runs one or more Raspberry Pi gateways. The Pi hosts a K3s server (or a hardened agent that fronts a regional control plane), a pull-through or mirror cache for images and model packages, and a forwarder that ships metrics and logs when connectivity allows.

NVIDIA Jetson Orin Nano and larger Jetson devices join as K3s agents. They run inference workloads and a thin telemetry sidecar. Site labels and rollout cohorts still control promotion. The Pi changes where control and caching live, not whether the fleet is operated from Git.

Why Raspberry Pi for the gateway

Raspberry Pi 5 (and comparable industrial Pi-class boards) balances power draw, unit cost, and enough CPU and storage for control-plane and cache duties. It is the wrong place for heavy vision models. It is a strong place for always-on site services that must stay up when GPU nodes reboot for updates.

When a site needs more I/O or redundancy, the same pattern scales to a small pair of Pis or an industrial ARM gateway. The operational model stays fixed: gateway for site services, Jetson for inference, cloud for policy and history.

  • Raspberry Pi 5: reference site gateway for cost-aware deployments
  • Industrial Pi-class or ARM gateways when the environment demands them
  • Paired gateways when the site needs control-plane redundancy
  • NVIDIA Jetson family: inference workers, not default control nodes

Software stack

The stack stays portable. We do not require a proprietary edge OS for the gateway role. Raspberry Pi OS or a hardened Linux baseline is enough, with K3s, containerd, and standard observability agents. Git remains the source of truth for what should run at the site.

  • OS: Raspberry Pi OS or hardened Linux on Raspberry Pi 5
  • Kubernetes: K3s server on the gateway, agents on Jetson workers
  • Cache: local registry mirror or pull-through for images and model packages
  • Delivery: GitOps overlays with site and cohort labels
  • Observability: Prometheus node metrics, buffered remote write, structured logs
  • Optional bridges: MQTT, camera ingest, or protocol adapters on the Pi

K3s control plane on the Raspberry Pi

The Raspberry Pi runs the site K3s server with a small footprint: API server, scheduler, and controllers sized for a limited worker count. Jetson nodes join with the site API URL and a short-lived join token issued through enrollment, not a password shared on a USB stick.

Node labels separate roles clearly. The Pi is labeled as gateway or control. Jetson nodes are labeled by hardware profile, site, and cohort. Workloads that need a GPU never schedule onto the Pi by accident.

  • Pi labeled for control-plane and gateway roles
  • Jetson agents labeled by hardware, site, and rollout cohort
  • Taints keep inference off the gateway and control duties off GPU nodes
  • Desired state applied from Git, including gateway Deployments
bootstrap-pi-server.shbash
Illustrative
# On the Raspberry Pi gateway after baseline OS + identity
curl -sfL https://get.k3s.io | sh -s - server \
  --node-name "pi-gateway-${SITE_ID}" \
  --node-label "sailbird.io/role=gateway" \
  --node-label "sailbird.io/site=${SITE_ID}" \
  --node-taint "node-role.kubernetes.io/control-plane=true:NoSchedule" \
  --tls-san "k3s.${SITE_ID}.site.local"

Fragment only: TLS SANs, join tokens, and device identity come from enrollment, not a shared lab script.

Artifact cache and bandwidth

A site with twenty Jetson devices should not pull the same multi-gigabyte image twenty times over LTE or a contended factory uplink. The Raspberry Pi hosts a local cache. Workers pull from the site endpoint. The gateway reconciles with the central registry on a schedule or when bandwidth allows.

Model packages follow the same idea. Stage once at the site, verify checksums, then let workers consume the local copy. Canary cohorts still matter: the cache does not remove the need for health-gated promotion.

  • Pull-through or mirror cache on the Pi for container images
  • Scheduled sync windows for constrained WAN links
  • Checksum verification before workers consume a staged package
  • Keep the previous release cached for fast rollback at the site
registry-cache.yamlyaml
Illustrative
apiVersion: apps/v1
kind: Deployment
metadata:
  name: site-registry-cache
  labels:
    app: site-registry-cache
    sailbird.io/role: gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: site-registry-cache
  template:
    metadata:
      labels:
        app: site-registry-cache
    spec:
      nodeSelector:
        sailbird.io/role: gateway
      containers:
        - name: cache
          image: registry.example.com/platform/registry-cache@sha256:c4d1...
          env:
            - name: UPSTREAM_REGISTRY
              value: registry.example.com
            - name: SITE_ID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['sailbird.io/site']
          ports:
            - containerPort: 5000

A site cache is a gateway workload. Workers point at the local endpoint; the Pi reconciles with the central registry.

Joining Jetson workers

Workers should discover the site control plane through enrollment, not tribal knowledge of an IP address. The Pi publishes a stable site API name. Jetson devices receive join material after identity is established, then register with hardware and cohort labels.

This keeps the operational story aligned with the Jetson fleet lab: replace a board, re-run bootstrap, return to desired state. The difference is that the first hop is the site gateway, not a cloud API that may be unreachable during commissioning.

join-jetson-agent.shbash
Illustrative
# On each Jetson after JetPack + device identity
curl -sfL https://get.k3s.io | K3S_URL="https://k3s.${SITE_ID}.site.local:6443" \
  K3S_TOKEN="${NODE_TOKEN}" sh -s - agent \
  --node-label "sailbird.io/hw=jetson-orin-nano" \
  --node-label "sailbird.io/site=${SITE_ID}" \
  --node-label "sailbird.io/cohort=${COHORT}"

Jetson agents join the site K3s API hosted on the Pi. Labels keep hardware and cohort explicit.

Telemetry buffer and remote operations

When the WAN drops, inference should continue and local health should still be visible at the site. The Raspberry Pi runs a forwarder that accepts metrics and logs from workers, stores them briefly, and remote-writes when the uplink returns.

Cloud dashboards then show site-level lag as a first-class signal, not only per-device scrape failures. Alerts should distinguish offline workers from an offline site uplink so operators pick the right runbook.

  • Local scrape of gateway and Jetson node metrics
  • Buffered remote write with backpressure toward the cloud
  • Site uplink lag and worker last-seen as separate signals
  • Runbooks for WAN outage versus single-device failure
alerts/site-gateway.yamlyaml
Illustrative
groups:
  - name: site-gateway
    rules:
      - alert: SiteUplinkStale
        expr: |
          time() - site_remote_write_success_timestamp > 900
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Site {{ $labels.site }} has not forwarded telemetry"
      - alert: GatewayDiskPressure
        expr: |
          node_filesystem_avail_bytes{mountpoint="/var/lib/rancher"}
            / node_filesystem_size_bytes{mountpoint="/var/lib/rancher"} < 0.15
        for: 20m
        labels:
          severity: critical
        annotations:
          summary: "Registry/cache disk low on Pi gateway {{ $labels.instance }}"

Separate site uplink failure from a single Jetson going quiet so the runbook matches the failure.

Security and provisioning

The gateway is a privileged site asset. It holds join material paths, cache contents, and often a bridge into OT networks. Treat it with the same seriousness as a regional jump host: unique identity, short-lived credentials, disk encryption where the environment allows, and no shared root passwords baked into images.

Network policy should keep worker inference traffic, cache pulls, and OT bridges in explicit lanes. The Pi is not a place to casually expose SSH to the internet because commissioning felt urgent.

  • Unique gateway identity and enrollment at first boot
  • Short-lived join tokens for Jetson agents
  • Encrypted transport for registry sync and telemetry
  • Clear boundary between IT uplink, site LAN, and OT adapters

How this relates to the Jetson fleet lab

The Jetson Orin Nano lab focuses on inference workers: agents, model promotion, OTA canaries, and remote diagnostics. This lab adds the missing site tier. Together they describe a hybrid edge site that still speaks one operational language.

You can start with cloud-hosted K3s and Jetson agents only. Introduce a Raspberry Pi gateway when bandwidth, offline windows, or local enrollment make the cloud hop too fragile. The promotion and observability habits should not change when the gateway appears.

What this lab includes

This reference shows how Sailbird approaches two-tier edge sites: Raspberry Pi for gateway and control services, NVIDIA Jetson for inference, and cloud for policy and long-term operations.

  • Reference architecture for Pi gateway plus Jetson workers on K3s
  • Cache, enrollment, and telemetry patterns for constrained sites
  • Security baseline for a privileged site control node
  • A clear split of roles so GPU capacity stays on inference

Need a two-tier edge site?

We help teams design site gateways on Raspberry Pi alongside NVIDIA Jetson inference fleets, with the same GitOps and observability model across cloud and field.

Start a conversation

Ready to take your AI workloads to production?

Let's talk about your platform: cloud, hybrid, or edge. Start with a short, no-pressure conversation.

Start a conversationExplore services