ROS 2 Kubernetes architecture

Understand the layers of a local robotics infrastructure lab, from Ubuntu virtual machines and kubeadm to ROS 2 DDS discovery and monitoring, without confusing planned integrations with proven behavior.

VAGRANT CLUSTER / HISTORICALJAZZY IMAGE / SEPARATE

Three-node historical topology

The Vagrantfile defines a VirtualBox private network with one Kubernetes control-plane VM and two worker VMs. These are Kubernetes nodes rather than ROS 2 application nodes. The control plane initializes kubeadm and workers join using a generated command.

VM	Role	IP	vCPUs	RAM
`controlplane`	Control plane	192.168.56.10	14	18,240 MB
`worker1`	Worker	192.168.56.11	2	6,096 MB
`worker2`	Worker	192.168.56.12	2	6,096 MB

These numbers describe the checked-in Vagrant configuration. They are not minimum requirements for a future lightweight Kubernetes profile.

Topology: conceptual dependency chain

Developer workstation (VirtualBox / Vagrant)
  ├─ controlplane  192.168.56.10   → kubeadm / API
  ├─ worker1       192.168.56.11   → workloads
  └─ worker2       192.168.56.12   → workloads

Kubernetes ↔ networking/CNI ↔ application pods
                              ↳ ROS middleware / DDS discovery
Monitoring examples ↔ Prometheus / Grafana
Historical data      ↔ Python / Jupyter

Illustrates component relationships, not a verified active cluster.

ROS 2 messaging and DDS networking

ROS 2 applications exchange messages through a middleware implementation (RMW), often using DDS discovery and transport. Default multicast discovery is not guaranteed across Kubernetes CNI implementations. Discovery modes depend on your RMW and configuration; alternatives include an explicit Fast DDS Discovery Server.

The original lab installs historical Weave Net. A modern networking experiment should test pod-to-pod connectivity, DNS or advertised locator reachability, discovery mode, UDP transport, namespace isolation and restart behavior on distinct worker nodes. See the repository DDS troubleshooting guide and network modernization issue #15.

Jazzy image and legacy workload manifests

The modern Dockerfile uses ROS 2 Jazzy / Ubuntu 24.04 and demo nodes. The automated smoke script checks two processes in the same container. The historical root-level Kubernetes YAML uses stress-ng and does not auto-launch a cross-worker ROS 2 talker/listener.

A smoke test is not an integration test

No checked-in test in the current version proves message delivery across two different Kubernetes workers. Release gates for such a claim are tracked in #14.

Monitoring and experimentation

Monitoring scripts and configuration for Prometheus, Grafana, Metrics Server and the Kubernetes Dashboard exist as historical educational references. The separate DataAnalysis directory contains Python and Jupyter analysis over historical metrics; those plots are not measurements of a new modern cluster.

Study the source in MonitoringSystem and DataAnalysis. Security hardening, maintained UI replacements and credible end-to-end measurements remain tracked in the roadmap.

Evidence required for modern support claims

Pin and record supported ROS distribution, OS, Kubernetes, CNI, runtime and discovery configuration.
Verify a clean install on documented machine resources.
Place ROS talker and listener on different workers and record message receipt.
Test restarts and bounded failure cases with clear pass/fail output.
Require least-privilege access, no leaked tokens and reproducible raw data for performance claims.