Docker / Kubernetes / Cloud
RC7 preparation: this page retains historical investigations and measurements, not approval of the current candidate. Runtime file contracts were checked against current source; historical interoperability, performance and platform claims were not remeasured by that review.
The pain
Containerized and cloud ROS 2 multiplies the discovery problem (19 reports): container network namespaces, overlay networks, and Kubernetes CNIs do not pass UDP multicast by default, so DDS discovery silently fails across pods/containers.
- Nodes in different containers cannot discover each other without
hostnetworking or a hand-built Discovery Server. - A simulator/container can ignore the DDS config it was given and remain unreachable.
- When a host has both WiFi and Ethernet, a containerized node fails to register because the wrong interface is announced.
- Getting multicast through Kubernetes (Cilium and friends) is its own project.
Most recent example
IsaacSim#407 — “Isaac Sim in Docker unreachable and ignores CycloneDDS config” (2026-01-09). A containerized Isaac Sim instance is unreachable over ROS 2 and does not honour the Cyclone DDS configuration it was handed — discovery-in-containers failing in exactly the way the cluster predicts.
Reference list (most recent)
| Date | Source | Problem |
|---|---|---|
| 2026-01-09 | IsaacSim#407 | Container unreachable, ignores DDS config |
| 2024-10-23 | rmw_fastrtps#786 | Docker host-net node fails to register with WiFi+Ethernet |
| 2024-03-27 | ROS Discourse | Making DDS multicast work under Cilium/Kubernetes |
| 2024-02-17 | create3 discussion #549 | Discovery Server config needed for ROS 2 in Docker |
| 2024-02-14 | ROS Discourse | Discovery Server gymnastics for Kubernetes |
How ZeroDDS solves it
Runtime settings below belong in the base file and sorted drop-ins, not environment overrides.
Unicast discovery + interface pinning is exactly the model containers and clouds want.
- No multicast required, anywhere.
discovery.no_multicast: true+transport.user_multicast: false+discovery.peersis unicast end-to-end, which is precisely what overlay networks and Kubernetes CNIs do pass. You address pods/containers by IP/service — no multicast for the CNI to drop, no Discovery Server pod to operate. - Interface pinning fixes the multi-interface registration failure.
transport.interface: <ip>selects an IP interface and advertised IP locators, so the “WiFi+Ethernet host in Docker fails to register” (rmw_fastrtps#786) failure is an explicit interface setting. - Config is honoured, not ambient. Discovery configuration is explicit layered files read through the fallible runtime startup path. Mount the base and its ordered drop-ins; malformed known settings prevent startup.
- TCP where overlays prefer it. A first-class TCP transport is available for networks that only forward TCP cleanly.
Why it no longer has to be a pain
Container/cloud pain is multicast through networks that don’t forward multicast. ZeroDDS’s default-capable unicast discovery plus interface pinning maps directly onto how container and cloud networking actually routes traffic — the deployment becomes “list the peer IPs”, not “operate a Discovery Server and fight the CNI.”
Reproduce it yourself
# Unicast, multicast-free discovery (the container/cloud model), cross-vendor:
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh→ Back to overview · Next: Security
Docker / Kubernetes / Cloud
RC7-Vorbereitung: Diese Seite enthält historische Untersuchungen und Messwerte, keine Freigabe des aktuellen Kandidaten. Die Runtime-Dateiverträge wurden mit dem aktuellen Quellstand abgeglichen; historische Interop-, Performance- und Plattformbehauptungen dadurch nicht erneut vermessen.
Der Schmerz
Containerisiertes und Cloud-ROS-2 vervielfacht das Discovery-Problem (19 Reports): Container-Network-Namespaces, Overlay-Netze und Kubernetes-CNIs lassen UDP-Multicast per Default nicht durch, sodass DDS-Discovery still über Pods/Container hinweg scheitert.
- Nodes in verschiedenen Containern können sich ohne
host-Networking oder einen hand-gebauten Discovery-Server nicht entdecken. - Ein Simulator/Container kann die ihm gegebene DDS-Config ignorieren und unerreichbar bleiben.
- Wenn ein Host sowohl WiFi als auch Ethernet hat, scheitert ein containerisierter Node bei der Registrierung, weil das falsche Interface announct wird.
- Multicast durch Kubernetes (Cilium und Freunde) zu bekommen ist ein eigenes Projekt.
Jüngstes Beispiel
IsaacSim#407 — „Isaac Sim in Docker unreachable and ignores CycloneDDS config” (2026-01-09). Eine containerisierte Isaac-Sim-Instanz ist über ROS 2 unerreichbar und befolgt die ihr gegebene Cyclone-DDS-Konfiguration nicht — Discovery-in-Containern, das genau so scheitert, wie der Cluster vorhersagt.
Referenzliste (jüngste zuerst)
| Datum | Quelle | Problem |
|---|---|---|
| 2026-01-09 | IsaacSim#407 | Container unerreichbar, ignoriert DDS-Config |
| 2024-10-23 | rmw_fastrtps#786 | Docker-Host-Net-Node scheitert bei Registrierung mit WiFi+Ethernet |
| 2024-03-27 | ROS Discourse | DDS-Multicast unter Cilium/Kubernetes zum Laufen bringen |
| 2024-02-17 | create3 discussion #549 | Discovery-Server-Config nötig für ROS 2 in Docker |
| 2024-02-14 | ROS Discourse | Discovery-Server-Turnübungen für Kubernetes |
Wie ZeroDDS es löst
Die folgenden Runtime-Werte gehören in Basisdatei und sortierte Ergänzungen, nicht in Umgebungs-Overrides.
Unicast-Discovery + Interface-Pinning ist genau das Modell, das Container und Clouds wollen.
- Kein Multicast nötig, nirgends.
discovery.no_multicast: true+transport.user_multicast: false+discovery.peersist Unicast end-to-end, was genau das ist, was Overlay-Netze und Kubernetes-CNIs durchlassen. Du adressierst Pods/Container per IP/Service — kein Multicast, das das CNI droppen könnte, kein Discovery-Server-Pod zu betreiben. - Interface-Pinning fixt den Multi-Interface-Registrierungs-Fehler.
transport.interface: <ip>wählt ein IP-Interface und angekündigte IP-Locators, sodass der „WiFi+Ethernet-Host in Docker scheitert bei Registrierung”-Fehler (rmw_fastrtps#786) eine explizite Interface-Einstellung ist. - Config wird befolgt, nicht ambient. Discovery-Konfiguration wird über Basisdatei und sortierte Fragmente geladen. Ungültige bekannte Werte verhindern den Start.
- TCP, wo Overlays es bevorzugen. Ein First-Class-TCP-Transport ist für Netze verfügbar, die nur TCP sauber forwarden.
Warum es kein Schmerz mehr sein muss
Container-/Cloud-Schmerz ist Multicast durch Netze, die Multicast nicht forwarden. Die default-fähige Unicast-Discovery von ZeroDDS plus Interface-Pinning bildet direkt darauf ab, wie Container- und Cloud-Networking Traffic tatsächlich routet — das Deployment wird „liste die Peer-IPs”, nicht „betreibe einen Discovery-Server und kämpfe mit dem CNI”.
Selbst reproduzieren
# Unicast, multicast-freie Discovery (das Container-/Cloud-Modell), cross-vendor:
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh→ Zurück zur Übersicht · Weiter: Security