Kubernetes for Industry and IoT

Kubernetes in industry

Over the last few years I have seen a sharp rise in requests to adopt and implement Kubernetes in industrial settings, both at startups and at established companies. Kubernetes gets picked to automate releases and the application lifecycle, to handle high availability, and to meet the requirements of off-the-shelf applications that by now run on Kubernetes.

The requests come in two kinds: projects in the datacenter and in the cloud, and software to ship and manage directly inside the plants, at the edge.

Datacenter and cloud: often the first cloud native architecture

The first kind covers new projects or modernization projects. The difference from other sectors is that cloud native technologies are still barely adopted here. In fintech, for example, you almost always arrive after years of cloud native, with platforms already in place and habits already formed, not always good ones. In industry, adoption is recent, and Kubernetes is often the first architecture of this kind.

That is an opportunity: you can start with the right practices from day one, instead of correcting entrenched habits.

Edge and plants: hardware and connectivity

Shipping and managing software inside industrial plants poses different challenges, and not only at the infrastructure level.

The hardware changes, and that pushes toward lean distributions with less management complexity, such as k3s or MicroK8s.

And above all, the connectivity changes. A remote site can have a flaky line, no redundancy, sometimes no connection at all for hours. An architecture designed for the datacenter takes a very good connection for granted. In plants, instead, you have to think not only at the infrastructure level but above all at the application level, with all the problems that come with distributed systems. You cannot, for example, take for granted that the data produced at the edge will reach a centralized database within a predictable time.

A single node per site?

In many plants the cluster is a single machine. That is not a shortcut: it is often the right choice, because it is cheap, easy to manage and, with a lightweight distribution, does everything that is needed. But it has to be weighed clearly, site by site.

A single-node cluster has no redundancy: if the machine stops, everything running on the site stops until it is replaced. So before choosing it you need to answer a few questions. What happens to production if the node is down for a day? How quickly can the hardware be replaced and the cluster state restored, and is there a backup to restore it from? Are there applications that must stay available regardless?

Where the answer is that downtime is tolerable and recovery is fast and tested, a single node is enough. Where it is not, you move to multiple nodes, or you keep the critical application outside the cluster. That decision is part of the design, it does not come after the first failure.

A case: data ingestion for an IoT startup

For a post-seed IoT startup I built an infrastructure that is part cloud and part bare metal, which made the onboarding of more than 10 industrial sensor providers automatic while keeping operating costs under control. Once it was up, the platform was handed over to the in-house team, which kept developing it.

How I work

As with any Kubernetes adoption, the first step is to understand whether it makes sense in your case, and in what form. Only then do we decide the model: how many clusters, how many nodes per site, which distributions, what stays in the datacenter and what goes to the plants. I cover this in more detail on the Kubernetes consulting page.

The goal does not change: an in-house team able to run the platform on its own. You get there through hands-on mentoring and, where needed, a Kubernetes course that gives everyone a common foundation.