Ten years ago the canonical industrial edge stack was a PLC from 2011, a SCADA server running Windows 7 Embedded, and a field engineer who drove three hours to restart a hung process. Today Gartner forecasts that 80% of custom edge software will be containerized by 2028. The direction is not in dispute. The question that actually matters is: which container runtime survives the conditions that factory floors impose?
This post argues the answer is systemd-native Podman Quadlets — not because Kubernetes is bad, but because the shape of the problem (brownfield hardware, air-gapped networks, OT teams with no Kubernetes operators) selects against a control-plane daemon by construction.
This is not a hypothetical runtime argument: the e-Kanban system that runs 20 cells and 400 bins from a single $4,000 box does it on exactly this substrate — systemd-native, no container-orchestration layer on the device (FTPFI Part 1).
The K3s Assumption Nobody States#
K3s is the lightest production-grade Kubernetes distribution available. It ships a real control-plane server process that runs continuously, manages cluster state in SQLite or etcd, exposes the Kubernetes API server on port 6443, and requires kubeconfig, kubectl, and at minimum 512 MB of RAM for the server node (per the K3s documentation). For an OT engineer who manages that node, it also requires knowing what a CRD is, why a pod is stuck in CrashLoopBackOff, and how to rotate a kubeconfig credential.
That is a reasonable ask on a cloud team. It is an unreasonable ask on a team whose primary tool is a SCADA HMI and whose change window is four hours during a planned maintenance shutdown on a Saturday night.
The K3s argument has always carried an invisible assumption: a purpose-built, well-connected compute node and a team with Linux operations fluency. On greenfield industrial deployments — a new factory line, a new process island with modern hardware — that assumption sometimes holds. On brownfield factory floors, which represent the majority of industrial edge deployments today, it often does not.
What Quadlets Are (and Are Not)#
Podman Container Tools was accepted to the CNCF Sandbox on 2025-01-21 — a Red Hat donation announced at KubeCon NA 2024. The CNCF membership matters for two reasons: it signals neutral governance, and it gives procurement teams a foundation-backed project to point to. This is not a Red Hat proprietary tool; it is an an open-source project under CNCF Sandbox governance (CNCF is a Linux Foundation project).
Quadlet is a feature of Podman, not a separate runtime. It works by shipping .container, .network, and .volume unit files — INI-format files that Podman’s systemd-generator processes at boot time into standard systemd service units. The result is a container workload managed entirely by systemd: started on boot, restarted on failure, stopped on shutdown, logged via journald. There is no orchestrator daemon. There is no API server. There is no cluster state.
The argument is not “no containers.” The argument is “no orchestrator daemon” — a precise distinction that determines whether your runtime attack surface is systemd alone, or a control plane a field engineer cannot read with systemctl status.
The .container Unit File#
A Quadlet file for a data-collection workload looks like this:
# /etc/containers/systemd/opcua-collector.container
[Unit]
Description=OPC-UA Data Collector
After=network-online.target
Wants=network-online.target
[Container]
Image=registry.example.com/ot/opcua-collector:1.4.2
PublishPort=4840:4840
EnvironmentFile=/etc/opcua-collector.env
Network=host
AutoUpdate=registry
Label=app=opcua-collector
[Service]
Restart=on-failure
RestartSec=10s
TimeoutStartSec=60s
MemoryMax=256m
CPUQuota=50%
[Install]
WantedBy=multi-user.target default.target
Drop this file in /etc/containers/systemd/. Run systemctl daemon-reload. The generator produces a opcua-collector.service unit that systemd supervises like any other service on the box. Enable it with systemctl enable --now opcua-collector. That is the entire operational surface.
MemoryMax=256m and CPUQuota=50% are cgroup constraints applied at the systemd layer — no container-runtime-level resource accounting to debug, no separate LimitRange to write. AutoUpdate=registry integrates with podman auto-update, which can be invoked by a timer or by Margo’s pull-based desired-state mechanism (described in Part 2).
The [Service] section is a verbatim systemd service stanza. An OT engineer who has previously written a systemd unit for any other daemon can read and modify this file without a Kubernetes course.
This is not a contrived shape. Part 2 walks a working example — a Node-RED workload delivered through Margo as a quadlet deployment profile — where a .container file of exactly this form is what unpacks from the OCI artifact at the end of the chain.
The Three Conditions That Select for Quadlets#
Brownfield hardware. Legacy edge nodes are often single-board ARM devices, refurbished industrial PCs, or embedded controllers with 2–4 GB of RAM and no guarantee of a stable network during boot. K3s requires at minimum 512 MB of RAM (per the K3s documentation), with the server process occupying much of that headroom before any workload runs. A Quadlet workload consumes the memory its own container image requires, nothing more. No resident daemon, no cluster API server, no etcd lease heartbeats.
Air-gapped networks. IEC 62443 Zone/Conduit model segments OT networks from IT and external networks. An air-gapped Level 1 or Level 2 network has no outbound internet connectivity. K3s requires either network access to pull images or a carefully pre-staged image bundle and an internal registry — plus the control-plane node must still reach the API server. A Quadlet workload pre-staged in a local OCI registry (or distributed via Margo OCI artifacts) requires no control-plane reachability. The Image= line points to a local registry IP. The system runs offline after initial provisioning.
Skills gap. The OT/IT integration gap is not primarily a tooling problem — it is a team-boundary problem. Expecting OT teams to operate Kubernetes control planes is a category error. The tools that survive are the tools that map onto what OT engineers already know. Every Linux-capable OT engineer knows systemctl start, journalctl -u, and how to read an INI file. Quadlets extend that existing mental model rather than replacing it with a new operational abstraction.
What Quadlets Do Not Do#
Quadlets do not replace Kubernetes for multi-node scheduling. If your edge deployment requires bin-packing workloads across a fleet of nodes, you need an orchestrator. Quadlets are a per-device runtime: one device, one systemd instance, one set of declarative unit files. Fleet-level coordination is Margo’s job (Part 2 of this series), not Quadlet’s.
Quadlets also do not provide network policies, service mesh, or RBAC. IEC 62443 network segmentation is implemented at the network layer (firewalls, conduits, unidirectional gateways) or at the OS layer (SELinux, AppArmor, seccomp), not inside Quadlet. The runtime’s security posture is what you apply to the systemd unit and the cgroup — which is auditable, durable, and does not require a certificate rotation.
For the Quadlet mechanics in depth — the Podman REST API, how libpod handles lifecycle, and the full systemd control surface — see the Device Control Plane series, which covers the broker-free, Margo-less device-local lifecycle in detail.
The Shop-Floor Arc#
The evolution arc on the industrial edge is not from PLC to Kubernetes. It is from vendor-locked, manually-operated, hours-to-recover infrastructure to systemd-native, declaratively-described, self-healing workloads that OT teams can read and operate without a cloud operations background.
Podman Quadlets sit at the convergence of three trends: containers as the packaging unit (Gartner’s 80% by 2028 forecast is not about Kubernetes, it is about OCI images); systemd as the universal Linux service manager already present on every modern embedded Linux distribution; and open, neutral-governance standards (CNCF Sandbox) as the selection criterion for industrial procurement.
The deck’s “K3s/Kubernetes” framing describes where the industry discussion was two years ago. The place that discussion has arrived is a runtime with no control plane to staff, no cluster state to backup, and no API server to secure — just systemd units that happen to run containers.
What Comes Next#
Part 2 of this series covers the interoperability layer: how Margo’s pull-based desired-state model coordinates Quadlet workloads across a fleet without a central orchestrator, and why port 443 + a brokerless pull architecture is what OT network segmentation actually permits.
For the full standards stack that makes every layer of this architecture auditable and governance-portable, see The Open Standards Stack of the Software-Defined Edge.
Leadership companions on javatask.systems: the capital-allocation argument behind underfunded edge substrate is in The Layer Your Capital Is Funding Is the Wrong One; the team-boundary root cause of the IT/OT skills gap is in The Skills Gap Is a Team-Boundary Problem; and the trust model behind dropping the orchestrator is in The Year I Stopped Trusting the Orchestrator.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.