Skip to main content

External Tenants

Most tenants run on platform-managed infrastructure: their edge nodes join the central cluster directly. An external tenant is different. It runs its own standalone cluster, on its own hardware, and connects back to the platform over an ArcNet tunnel — which, on a site whose network filters UDP, is itself carried over Flux. The tunnel is what the import model depends on; Flux is what makes it reachable.

This is the model for enterprise customers who will not put their production infrastructure under someone else's control plane, and it is what Ops calls external deployment mode.

ModelHow nodes joinTypical customer
ManagedNodes join the central cluster with an agent tokenStandard deployments
ExternalA standalone cluster connects over ArcNet and is importedEnterprises running their own infrastructure

From inside the tenant, the two look identical. Their users see their own nodes, their own metrics, shell access to their own hosts, and the same App Store. The distinction is invisible to them and matters only to whoever operates the platform.

Before you start​

  1. An ArcNet tunnel established between the external site and the platform gateway
  2. A running cluster at the external site, with a valid kubeconfig
  3. The cluster import completed, so the cluster is visible to the platform
  4. Connectivity verified through the tunnel, not just assumed

Step 4 is the one people skip. A cluster that imports successfully but cannot be reached over the tunnel will register and then sit in WaitCheckIn forever.

caution

Get the directory group to tenant mapping right before you point real users at the deployment. Tenant scope is enforced in the auth layer: a user can only see tenants they are bound to through their group claims, and hand-crafting a different tenant into a request returns 403 rather than data. That is the correct behavior, but it means a wrong mapping looks like a broken deployment. See SSO Integration.

Creating one​

From Global Command, use the tenant creation tool and supply:

  • Tenant ID, a lowercase slug
  • Display name, human-readable
  • Tenant type: customer, partner, or provider
  • Cluster mode: external

Then the external-cluster fields:

  • The cluster ID and name from the import
  • The ArcNet IP of the external cluster

The same thing can be done through the tenants API if you are onboarding in bulk.

Watching it​

Downstream Clusters in Global Command lists every connected cluster with its health, node count, mode, ArcNet address, and a link through to the cluster management view.

A cluster showing Disconnected is almost always a tunnel problem rather than a cluster problem. Check ArcNet status first; the cluster itself is usually fine and simply unreachable.

If the site's ArcNet tunnel is carried over Flux — which it is wherever the network filters UDP — then check Flux too. A dead Flux path takes ArcNet down with it at those sites, and the symptom presents as an ArcNet failure.

How deployment differs​

When a tenant is in external mode, App Store deployments are routed as bundles picked up by an agent on the customer's cluster, rather than installed directly. The practical consequences:

  • Deployments surface a Pending state while the agent syncs, which managed deployments skip
  • A deployment is only as healthy as its least healthy target cluster
  • Nothing is installed by pushing at the cluster; the cluster pulls

See Ops & Clusters for reading that status.

Next steps​