{"id":8716,"date":"2026-10-05T12:05:45","date_gmt":"2026-10-05T12:05:45","guid":{"rendered":"https:\/\/unwirednetworks.com\/?p=8716"},"modified":"2026-10-05T13:01:31","modified_gmt":"2026-10-05T13:01:31","slug":"kubernetes-on-the-vehicle-router","status":"publish","type":"post","link":"https:\/\/unwirednetworks.com\/en\/kubernetes-on-the-vehicle-router\/","title":{"rendered":"Kubernetes on the Vehicle Router."},"content":{"rendered":"\n

Your onboard application exists as a Helm chart, the pipeline is in place, your team knows Kubernetes. Only in the vehicle did that workflow stop short, at an additional compute box or at a rewrite of the application for the router. With Unwired Edge Compute for Kubernetes it now runs where it belongs: as a Kubernetes workload directly on the vehicle router.<\/p>\n\n\n\n

The Router Becomes the Platform for Your Applications.<\/h2>\n\n\n\n

Passenger information, automatic passenger counting, diagnostics and video analytics stopped being single programs long ago. They are systems made of several services with their own databases, interfaces and release cycles. The people who build them work with manifests, Helm charts and GitOps. In the vehicle, that state of the art had to stay outside: either every application got its own box in the equipment cabinet, or the software was taken apart and adapted for the router.<\/p>\n\n\n\n

\n\n
\n
<\/div>\n\n
\n <\/span><\/span><\/span><\/span><\/span>\n <\/div>\n
\n <\/span><\/span><\/span><\/span>\n <\/div>\n
<\/div>\n\n \n \n \n \n \n \n <\/svg>\n\n \n
\n \n \n <\/svg>\n PIS<\/span>\n <\/div>\n\n \n
\n \n \n <\/svg>\n APC<\/span>\n <\/div>\n\n \n
\n \n \n <\/svg>\n Diagnostics<\/span>\n <\/div>\n\n \n
\n \n \n <\/svg>\n More<\/span>\n <\/div>\n\n \n
\n \"\"\n <\/div>\n\n<\/div>\n<\/div>\n\n\n\n

Unwired Edge Compute for Kubernetes changes that. The vehicle router that already sits in the vehicle for WAN bonding<\/a>, passenger Wi-Fi<\/a> and the in-vehicle network now also runs a Kubernetes cluster with a standard API. Your application runs on it unchanged, with the standard Kubernetes API, with Helm and with the GitOps tool of your choice. For you, that means one piece of hardware less per vehicle, no special path for onboard software, and a deployment process that is the same from the data center to the train.<\/p>\n\n\n\n

What You Get with Unwired Edge Compute for Kubernetes.<\/h2>\n\n\n\n
\n
\n
<\/div>\n\n
\n <\/span><\/span>\n <\/div>\n
\n <\/span><\/span>\n <\/div>\n\n
<\/div>\n\n \n \n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \n\n \n \n \n \n \n \n <\/svg>\n\n \n
\n \"\"\n <\/div>\n\n \n
\n \"\"\n <\/div>\n\n \n
\n \n \n \n <\/svg>\n Unwired Edge Cloud OS\n <\/div>\n\n \n
\n \n \n \n <\/svg>\n GPIO\n <\/div>\n
\n \n \n <\/svg>\n GPS\n <\/div>\n
\n \n \n <\/svg>\n RS485\n <\/div>\n\n \n
\n \n \n <\/svg>\n USB\n <\/div>\n
\n \n \n \n <\/svg>\n VLAN\n <\/div>\n
\n \n \n <\/svg>\n SSD\n <\/div>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\n
<\/path><\/svg><\/div>\n
Standard Kubernetes per Vehicle<\/div>\n
Control plane, kubelet and containerd run as a package of the Unwired Edge Cloud OS directly on the router and start with the device.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Application Updates Without a Firmware Build<\/div>\n
Operating system and applications have separate lifecycles: a new release needs no firmware build and no maintenance appointment.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
GitOps All the Way into the Vehicle<\/div>\n
You set up ArgoCD, Flux or Open Cluster Management yourself using the included Helm deployer. From then on, every vehicle pulls its desired state from your repository. One repository, hundreds of vehicles, no technician on site.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Access to the Vehicle Network<\/div>\n
With advanced networking, pods attach directly to VLANs or bridges of the in-vehicle network; the host firewall remains in control.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Access to the Hardware<\/div>\n
GPIO, GPS, RS485, USB, audio and DisplayPort are available to your containers through the integrated hardware access.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Observability Down to the Pod<\/div>\n
Logs and metrics stream in real time to the Unwired Edge Cloud via OpenTelemetry, and from there via OTLP or Prometheus remote_write into your existing monitoring. The firmware also watches the state of the Kubernetes service from the outside, even when nothing inside the cluster is reporting anymore.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Persistent Storage<\/div>\n
Persistent Volumes live on a separate SSD or NVMe drive, apart from the operating system.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Failover Between Vehicles<\/div>\n
A sidecar container from Unwired manages a virtual service IP via VRRP across several routers; your application has a say through its health check.<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/path><\/svg><\/div>\n
Maintained Base Services<\/div>\n
Networking, storage, observability, hardware access and failover come from Unwired as optional base services: tested, checked for vulnerabilities and kept current along with their dependencies. You can replace any of them with your own components.<\/div>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n

One Cluster per Vehicle.<\/h2>\n\n\n\n

Every router runs its own single-node cluster. Multi-node clusters spanning several vehicles are deliberately not supported, and for good reason: a train is not an availability zone. Cars are coupled and uncoupled, links between vehicles break, devices fail one at a time. A cluster that had to hold a quorum across those boundaries would cause trouble exactly when you need it.<\/p>\n\n\n\n

That is why every cluster stays operational on its own, and high availability is built where it actually works in a vehicle: in the application itself and through the failover sidecar between devices. For your team, that means fewer edge cases in operation and behavior you can reproduce in the lab.<\/p>\n\n\n\n

\n
\n
<\/div>\n\n
\n <\/span><\/span>\n <\/div>\n
<\/div>\n\n \n
\n \"\"\n <\/div>\n\n \n \n \n \n \n <\/marker>\n <\/defs>\n \n \n \n \n \n \n <\/svg>\n\n \n
\n \"\"\n <\/div>\n
\n \"\"\n <\/div>\n
\n \"\"\n <\/div>\n\n \n
\n <\/span>MASTER<\/span>\n <\/span>BACKUP<\/span>\n <\/div>\n
\n <\/span>MASTER<\/span>\n <\/span>BACKUP<\/span>\n <\/div>\n
\n <\/span>MASTER<\/span>\n <\/span>BACKUP<\/span>\n <\/div>\n\n \n
\n \n \n <\/svg>\n Service-IP\n 10.0.0.10<\/span>\n <\/div>\n<\/div>\n<\/div>\n\n\n\n

Operations and Security from a Single Source.<\/h2>\n\n\n\n

The Kubernetes service is part of the device configuration and is activated and rolled out through the device management<\/a> of the Unwired Edge Cloud, just like modems, VLANs or WAN bonding. New Kubernetes versions arrive as package updates that Unwired releases regularly; before release, the operating system and the Kubernetes service go through automated tests, long-running tests on lab devices, and an SBOM and CVE check. You schedule operating system updates in rollout windows with limited concurrency, so the entire fleet never updates at the same time.<\/p>\n\n\n\n

\n\n
\n
<\/div>\n\n \n
\n <\/span><\/span>\n <\/div>\n
\n <\/span><\/span><\/span><\/span>\n <\/div>\n
<\/div>\n\n \n \n \n \n <\/svg>\n\n \n
\n
\n Helm Chart<\/span>\n \n \n \n \n <\/svg>\n main\n <\/span>\n <\/div>\n
\n
\n \n \n \n \n \n <\/svg>\n <\/span>\n
\n app<\/span>\n v2.3.1<\/span>\n <\/div>\n <\/div>\n\n
\n a3f9c1e<\/span>\n chore: bump image tag<\/span>\n <\/div>\n\n
\n \n <\/span>\n Commit pushed\n <\/span>\n \n <\/span>\n Syncing to fleet<\/span>\n <\/span>\n \n \n \n <\/svg>\n Deployed \u00b7 in sync\n <\/span>\n <\/div>\n <\/div>\n <\/div>\n\n \n
\n \n \n \n <\/svg>\n GitOps\n <\/div>\n\n \n
\n \"\"\n <\/div>\n\n \n
\n \"\"\n <\/div>\n<\/div>\n<\/div>\n\n\n\n

For tenders and audits, that counts twice. Containers run isolated from the host system, workloads follow Pod Security Standards as non-root with resource limits, and observability<\/a> provides the version evidence that CRA, NIS2 and ISO 27001 demand across the lifecycle. You meet those requirements with the same platform you use to manage devices and network.<\/p>\n\n\n\n

When the Standard Edition Is Enough.<\/h2>\n\n\n\n

Not every application needs Kubernetes. Unwired Edge Compute Standard runs lightweight OCI containers and is available across the entire device portfolio. For a single service with a clear job, such as an onboard portal or an interface integration, it is the right choice. The overview shows what a vehicle router does without Edge Compute, what the Standard edition adds, and what only comes with Kubernetes:<\/p>\n\n\n\n

\n\n
\n
<\/div>\n\n
\n <\/span><\/span><\/span><\/span><\/span>\n <\/div>\n
\n <\/span><\/span><\/span><\/span>\n <\/div>\n
<\/div>\n\n
\n\n
\n
\n \n \n <\/svg>\n CRA Ready\n <\/div>\n
\n \"\"\n
<\/div>\n <\/div>\n <\/div>\n\n
\n
\n \n \n <\/svg>\n Analytics & Logs\n <\/div>\n
\n \"\"\n
<\/div>\n <\/div>\n <\/div>\n\n
\n
\n \n \n <\/svg>\n NIS 2 Ready\n <\/div>\n
\n \"\"\n
<\/div>\n <\/div>\n <\/div>\n\n <\/div>\n<\/div>\n<\/div>\n\n\n\n
<\/th>Without Edge Compute<\/th>Standard<\/th>Kubernetes<\/th><\/tr><\/thead>
Device management, WAN bonding, passenger Wi-Fi from the Unwired Edge Cloud<\/td>\u2713<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Observability for router and network<\/td>\u2713<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Applications run on the vehicle router instead of on separate hardware<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
OCI containers, isolated from the host system<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Application updates without a firmware build<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Activation and rollout from the Unwired Edge Cloud<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Access to VLANs of the in-vehicle network<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Access to physical interfaces (CAN, RS485, GPIO, GPS, USB)<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Persistent storage on internal SSD<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Runs across the entire device portfolio, from 1 CPU core and 256 MB RAM<\/td>\u2713<\/span><\/td>\u2713<\/span><\/td>\u2717<\/span><\/td><\/tr>
Standard Kubernetes API, Helm charts, CRDs<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
GitOps deployment with ArgoCD, Flux or Open Cluster Management<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Orchestration of multiple services (Deployments, StatefulSets)<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Advanced networking, multiple network interfaces per pod<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Persistent Volumes for Kubernetes workloads on SSD or NVMe<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Failover between vehicles with a virtual service IP<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Pod Security Standards, resource limits, probes<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Container logs and metrics in real time to the Unwired Edge Cloud and on to your own monitoring systems<\/td>\u2717<\/span><\/td>\u2713<\/span><\/td>\u2713<\/span><\/td><\/tr>
Base services for networking, storage, observability, hardware access and failover, maintained by Unwired<\/td>\u2717<\/span><\/td>\u2717<\/span><\/td>\u2713<\/span><\/td><\/tr>
Minimum requirements<\/td>none<\/td>1 core, 256 MB RAM<\/td>2 cores, 1 GB RAM, SSD or NVMe<\/td><\/tr><\/tbody><\/table>
Without Edge Compute = vehicle router for network and Wi-Fi, applications on separate hardware. Standard = Unwired Edge Compute Standard (lightweight OCI containers). Kubernetes = Unwired Edge Compute for Kubernetes (single-node cluster per vehicle).<\/figcaption><\/figure>\n\n\n\n

Unwired Edge Compute for Kubernetes pays off as soon as an application consists of several services, comes as a Helm chart, or your team already works with GitOps. It requires an x64 or arm64 router with SSD or NVMe; large rail routers and onboard servers have that on board. For such devices, Unwired recommends the Kubernetes edition for all new projects.<\/p>\n\n\n\n

Conclusion.<\/h2>\n\n\n\n

Kubernetes on the vehicle router means your onboard application rides into the train with the same toolbox it was built with. No additional box, no firmware build for a software update, no technician at the vehicle for a release. How both editions fit into the edge computing platform of the Unwired Edge Cloud is covered on our page on edge computing with a container runtime on vehicle routers<\/a>. Whether your application runs on your routers is something we can settle fastest together: start a demo<\/a> or get in touch<\/a>.<\/p>\n\n\n\n

\n

FAQ<\/h2>\n\n\n\n
\n
\n