Crosslink
How Crosslink makes a service in one of a boundary's clusters reachable from its other clusters under the same name, and what the Crosslink tab reports.
A boundary can span several clusters, but a service's in-cluster name,
<service>.<namespace>.svc.cluster.local, normally only works on the cluster it runs on.
Crosslink connects the boundary's clusters so that an exposed service answers to the same name
on every one of them, and an application needs no configuration change to call across a cluster
edge. It is off until someone turns it on, and nothing is installed in any cluster before that.
Hub and spokes
Turning Crosslink on means choosing a hub: one of the boundary's clusters that accepts inbound connections. Every other cluster of the boundary is a spoke and dials out to the hub, so only the hub needs to be reachable from the others. The hub must be a cluster the boundary is projected into, and a platform administrator must have marked that cluster as accepting inbound links, because doing so asserts that the network path and firewall rules exist — see Clusters.
Sites and links
In every cluster of the boundary the operator sets up a site and reports its state. The Topology card on the Crosslink tab shows the hub and each spoke with its status in words:
| Site status | Meaning |
|---|---|
| Provisioning | The site is being set up and is not ready yet. |
| Active | The site is ready and carries traffic. |
| Degraded | The site is up but impaired, typically because its link dropped. The reason is shown with it. |
| Failed | The site could not be set up, or has failed. |
| Unknown | The operator has not reported on this cluster yet. This is not the same as healthy. |
Each spoke also shows its link to the hub:
| Link status | Meaning |
|---|---|
| Connecting | The spoke is dialling the hub, retrying with a delay. |
| Connected | The link is up. |
| Disconnected | The link was up and has dropped. |
Right after Crosslink is turned on, the tab shows that it is waiting for the operator until the first sites report.
Exposures
Crosslink only carries services that opt in. For each one, the Exposures card shows an Export row in the cluster where the service runs and an Import row in every other cluster, where a stand-in service with the same name in the same namespace forwards to it. Each row shows the namespace, cluster and port. A row marked Name taken means the other cluster already has a service with that name in that namespace, so the import did not happen there.
There is nothing to add or remove on the tab: exposure is decided by the service itself. Today a
service opts in when it carries the label platform.stackship.se/crosslink: "true"; the resource
pages and the CLI have no setting for it yet. Only TCP is carried, a port whose target port is
given by name is left out, and the service must select its pods.
The boundary CA
Traffic between sites is secured with the boundary's own certificate authority. The Boundary CA card shows its fingerprint, generation and expiry. It warns when fewer than 14 days remain and turns critical once the CA has expired. The platform rotates the CA by itself 90 days after the current generation was issued, and Rotate requests one right away; while sites are still moving to the new generation the card says that a rotation is in progress.
What it does not change
Crosslink joins the clusters of one boundary. It never connects two boundaries, and the network rules inside each cluster still apply — see Network isolation.
To turn it on, change the hub or turn it off, see Turn Crosslink on and manage it.