Kubernetes for Transit Operators: The Vehicle as a Data Center.

Kubernetes is the standard data centers use to run, update and monitor applications built from many containers. Kubernetes in the vehicle takes that operating model and applies it to the fleet: onboard applications such as passenger information, passenger counting and diagnostics run as Kubernetes workloads, deployed centrally from the Unwired Edge Cloud and monitored the same way across the board. It is aimed at transit operators with larger fleets and several onboard applications from different suppliers, in other words, anywhere updates, faults and re-tendering are still handled application by application. Large rail operators in Europe already run this model.

For a single onboard application, Kubernetes rarely tips the decision; Unwired Edge Compute Standard with OCI containers is often all it takes. The real question is what you will add over the next few years. A virtualization platform in the vehicle does more than get one application on board: every application you add after it shares the same rollout, the same monitoring and the same resilience, with no new hardware project. Start with Kubernetes and you build the platform once, then specify every future application as a standard Kubernetes workload, whoever supplies it. The payoff comes over the life of the contract, not with the first project.

Both are editions of the Unwired Edge Cloud edge computing platform. Unwired Edge Compute Standard runs individual OCI containers on every device in the portfolio, smaller vehicle routers included, and is the right fit for virtualizing a single onboard application. Unwired Edge Compute for Kubernetes orchestrates applications made up of several services, using the standard Kubernetes API, Helm charts and GitOps. It adds Persistent Volumes, failover between devices and observability down to the pod. For that, you need a powerful vehicle router or separate compute hardware running Unwired Edge Cloud OS. Both editions are enabled and rolled out through the same device management.

A multi-node Kubernetes cluster has to hold a quorum at all times, meaning it must be able to reach a majority of its nodes. On a train, you can’t count on that: cars are coupled and uncoupled, links between vehicles drop, individual devices fail. A cluster spanning the whole train would break down at exactly those moments. That is why Unwired Edge Compute for Kubernetes runs an independent single-node cluster in every vehicle. Each vehicle keeps running on its own, with or without a connection to other cars or to the cloud. Resilience comes from the onboard application itself and from failover between devices using a virtual service IP.

They keep running. The cluster in the vehicle doesn’t need a cloud connection to work; it only uses one to fetch new versions from the repository and to ship logs and metrics. When the connection drops, passenger information, passenger counting and diagnostics carry on locally, with their data on Persistent Volumes in the vehicle. Once the connection is back, the vehicle syncs to its desired state and the Unwired Edge Cloud shows its status in real time again. This behavior is designed for service with patchy coverage, and you can reproduce it in the lab.

NIS2, the Cyber Resilience Act and ISO 27001 all call for traceable versions across the entire lifecycle, prompt security updates and clean separation between systems. Kubernetes in the vehicle lays the groundwork: containers run isolated from the host system, and workloads follow Pod Security Standards as non-root with resource limits. The operating system and the Kubernetes service go through an SBOM and CVE check before every release. Every version you roll out is uniquely identified and logged, and the observability of the Unwired Edge Cloud supplies the version evidence auditors ask for. You meet these requirements with the same platform you already use to manage devices and network.

There are three approaches on the market. Some vehicle router vendors offer a container runtime on their own devices, usually for individual OCI containers managed device by device. System integrators add additional hardware for each onboard application, each with its own management software. The third approach is a platform that brings network, device management and application operations together in one place. The Unwired Edge Cloud is one of these: Unwired Edge Cloud OS runs vendor-agnostic on routers and compute hardware, supports OCI containers as well as full Kubernetes, and comes with observability and long-term updates built in. What to look for: standard APIs, central rollout, audit evidence.