Kubernetes is the gold standard for container orchestration. No argument there.

And it's well earned. Kubernetes runs a huge share of the world's cloud workloads, and every major cloud provider sells it as a managed service.

So when industrial companies start running containers on the plant floor, the conclusion seems obvious: the edge should run Kubernetes too.

Or... should it?

I'm not going to tell you Kubernetes is bad. It isn't. The question is a different one: is it the simplest thing that solves the problem we actually have at the edge?

And, just as important:

"Who is going to operate it?"

‍

What Kubernetes Was Built For

Let me start by giving some credit to Kubernetes, because it's one of the most impressive pieces of infrastructure software ever written. When a container dies, Kubernetes brings it back to life. You tell it what state you want, and it keeps working tirelessly to make that state a reality. It scales services up and down, balances the load, and rolls out new versions without downtime. In a data center running hundreds of microservices, that's pretty close to a superpower.

But those superpowers come with a few assumptions. Kubernetes was designed for an environment where:

• The network is always available.
• Nodes are interchangeable, so workloads can run anywhere.
• Resources are plentiful, and you can always add another node.
• A dedicated platform team is there to operate the cluster.

In the cloud, all four tend to be true. On the plant floor, well... things get a little more complicated.

‍

What's Different at the Industrial Edge

The network can't be taken for granted. Kubernetes assumes that the control plane and worker nodes can communicate reliably. But at a remote substation, a water treatment plant, or a wind farm, connectivity can be intermittent or sometimes disappear for days. Projects like KubeEdge have emerged to address precisely this challenge, which tells you something: offline operation is not native, it's added on top.

Resources are constrained. The usual answer is: "Use K3s. It's lightweight." And by Kubernetes standards, it is. But its own documentation puts the memory footprint of a minimal K3s server at around 1.2 to 1.4 GB of RAM, before you deploy a single application. On an industrial PC with just 4 GB, that's roughly a third of the available memory committed to the orchestration layer rather than the applications doing the actual work. And memory footprint is only part of the story. K3s reduces the overhead, but it doesn't remove the underlying complexity. Lightweight Kubernetes is still Kubernetes.

Nodes are not interchangeable. In the cloud, the scheduler's job is to find a suitable node for each workload. At the industrial edge, the physical location of that workload can be just as important as its compute requirements. The application reading the vibration sensor on Pump 4 needs to run on the device connected to Pump 4. Not on some other node across the plant. Of course, Kubernetes gives you node selectors and affinity rules to enforce placement, but then you spend your time fighting the scheduler to stop it from doing its job.

The network is part of the physical process. Industrial applications communicate with the world through Modbus over serial links, OPC UA to PLCs on segmented networks, and MQTT through tightly controlled firewalls. These aren't just endpoints on a virtual network; they're interfaces to physical equipment and operational technology. Kubernetes networking introduces another abstraction layer between applications and those interfaces. As a result, many industrial deployments end up with host networking and privileged containers, which means switching off the very abstraction you were paying for.

‍

The Real Cost Isn't CPU. It's Tickets.

All of the above is technical, and technical problems have workarounds.

The real problem is human.

Kubernetes is hard. Even among organizations that already run it in production, 40% say they lack the skills and people to manage it, according to Spectro Cloud. And those are IT teams that chose it. Now hand it to an OT team whose job is keeping a production line running.

So OT does the only thing it can: it depends on IT. And that hurts everyone.

• It hurts OT, because they lose their independence. Every new app, every config change, every new sensor becomes a ticket. Then another one. Then the 300th. The people who know the process best can't touch the system that runs it.
• It hurts IT, because they end up maintaining a platform for users who don't speak its language, solving tickets for problems they don't fully understand, on a plant floor they rarely visit. The friction goes both ways, and nobody enjoys it.

And there's a worse version. One of the companies we work with didn't depend on their IT department. They depended on an external consultancy that had built their Kubernetes infrastructure and was maintaining it for them. Every change, however small, had to be scoped, quoted, and scheduled. Changes were slow, painful and, above all, expensive. They weren't operating an edge platform. They were renting access to their own plant.

Which brings us back to an earlier article: we're asking OT engineers to become the IT-OT unicorn. And we already agreed unicorns don't exist.

‍

The Simplest Thing That Works

There's an old engineering principle worth remembering:

"Use the simplest technology that gets the job done."

Kubernetes is extraordinarily configurable. That's one of its greatest strengths in the cloud, but at the edge, that flexibility comes at a cost. Every configuration option is something someone has to understand, document, secure, and maintain. Configurability isn't free. You pay for it in complexity, every single day.

And a typical edge node is no data center. It's an industrial PC running a handful of containers: a protocol connector, a message broker, a database, perhaps an ML model and a dashboard. You don't necessarily need a full orchestration platform to run that stack. You need something that fits the job.

There's a perfectly good ladder for that:

1. Docker to package and run the applications.
2. Docker Compose to describe the whole node in one readable file.
3. Docker Swarm, if you need clustering and high availability across a few nodes.

Each step adds capabilities only when you need them. You start with the simplest thing that works and move up when the requirements demand it.

That's the opposite of starting with everything and spending months figuring out what you can safely turn off.

‍

One Platform to Rule Them All?

Now let's look at this from the IT department's perspective, because they have good reasons for wanting standardization, too.

IT wants one orchestration platform across the company. One way to deploy, one way to secure, one way to monitor, one set of skills. That's how organizations have standardized email, ERP, and countless other corporate services. So why should the edge be any different?

Because not all workloads are created equal, and neither are the people operating them.

Outlook and SAP serve users with broadly similar expectations, wherever they sit in the organization. But industrial edge computing brings two very different worlds together:

• IT runs dynamic, interchangeable workloads in data centers and the cloud, managed by teams specialized in infrastructure and platform operations.
• OT runs applications tied to specific machines and physical processes, where reliability and keeping the production line running come first.

Force one tool on both, and one of them will always be using the wrong tool.

So perhaps the answer isn't one platform for everything. Perhaps it's two platforms, each doing what it does best: Kubernetes in the cloud and data center, operated by IT; and a simpler, Docker-based platform at the edge, designed to let OT manage its own applications and infrastructure.

This doesn't mean abandoning standardization. It means standardizing the right things.

IT should define and enforce the guardrails: security policies, approved container images and registries, identity and access management, network segmentation, and observability requirements. OT should manage day-to-day operations within those guardrails, without needing to raise a ticket every time the plant needs a change.

Standardize the rules. Let the runtime fit the environment.

‍

So, Is Kubernetes Too Much?

In the cloud, no. At the industrial edge, often yes. Not because Kubernetes is bad technology, but because it solves problems many edge deployments don't have while creating one they can't afford: a dependency on people who aren't there when the plant needs them.

So before choosing an orchestrator, ask a simpler question.

"When Line 3 goes down in the middle of the night, who's going to fix it?"

If the answer is "we'll open a ticket," you have chosen the wrong tool.

‍

About Barbara

Barbara enables industrial organizations to deploy, orchestrate, and continuously manage distributed applications and AI models directly at the edge — where latency, bandwidth constraints, and data sovereignty cannot be compromised.

Built for complex environments with SCADA systems, PLCs, legacy protocols, and heterogeneous hardware, Barbara helps IT and OT teams move beyond pilots and scale secure edge deployments to thousands of nodes.

If you're working on similar challenges or exploring how edge platforms can support your industrial initiatives, explore more insights on our blog or get in touch with our team to continue the conversation.

Alternatively, you can also start using the platform today.