Ihre Bord-Anwendung liegt als Helm-Chart vor, die Pipeline steht, das Team kennt Kubernetes. Nur im Fahrzeug endete dieser Workflow bisher an einer zusätzlichen Rechnerbox oder an einem Umbau der Anwendung für den Router. Mit Unwired Edge Compute for Kubernetes läuft sie jetzt dort, wo sie hingehört: als Kubernetes-Workload direkt auf dem Fahrzeugrouter.
Der Router wird zur Plattform für Ihre Anwendungen.
Fahrgastinformation, automatische Fahrgastzählung, Diagnose oder Videoanalyse sind längst keine Einzelprogramme mehr, sondern Systeme aus mehreren Services mit eigenen Datenbanken, Schnittstellen und Release-Zyklen. Wer sie entwickelt, arbeitet mit Manifesten, Helm-Charts und GitOps. Im Fahrzeug musste dieser Stand der Technik bisher draußen bleiben: Entweder kam pro Anwendung eine eigene Box in den Schaltschrank, oder die Software wurde für den Router zerlegt und angepasst.
Unwired Edge Compute for Kubernetes ändert das. Der Fahrzeugrouter, der ohnehin für WAN-Bonding, Passagier-WLAN und das Bordnetz im Fahrzeug sitzt, betreibt zusätzlich einen Kubernetes-Cluster mit Standard-API. Ihre Anwendung läuft darauf unverändert, mit der Standard-Kubernetes-API, mit Helm und mit dem GitOps-Werkzeug Ihrer Wahl. Für Sie heißt das: eine Hardware weniger pro Fahrzeug, kein Sonderweg für die Bordsoftware, und ein Deployment-Prozess, der vom Rechenzentrum bis in den Zug derselbe ist.
Was Sie mit Unwired Edge Compute for Kubernetes bekommen.
Ein Cluster pro Fahrzeug.
Jeder Router betreibt einen eigenen Single-Node-Cluster. Multi-Node-Cluster über mehrere Fahrzeuge hinweg sind bewusst nicht vorgesehen, und das aus gutem Grund: Ein Zug ist keine Verfügbarkeitszone. Wagen werden gekuppelt und getrennt, Verbindungen zwischen Fahrzeugen reißen ab, Geräte fallen einzeln aus. Ein Cluster, der über solche Grenzen hinweg ein Quorum halten müsste, würde genau dann Probleme machen, wenn Sie ihn brauchen.
Deshalb bleibt jeder Cluster für sich lauffähig, und Hochverfügbarkeit entsteht dort, wo sie im Fahrzeug funktioniert: in der Anwendung selbst und über den Failover-Sidecar zwischen Geräten. Für Ihr Team bedeutet das weniger Sonderfälle im Betrieb und ein Verhalten, das Sie im Labor nachstellen können.
Betrieb und Sicherheit aus einer Hand.
Der Kubernetes-Dienst ist Teil der Gerätekonfiguration und wird über das Gerätemanagement der Unwired Edge Cloud aktiviert und ausgerollt, genauso wie Modems, VLANs oder WAN-Bonding. Neue Kubernetes-Versionen kommen als Paket-Updates, die Unwired regelmäßig freigibt; Betriebssystem und Kubernetes-Dienst durchlaufen vorher automatisierte Tests, Dauertests auf Laborgeräten und eine SBOM- und CVE-Prüfung. Betriebssystem-Updates planen Sie über Rollout-Fenster, mit begrenzter Parallelität, damit nie die ganze Flotte gleichzeitig aktualisiert.
Für Ausschreibungen und Audits zählt das doppelt. Container laufen isoliert vom Hostsystem, Workloads nach Pod-Security-Standards als Non-Root mit Ressourcenlimits, und die Observability liefert die Versionsnachweise, die CRA, NIS-2 und ISO 27001 über den Lebenszyklus verlangen. Sie erfüllen diese Anforderungen mit derselben Plattform, mit der Sie auch Geräte und Netz verwalten.
Wann die Standard-Edition reicht.
Nicht jede Anwendung braucht Kubernetes. Unwired Edge Compute Standard betreibt leichtgewichtige OCI-Container und ist im gesamten Geräteportfolio verfügbar. Für einen einzelnen Dienst mit klarer Aufgabe, etwa ein Onboard-Portal oder eine Schnittstellen-Anbindung, ist das die richtige Wahl. Die Übersicht zeigt, was ein Fahrzeugrouter ohne Edge Compute leistet, was die Standard-Edition hinzufügt und was erst mit Kubernetes dazukommt:
| Ohne Edge Compute | Standard | Kubernetes | |
|---|---|---|---|
| Gerätemanagement, WAN-Bonding, Passagier-WLAN aus der Unwired Edge Cloud | ✓ | ✓ | ✓ |
| Observability für Router und Netz | ✓ | ✓ | ✓ |
| Anwendungen laufen auf dem Fahrzeugrouter statt auf eigener Hardware | ✗ | ✓ | ✓ |
| OCI-Container, isoliert vom Hostsystem | ✗ | ✓ | ✓ |
| Anwendungs-Updates ohne Firmware-Build | ✗ | ✓ | ✓ |
| Aktivierung und Rollout aus der Unwired Edge Cloud | ✗ | ✓ | ✓ |
| Zugriff auf VLANs des Bordnetzes | ✗ | ✓ | ✓ |
| Zugriff auf physische Schnittstellen (CAN, RS485, GPIO, GPS, USB) | ✗ | ✓ | ✓ |
| Persistenter Speicher auf interner SSD | ✗ | ✓ | ✓ |
| Läuft im gesamten Geräteportfolio, ab 1 CPU-Kern und 256 MB RAM | ✓ | ✓ | ✗ |
| Standard-Kubernetes-API, Helm-Charts, CRDs | ✗ | ✗ | ✓ |
| GitOps-Deployment mit ArgoCD, Flux oder Open Cluster Management | ✗ | ✗ | ✓ |
| Orchestrierung mehrerer Services (Deployments, StatefulSets) | ✗ | ✗ | ✓ |
| Erweiterte Netzwerkfunktionen, mehrere Netzwerk-Interfaces pro Pod | ✗ | ✗ | ✓ |
| Persistent Volumes für Kubernetes-Workloads auf SSD oder NVMe | ✗ | ✗ | ✓ |
| Failover zwischen Fahrzeugen mit virtueller Service-IP | ✗ | ✗ | ✓ |
| Pod-Security-Standards, Ressourcenlimits, Probes | ✗ | ✗ | ✓ |
| Logs und Metriken der Container in Echtzeit an die Unwired Edge Cloud und weiter an eigene Monitoring-Systeme | ✗ | ✓ | ✓ |
| Von Unwired gepflegte Basisdienste für Netzwerk, Speicher, Observability, Hardware-Zugriff und Failover | ✗ | ✗ | ✓ |
| Mindestausstattung | keine | 1 Kern, 256 MB RAM | 2 Kerne, 1 GB RAM, SSD oder NVMe |
Unwired Edge Compute for Kubernetes lohnt sich also, sobald eine Anwendung aus mehreren Services besteht, als Helm-Chart vorliegt oder Ihr Team ohnehin mit GitOps arbeitet. Voraussetzung ist ein x64- oder arm64-Router mit SSD oder NVMe; große Bahnrouter und Bordserver bringen das mit. Für solche Geräte empfiehlt Unwired in neuen Projekten grundsätzlich die Kubernetes-Edition.
Fazit.
Kubernetes auf dem Fahrzeugrouter heißt: Ihre Bord-Anwendung fährt mit demselben Werkzeugkasten in den Zug, mit dem sie entwickelt wurde. Keine zusätzliche Box, kein Firmware-Build für ein Software-Update, kein Techniker am Fahrzeug für ein Release. Wie sich beide Editionen in die Edge-Computing-Plattform der Unwired Edge Cloud einfügen, zeigt die Seite Edge Computing mit Container-Runtime auf Fahrzeugroutern. Ob Ihre Anwendung auf Ihren Routern läuft, klären wir am schnellsten gemeinsam: Demo starten oder Kontakt aufnehmen.
FAQ
Ja, wenn der Router genug Ressourcen hat und das Betriebssystem einen Kubernetes-Dienst mitbringt. Ein Fahrzeugrouter ist ein industrielles Linux-Gerät mit Modems, Ethernet und WLAN; auf leistungsfähigen Modellen mit zwei oder mehr CPU-Kernen, mindestens 1 GB RAM und SSD lässt sich ein Single-Node-Kubernetes-Cluster betreiben, der Bord-Anwendungen als Pods ausführt. Unwired Edge Compute for Kubernetes liefert diesen Dienst als Paket des Unwired Edge Cloud OS, aktiviert über das Gerätemanagement der Unwired Edge Cloud. Die Anwendungen werden mit Standard-Kubernetes-Manifesten oder Helm-Charts beschrieben und per GitOps ausgerollt.
Weil viele Bord-Anwendungen dort laufen müssen, wo die Daten und die Hardware sind. Fahrgastinformation, Fahrgastzählung, Videoanalyse oder Diagnose brauchen Zugriff auf Kameras, Sensoren, GPS, serielle Schnittstellen und das Bordnetz, und sie müssen weiterarbeiten, wenn der Zug oder Bus keine Verbindung hat. Unwired Edge Compute for Kubernetes bringt den Deployment-Standard aus dem Rechenzentrum an diesen Ort: dieselben Manifeste, Helm-Charts und GitOps-Werkzeuge, nur auf dem Router statt auf einem Server. Die Cloud bleibt für Gerätemanagement, Observability und die Verteilung neuer Versionen zuständig, nicht für den Betrieb der Pods.
Ein vollwertiges Kubernetes in Single-Node-Ausführung. Auf dem Router laufen Control Plane mit eingebettetem etcd, kubelet und containerd als Container-Runtime; die Standard-Kubernetes-API steht zur Verfügung, ebenso Deployments, StatefulSets, ConfigMaps, Secrets und CRDs. Was fehlt, ist die Verteilung eines Clusters über mehrere Knoten. Bei Unwired Edge Compute for Kubernetes übernimmt der Unwired Kubernetes Service (unwired-ks) diese Rolle; Helm, ArgoCD, Flux und Open Cluster Management funktionieren wie auf jedem anderen Cluster.
Weil ein Zug keine Verfügbarkeitszone ist. Multi-Node-Kubernetes setzt stabile Verbindungen zwischen den Knoten voraus, um ein Quorum zu halten; im Fahrzeug werden Wagen gekuppelt und getrennt, Verbindungen zwischen Fahrzeugen reißen ab und Geräte fallen einzeln aus. Ein Cluster, der über solche Grenzen hinweg abstimmen müsste, wäre genau dann instabil, wenn er gebraucht wird. Unwired Edge Compute for Kubernetes betreibt deshalb bewusst einen eigenständigen Cluster pro Router. Hochverfügbarkeit entsteht auf Anwendungsebene oder über einen Failover-Sidecar, der eine virtuelle Service-IP per VRRP zwischen mehreren Routern verwaltet.
Der Cluster läuft weiter, weil Control Plane und Workloads lokal auf dem Router liegen und die Kubernetes-API auf dem Gerät erreichbar ist. Die Verbindung zur Cloud wird für Gerätemanagement, die Weiterleitung von Logs und Metriken und für den Abgleich mit dem GitOps-Repository gebraucht, nicht für den Betrieb der Pods. Ein Pull-basiertes GitOps-Werkzeug wie ArgoCD oder Flux holt sich den Sollzustand, sobald wieder eine Verbindung besteht. Bei Unwired Edge Compute for Kubernetes wird der Zustand des Kubernetes-Dienstes zusätzlich von der Firmware erfasst, sodass die Unwired Edge Cloud auch dann meldet, ob Dienst und Node laufen, wenn im Cluster selbst nichts mehr ankommt.
Ein x64- oder arm64-Gerät mit mindestens zwei CPU-Kernen, 1 GB RAM und persistentem Speicher wie SSD oder NVMe. Bei Unwired Edge Compute for Kubernetes belegt das Basissystem etwa 0,3 CPU-Kerne und 500 MB RAM, der Rest steht den Anwendungen zur Verfügung; für den Speicher sind mindestens 4 GB zuzüglich Container-Images und Daten einzuplanen. Große Bahnrouter und Bordserver bringen diese Reserven mit. Kleinere Router mit einem CPU-Kern und 256 MB RAM betreiben Container mit Unwired Edge Compute Standard. Welche Geräte unterstützt werden, zeigt die Liste der unterstützten Hardware.
Anwendungen aus mehreren Services, die als Helm-Chart vorliegen oder per GitOps ausgerollt werden sollen: Fahrgastinformationssysteme mit Datenbank und Schnittstellen, automatische Fahrgastzählung mit Auswertung, Videoanalyse, Diagnose- und Telemetrie-Stacks. Ein einzelner Dienst mit klarer Aufgabe, etwa ein Onboard-Portal für das Passagier-WLAN, ein VPN oder eine Schnittstellen-Anbindung, braucht kein Kubernetes; dafür reichen leichtgewichtige OCI-Container, bei Unwired die Edition Edge Compute Standard. Für leistungsfähige Geräte empfiehlt Unwired in neuen Projekten grundsätzlich Unwired Edge Compute for Kubernetes.
Getrennt voneinander. Anwendungen kommen per GitOps: Ein neuer Commit im Repository, und jedes Fahrzeug zieht die neue Version, ohne Firmware-Build und ohne Wartungstermin am Fahrzeug. Der Kubernetes-Dienst selbst ist bei Unwired Edge Compute for Kubernetes ein Paket des Unwired Edge Cloud OS; neue Versionen kommen als Paket-Updates, die Unwired regelmäßig freigibt und vorher mit automatisierten Tests, Dauertests auf Laborgeräten sowie einer SBOM- und CVE-Prüfung absichert. Betriebssystem-Updates werden über Rollout-Fenster geplant und mit begrenzter Parallelität ausgerollt, damit nie die ganze Flotte gleichzeitig aktualisiert.
Über zusätzliche Netzwerk-Interfaces und Gerätezuordnungen, die Kubernetes von Haus aus nicht kennt. Bei Unwired Edge Compute for Kubernetes hängt das Standard-Pod-Netzwerk an einer Bridge im Host-Netz des Routers; über erweiterte Netzwerkfunktionen erhalten Pods weitere Interfaces und werden direkt an VLANs oder Bridges des Bordnetzes angebunden, etwa an das Fahrgastnetz oder das Betriebsnetz. Der integrierte Hardware-Zugriff reicht GPIO, GPS, RS485, USB, Audio und DisplayPort in Pods durch. Beides sind optionale Basisdienste, die Unwired testet und pflegt. WAN-Bonding, VLANs und Firewall bleiben im Gerätemanagement der Unwired Edge Cloud.
Es liefert die Bausteine, die diese Regelwerke über den Lebenszyklus verlangen: isolierte Workloads, nachvollziehbare Versionen und regelmäßige Sicherheits-Updates. Container laufen getrennt vom Hostsystem, Workloads nach Pod-Security-Standards als Non-Root mit Ressourcenlimits, und jede Version ist als Manifest oder Helm-Chart im Repository dokumentiert. Bei Unwired Edge Compute for Kubernetes kommen die SBOM- und CVE-Prüfung des Betriebssystems und des Kubernetes-Dienstes hinzu sowie die Observability der Unwired Edge Cloud, die Versionsstände und Zustände zentral erfasst. Die Nachweispflicht bleibt beim Betreiber, die Datenbasis dafür liefert die Plattform.
