TL;DR
Edge orchestration means deploying, updating, and monitoring containerized software across a fleet of industrial PCs from one control plane. With three machines, SSH and Docker Compose are enough. At thirty sites you want an orchestrator such as K3s, Portainer, or Azure IoT Edge. This guide covers the moving parts in plain English, and what they ask of your hardware.
Overview
Plant engineers have installed software on industrial PCs the same way for twenty years: image the drive, ship the box, hope nobody needs to touch it again. That stops working once AI models enter the picture, because models get retrained monthly or even weekly. Our guide to the AI model lifecycle at the edge covers why. The fix most teams land on is containers, the packaging format that runs the cloud, adapted for machines that sit in a cabinet behind a firewall. Orchestration is the layer that keeps those containers consistent across every box you own. It assumes a working network path between sites, which is its own project; see how to design a converged IT/OT network if that part is still open.
Edge orchestration in plain English
A container packages an application together with its dependencies so it runs identically on any Linux host. An orchestrator is software that decides which containers run on which machines, restarts them when they crash, and rolls out new versions without anyone driving to the site. The cloud version of this is Kubernetes. The edge version is usually K3s, a trimmed Kubernetes build whose agent runs in about 512 MB of RAM, or a lighter agent model like Portainer Edge or Azure IoT Edge.
How it works
Five layers, bottom to top. We use the fanless Nuvo-11000 and the Jetson-based NRU-220 as reference hardware here.
| Layer | What it does | Typical choices |
|---|---|---|
| Industrial PC | Runs the workloads at the machine | Nuvo-11000, NRU-220 |
| OS and container runtime | Hosts containers on Linux | Ubuntu 22.04 LTS, containerd |
| Orchestrator agent | Pulls images, starts containers, reports health | K3s agent, Azure IoT Edge runtime |
| Control plane | Holds desired state, schedules workloads | K3s server or Portainer, on-prem or cloud |
The agent on each box polls the control plane for its desired state. Change a deployment manifest once and every site converges on the new version. When a node drops offline, containers keep running locally and the agent reconciles after the link comes back.
Why it matters for edge AI
Inference workloads change faster than any other software a plant runs. A defect detection model that performed well in March can drift by June when an upstream supplier changes a coating. Without orchestration, the update means a technician, a USB stick, and a maintenance window at every site. With it, the retrained model ships as a new container tag and reaches forty sites in an afternoon. No truck rolls.
GPU access works inside containers as well. The NVIDIA Container Toolkit exposes a discrete RTX card in a Nuvo-9160GC to any container that requests it, and JetPack does the same for the Orin module in the NRU-220. The practical limit is usually disk: budget 10 to 20 GB of image storage per node so previous versions stay cached for rollback.
Real-world examples
A machine builder ships Nuvo-11000 units inside its inspection cells, each enrolled in the customer's Portainer instance. When the vision model changes, the OEM edits one manifest and every cell pulls the new image overnight.
A renewables operator runs K3s agents on cellular-connected boxes at remote substations, with the control plane in a regional office. Deployments tolerate the flaky backhaul because each node carries on with its last applied state until the link returns. The cabinet networking follows the pattern from our remote monitoring stack guide; a managed switch such as the PLANET GS-4210-8P2S provides 802.3at PoE for cameras plus two SFP uplinks.
Conclusion
Start with one box, containerd, and a private registry. Add the control plane when site count justifies it, not before. The hardware bar is modest: a quad-core CPU and 16 GB of RAM cover a K3s agent with room left over for inference. Follow Neteon on LinkedIn for more deep dives, or reach us at [email protected] or www.neteon.net to talk through an edge orchestration pilot.
Related Products
FAQs
Do I need Kubernetes to run containers on an industrial PC?
No. A single site runs fine on Docker Compose or plain containerd. Kubernetes, usually the K3s build, earns its complexity once you manage many sites and need automated rollouts, health checks, and rollback.
How much overhead does a K3s agent add?
Plan for roughly 512 MB of RAM and a few percent of CPU on the agent node. On a 16 GB machine like a Nuvo-11000 that leaves most of the system free for inference workloads.
Can containers use the GPU on these systems?
Yes. The NVIDIA Container Toolkit passes a discrete RTX GPU through to containers on x86 systems such as the Nuvo-9160GC, and JetPack provides the same for the Jetson AGX Orin module in the NRU-220.
What happens when an edge node loses its network connection?
Running containers are not affected. The agent keeps the last applied configuration, and when connectivity returns it reconciles with the control plane and pulls any updates it missed.
Is container orchestration safe to run on an OT network?
It can be, with the registry and control plane placed on the IT side of a firewall or DMZ, signed container images, and agents that only initiate outbound connections. That avoids opening inbound ports to the plant floor.
