ROS 2 / K8S LAB
Phase 1 · days 1–14

Define the reference path

Before anything is built, the lab needs one clear target: which versions it supports first, and what a passing test across two workers looks like. This phase picks that target and designs the test. It does not claim the test passes.

Proposal · planning targets, not promisesIssues #7, #14, #15

Why this phase comes first

A ROS 2 message has to leave one pod, cross the cluster network and arrive in another pod. Today only a much smaller step is checked: a talker and a listener exchanging a message inside one container.

Container tested

Inside one container

The Jazzy image builds in CI and passes a local talker and listener check. This is the only hop the repository checks today.

Not yet verified

Between two workers

No test shows a message crossing from one Kubernetes worker to another. That is what the reference path is designed to prove later.

Legacy

The original cluster

The Vagrant lab uses ROS 2 Foxy (end of life), Kubernetes 1.29 and Weave Net. It stays as a historical example.

One message, three hops

A message makes three hops: out of the talker pod, across the cluster network (the CNI), and into the listener pod. Press play to see how the four tasks of this phase build up that picture. The dashed path is a plan, not something that has run.

A planned path between two workers

Illustration · conceptual path
A planned path for one ROS 2 message between two Kubernetes workers A banner names the proposed first profile: ROS 2 Jazzy with Ubuntu 24.04, with the Kubernetes minor version still to be chosen. Below it, Worker 1 holds a talker pod and a separate stress-ng pod, and Worker 2 holds a listener pod and a separate stress-ng pod. Between the workers sits the cluster network, the CNI. A dashed line shows a message going from the talker through the network to the listener, labelled Not yet verified. At the bottom, a compatibility matrix lists two rows: one container is Container tested, and across workers is Not yet verified. Worker 1 Worker 2 talker pod stress-ng listener pod stress-ng CNInetwork Not yet verified Compatibility matrix One containerContainer tested Across workersNot yet verified
Step 1 of 4

The hollow marker is a conceptual message, not a measurement. The only hop the repository checks today is the one inside a single container.

What done looks like

This phase ends when the team agrees what a passing smoke test (a short check that the basics work) must show. These are draft exit conditions, taken from the release gates. The phase defines them, it does not meet them.

Draft exit conditions for the smoke test

  • The talker and listener start on their own, with no manual kubectl exec into a pod.
  • They run on different Kubernetes nodes.
  • A script checks that messages arrive, stops after a time limit, and exits with a truthful pass or fail code.
  • Every result, including failures, is written into the compatibility matrix with the versions used: ROS distro, Ubuntu, Kubernetes, container runtime, CNI and DDS.

What this phase will not claim

DDS (Data Distribution Service) is the messaging layer ROS 2 uses. The plan states that feature or performance claims must not rest on static YAML alone, and that a Docker build or lint pass does not replace an end-to-end ROS check.

Read the release gates

Issues in this phase

Status labels come from what the repository's files show, not from the state of the issue on GitHub.

  • #7

    Modern ROS 2 baseline

    Pinned Jazzy image and verified sample nodes, with legacy Foxy marked end of life. The image exists; the Kubernetes side of the profile is not chosen yet. Issue #7 ↗

    Container tested
  • #14

    Talker and listener across workers

    A repeatable command shows messages crossing nodes without kubectl exec, and ROS workloads are separated from stress workloads. Issue #14 ↗

    Not yet verified
  • #15

    Maintained CNI and explicit discovery

    Replace the archived Weave Net with a maintained plugin and set DDS discovery on purpose, then test discovery, restart and debugging across workers. Issue #15 ↗

    Planned