blueprint · described

Several regions through a transit cluster

Clusters in several regions, joined through a transit cluster. This is where the fabric is going, set out so you can see the shape. None of it runs today.

Not operating yet

Clusters do not connect to each other. Gateways peer only within their own cluster, and a cluster’s role is recorded without changing its behaviour. This page describes a proposed model. It is not a design we have committed to, and not something you can build today.

The proposed shape

Hub and spoke. One transit cluster is the hub. Each region that holds workloads has a local cluster, and each local cluster reaches the others through the transit cluster rather than directly. The role names already on a cluster — transit and local — are the vocabulary for this model, which is why they exist before the behaviour does.

Local clusters serve the workload networks in their own region, exactly as the single-cluster blueprint does.
The transit cluster carries traffic between local clusters.
Policy would still name hosts, and a flow between regions would be enforced by the same rules as a flow within one.

What has to exist first

A way for a cluster’s gateways to learn about gateways in another cluster. Today the peer set is built from one cluster’s gateways and nothing else.
A cluster role that changes behaviour. Today it is stored and nothing reads it.
Everything the single-cluster blueprint is waiting on, in each region.

routing…