Skip to content
Stackship documentation Svenska

Stackship platformAdministrators

Clusters

How the platform reaches the Kubernetes clusters it deploys onto, what it stores about them, and what the Clusters list shows.

Clusters are the Kubernetes clusters the platform places resources on. Platform administrators register and manage them under Settings → Platform Settings, on the Clusters tab. A boundary is made available on a cluster by a projection — see Add a projection — and users choose one of their boundary's clusters when they create a resource.

The Clusters list

The list shows each cluster's Name, Region, Connectivity and Cluster ID, with a pencil to edit it and a bin to delete it. Names are unique across the platform. Seeing the list needs kernel/clusters/read at the platform root (Platform Owner, Platform Contributor); registering, editing and deleting need kernel/clusters/write, which only Platform Owner holds.

With the CLI:

bash
stsh cluster list
stsh cluster get prod-eu-west

Connectivity

Every cluster is reached one of two ways, chosen when it is registered.

Mode How it works
Direct The platform calls the cluster's Kubernetes API server. Either it is the cluster the platform runs in, which needs no address, or an external API server given by its URL and CA certificate.
Agent An agent inside the cluster dials out to the platform, and work is sent down that connection. Nothing dials the cluster, so it needs no API URL and no certificate.

Important

Agent clusters cannot be enrolled yet. The portal lets you register an Agent cluster and issues a join token, but the command it shows installs from a chart that is not published. Register clusters as Direct.

Credentials

Registering a cluster never asks for a kubeconfig, and the platform stores no credential for another cluster's API server.

  • Your own requests to a cluster are sent with your own sign-in token, so Kubernetes applies your permissions and its audit log records the action against you. The cluster's API server must therefore trust the platform's identity provider, https://auth.example.com. This holds for Direct and Agent clusters alike.
  • Work the platform does on its own behalf runs under its own service account in the cluster the platform runs in, and through the agent in an Agent cluster. It is refused against an external Direct cluster, which only a signed-in user's token reaches.
  • The CA certificate only verifies the API server's TLS certificate. It grants nothing.

Accepts inbound links (Crosslink hub eligible) marks a cluster as able to host a Crosslink hub, and requires an Inbound endpoint — the host:port other clusters dial to reach it, for example skupper.example.com:443.

The setting lives on the cluster rather than on a boundary because it states a fact about your network: that a path, and the firewall rules along it, exist between your sites. No boundary owner can know that and the platform cannot discover it, so only a Platform Owner sets it.

In a hub-and-spoke topology every other cluster dials out to the hub, so only the hub needs inbound rules — usually one cluster in a DMZ or cloud site, while on-premises sites stay closed to inbound traffic. A cluster is offered as a boundary's hub only when it accepts inbound links, has an inbound endpoint, and the boundary is projected onto it.

Agent states

For an Agent cluster the Connectivity column shows the agent's state; a Direct cluster shows Direct.

State Meaning
Connected The agent has checked in within the last three minutes.
Not connected An agent enrolled at some point and has not checked in for three minutes.
Never enrolled No agent has redeemed a join token for this cluster.
Revoked The agent's identity was taken away with Revoke agent.

An agent that has just disconnected still shows Connected for up to three minutes.

Pages in this section