Docker / Kubernetes / Cloud

← Back to overview

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 host networking 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

Unicast discovery + interface pinning is exactly the model containers and clouds want.

  • No multicast required, anywhere. ZERODDS_NO_MULTICAST=1 + ZERODDS_PEERS is 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. ZERODDS_INTERFACE=<ip> binds and announces one interface across all transports, so the “WiFi+Ethernet host in Docker fails to register” (rmw_fastrtps#786) failure is a one-variable fix.
  • Config is honoured, not ambient. Discovery configuration is explicit environment variables read at startup — there is no separate XML the runtime can silently ignore.
  • 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

← Zurück zur Übersicht

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

Unicast-Discovery + Interface-Pinning ist genau das Modell, das Container und Clouds wollen.

  • Kein Multicast nötig, nirgends. ZERODDS_NO_MULTICAST=1 + ZERODDS_PEERS ist 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. ZERODDS_INTERFACE=<ip> bindet und announct ein Interface über alle Transporte, sodass der „WiFi+Ethernet-Host in Docker scheitert bei Registrierung”-Fehler (rmw_fastrtps#786) ein Ein-Variablen-Fix ist.
  • Config wird befolgt, nicht ambient. Discovery-Konfiguration ist explizite Umgebungsvariablen, beim Start gelesen — es gibt kein separates XML, das die Runtime still ignorieren kann.
  • 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