What is Kubernetes?
Kubernetes (K8s) is an open-source platform that distributes containerised applications across a cluster of machines, monitors them, scales them and restarts them automatically, based on a desired state that you declare. Where Docker builds containers and runs them on a single host, Kubernetes handles orchestration across many hosts. Within OT and Industrial Automation, Kubernetes increasingly runs at the edge: MQTT brokers, OPC UA gateways, historians, analytics and AI inference for IIoT platforms. That makes it a core building block of IT OT Convergence, but not a replacement for real-time control.
🧠 How did Kubernetes originate and who maintains it?
Google announced Kubernetes in June 2014, basing its design on experience with Borg, the internal cluster system on which Google had run its own production workloads for years. Version 1.0 followed in July 2015, after which Google donated the project as the seed technology of the Cloud Native Computing Foundation (CNCF) under the Linux Foundation. In March 2018 Kubernetes became the first CNCF project to reach graduated status. The name is Greek for helmsman; K8s stands for the eight letters between the K and the s.
| Characteristic | Value |
|---|---|
| Programming language | Go |
| Release cadence | Three minor releases per year |
| Support per minor release | About 1 year of patches |
| Supported versions (November 2026) | 1.35, 1.36 and 1.37 |
| Official scalability limits | 5,000 nodes, 110 pods per node, 150,000 pods |
For OT, that release cadence matters most: a cluster you do not upgrade at least once a year soon runs a version without security patches. Make upgrades part of your patch management and lifecycle management.
🔧 How does a Kubernetes cluster work?
A cluster consists of a control plane, which decides what should run, and worker nodes, which run the containers. The architecture is built around a reconciliation loop: controllers continuously compare the desired state with the actual state and correct any difference.
| Component | Layer | Function |
|---|---|---|
| kube-apiserver | Control plane | Central API; all management and automation goes through it |
| etcd | Control plane | Distributed key-value store holding the full cluster state |
| kube-scheduler | Control plane | Places pods on nodes based on CPU, memory and rules |
| kube-controller-manager | Control plane | Runs the controllers that enforce the desired state |
| kubelet | Worker node | Agent that starts pods and reports their status |
| Container runtime | Worker node | containerd or CRI-O; since version 1.24 (May 2022) Docker Engine only through the cri-dockerd adapter |
| kube-proxy / CNI plug-in | Worker node | Service routing and pod network, for example Calico or Cilium |
Key objects you will meet in every OT deployment:
- Pod - the smallest executable unit: one or more containers sharing a network stack and storage
- Deployment - manages replicas, rolling updates and rollback, providing automatic recovery and scalability
- DaemonSet - one pod per node, useful for a protocol collector or logging agent on every edge node
- Service - a stable DNS name and load balancing for changing pods
- Namespace - logical separation per team, line or site; not a security boundary on its own
- ConfigMap and Secret - configuration and secrets outside the image; Secrets are stored unencrypted (only base64-encoded) in etcd by default unless you enable encryption at rest
- NetworkPolicy - firewall rules between pods; without a policy every pod can reach every other pod
🔄 Which Kubernetes variants suit the edge and OT?
A full Kubernetes cluster needs several servers and management expertise. Lighter distributions have emerged for the shop floor and remote stations.
| Variant | Origin | Typical OT use |
|---|---|---|
| Kubernetes (upstream) | CNCF | Data centre or central on-premises OT cluster |
| K3s | Rancher (SUSE), CNCF | Edge gateways; minimum 2 CPUs and 2 GB RAM for a server, 512 MB for an agent |
| MicroK8s | Canonical | Small clusters and lab environments, mainly on Ubuntu |
| KubeEdge | Huawei Cloud, CNCF graduated since October 2024 | Central cloud control plane with edge nodes that keep working offline |
| OpenShift | Red Hat | Enterprise platform with stricter security defaults |
With dozens of sites you usually do not run one cluster spanning every location, but a small cluster per site, managed centrally through GitOps or a fleet management tool. Configuration then lives in version control and configuration management, so every change is traceable.
🏭 Which OT workloads run well on Kubernetes?
Kubernetes suits workloads that are stateless or write their state to a database, and that can tolerate an interruption of a few seconds.
| Workload | Suitability | Notes |
|---|---|---|
| MQTT broker and Unified Namespace | Good | Clustered brokers with multiple replicas, often with Sparkplug B services |
| OPC UA, Modbus TCP and HTTP/HTTPS gateways | Good | Protocol conversion as a microservice per line |
| Historian and time-series database | Good, with persistent storage | StatefulSet with local or replicated disks |
| Web HMI, dashboards and reporting | Good | Scales with the number of users |
| AI Vision and Predictive Maintenance | Good | GPU nodes and model updates through rolling updates |
| OEE platform and building automation (e.g. HVAC analytics) | Good | Classic IT-style applications on OT data, including telemetry processing |
| SCADA server | Partly | Vendor support for containers is still limited |
| Soft PLC | Limited | Only with a real-time kernel and strict CPU pinning |
| Motion Control and Safety functions | Not suitable | Require certified, deterministic hardware |
In the energy and water sectors, Kubernetes mainly hosts central services for telemetry processing, load analytics and aggregating historian data from dispersed stations; control itself stays in the local RTUs and PLCs.
Kubernetes is also strong for OTAP pipelines, simulation, cyber ranges and digital twins: a complete test environment can be reproduced from a single manifest.
⚠️ Where are the limits for real-time and availability?
Kubernetes was designed for IT workloads. The scheduler, the overlay network and shared CPUs add latency and jitter, so deterministic behaviour and real-time response are not guaranteed.
- Recovery from node failure takes minutes - by default pods get a 300-second toleration for an unreachable node, so they are only started elsewhere after about five minutes. For high availability, run critical services with several replicas at once.
- Redundant control plane - etcd works with a quorum; three members survive the loss of one, five members the loss of two.
- Real-time tuning - the static CPU Manager reserves dedicated cores for a pod; since Linux 6.12 (late 2024) PREEMPT_RT is part of the mainline kernel, bringing virtual control closer.
- Network - network virtualisation through overlays costs performance; for fieldbus traffic, host networking or a second network interface is often used.
🔐 How do you secure Kubernetes in an OT environment?
Kubernetes enlarges the attack surface: the API server is a single central point from which an attacker can take over every workload. In March 2025 IngressNightmare (CVE-2025-1974, CVSS 9.8) was disclosed, a vulnerability in the ingress-nginx controller that allowed unauthenticated code execution and cluster takeover. The Kubernetes project has since retired ingress-nginx: after March 2026 it receives no more security updates, so migrate to the Gateway API or another supported ingress controller.
| Risk | Consequence | Measure |
|---|---|---|
| Exposed API server or dashboard | Full cluster takeover | Reachable only from the management network, MFA for administrators |
| Excessive permissions | Lateral movement | RBAC with least privilege per namespace |
| Privileged containers | Escape to the host | Pod Security Standard Restricted or Baseline |
| Malicious images | Supply chain attack | Private registry, signed images, vulnerability scanning |
| Flat pod network | Unhindered spread | NetworkPolicies and microsegmentation |
| Unnoticed changes | Late detection | API audit logging to security monitoring |
Key references are the Kubernetes Hardening Guidance from NSA and CISA (version 1.2, August 2022) and the CIS Kubernetes Benchmark, which you check with kube-bench. Place the cluster within the zones of IEC 62443 and NIST SP 800-82: an edge cluster that talks to PLCs does not belong in the same segment as a cluster with internet access. Traditional network segmentation with an industrial firewall remains necessary, and management follows your organisation’s ISO 27001 and NIST CSF processes and security policy. This is how you translate general hardening and cybersecurity to the container level.
🧭 How do you introduce Kubernetes into OT step by step?
- Start with non-critical data - begin with an MQTT broker, dashboards or a historian replica, not with control.
- Choose a suitable distribution - K3s or MicroK8s for a single edge site, a full cluster in the cloud or data centre for central analytics.
- Define everything as code - manifests in Git, rollout through GitOps, and a test cluster in the OTAP pipeline.
- Secure from day one - RBAC, Pod Security Admission, NetworkPolicies, encryption of Secrets and audit logging.
- Test failure scenarios - pull a node, measure how long services are down and record that in the availability design.
- Plan upgrades - at least one minor upgrade per year, always in the test environment first.
If your organisation falls under the Dutch Cyberbeveiligingswet (the NIS2 implementation), which entered into force on 15 August 2026, a production cluster is subject to the same duty of care for risk management, access control and patching as any other OT system.
❓ Frequently asked questions
What is the difference between Docker and Kubernetes?
Docker builds and runs containers on a single host, whereas Kubernetes distributes containers across a cluster of machines, monitors them and restarts them automatically. Since version 1.24 Kubernetes no longer supports Docker Engine directly as its runtime, but it still runs images built with Docker through containerd or CRI-O.
Can a PLC run on Kubernetes?
A soft PLC can run in a container on Kubernetes, but only with a real-time Linux kernel, dedicated CPU allocation and carefully tested network behaviour. Kubernetes is not suitable for motion control and safety functions; those stay on certified, deterministic hardware.
What is K3s?
K3s is a lightweight, CNCF-certified Kubernetes distribution from Rancher, now part of SUSE. K3s runs as a single binary and needs at least 2 CPU cores and 2 GB RAM for a server and 512 MB for an agent, which makes it suitable for industrial edge gateways.
How quickly does Kubernetes recover from a failure?
Kubernetes restarts a crashed container within seconds, but when a whole node fails it waits about five minutes by default before starting the pods elsewhere. Critical OT services on Kubernetes therefore run with several replicas spread across nodes.
Is Kubernetes secure enough for OT?
Kubernetes can be used securely in OT if you apply RBAC, Pod Security Standards, NetworkPolicies, signed images and audit logging and place the cluster in its own IEC 62443 zone. A default installation is not secure enough, because pods can reach each other freely by default.
Which Kubernetes version should I use?
Always use one of the three Kubernetes minor versions still supported, which in November 2026 are 1.35, 1.36 and 1.37. Each minor version receives about one year of patches, so plan at least one upgrade per year.
📌 In summary
Kubernetes orchestrates containers across a cluster and makes edge and data services in OT scalable, reproducible and self-healing. It is an excellent fit for MQTT, gateways, historians and analytics, but not for hard real-time control or safety. With a lightweight distribution, GitOps, strict hardening and a yearly upgrade cycle, Kubernetes becomes a reliable foundation for IT/OT convergence.