Run several clusters on one network

A mesh network isn’t limited to one cluster. Put several clusters on the same network and every machine on it reaches all of them — each cluster keeps its own address space and its own DNS zone, so names never collide and traffic never crosses wires.

This is the runs-on relationship — a cluster’s own nodes live on the network — not an attachment, where a connector bridges a cluster in. Clusters that run on a network are native peers: no connector, no source-NAT, the real client address all the way to the pod. For the two relationships side by side, see Core concepts → Networking.

How several clusters stay untangled

When a cluster runs on a network, the platform does two things so many clusters coexist without planning:

• Carving. Each cluster gets its own pod and service ranges, picked to be unique across the region. Two clusters on one network can never overlap — you don’t allocate IPs, and nothing clashes.
• A DNS zone per cluster. Each cluster answers for ‹service›.‹namespace›.svc.‹cluster›.cluster.internal. The cluster name is baked into the name, so web.default.svc.alpha.cluster.internal and web.default.svc.beta.cluster.internal stay unambiguous on one network.

1. A network

Create a mesh network in the Console (Mesh → Networks) — call it fleet. The longbridge_mesh_network Terraform resource does the same.

2. Two clusters on it

Create each cluster with --network, naming that network. Joining an existing network exposes the cluster’s nodes to everything already on it, so it takes an explicit acknowledgment:

lbr cp cluster create alpha --tier small --mesh --network fleet --accept-shared-network
lbr cp cluster create beta  --tier small --mesh --network fleet --accept-shared-network

Each comes up with its own carved ranges and its own ‹cluster›.cluster.internal zone — nothing to configure. Attach a node to each so there’s somewhere to run pods: Join a node, or in a throwaway QEMU VM.

3. Something to reach

Run a workload in each cluster (against each one’s kubeconfig):

kubectl run web --image nginx --port 80
kubectl expose pod web --port 80 --name web

4. Put your machine on the network

The network’s Machines → Add machine prints a one-command join. Add --accept-routes to pick up the clusters’ ranges and --accept-dns to use their DNS zones:

tailscale up --login-server https://fleet.eu-hel.mesh.lngbrdg.com \
  --auth-key <key> --accept-routes --accept-dns

5. Reach every cluster by name

From your machine, curl each cluster’s service by its own name:

curl http://web.default.svc.alpha.cluster.internal/   # <title>Welcome to nginx!</title>
curl http://web.default.svc.beta.cluster.internal/    # the other cluster, same network

Both answer, each from its own cluster. The requests cross the mesh straight to the pods — no public endpoint, no load balancer — and the pods see your machine’s real mesh address as the source, not a proxy’s.

What sharing a network does — and doesn’t

Putting clusters on one network makes them reachable from the network: your laptops, CI runners, and other machines reach every cluster by name. It does not merge the clusters. Sharing a network doesn’t let a pod in one reach a pod in another — each cluster’s nodes carry only their own routes, so a workload stays inside its cluster unless you deliberately bridge them. That isolation is the default on purpose: a shared network is a place to reach your clusters from, not a flat space where every tenant dials into every other’s pods. Scope who reaches what with tags on the network’s Policy tab.

Clean up

Delete the clusters and the network when you’re done — the Console, lbr cp cluster delete, or the Terraform resources. Deleting a cluster deregisters its nodes and frees its carved ranges for the next one.