Deployment spaces

A deployment space is a registered Kubernetes cluster (or, for VM deploys, a Linux VM) on a connected cloud account. It is ZopDay’s unit of “where things run”: environments bind to spaces, and deployments ship through them. Anything ZopDay runs on a cluster or VM goes through a space.

Infrastructure, List view: the clusters and VMs your spaces point at, next to the datastores they connect to, with region, cost, and status.

Before you start

• A cloud account connected in Settings → Cloud Accounts. See Cloud permissions for what each capability needs.
• On AWS, cluster registration needs the account connected with ZopDay Provision access. WIF-Assume Role, IAM User (Static Keys) and Temporary Credentials accounts all qualify. See Cluster registration.
• A role that includes the space:* policies you need (space:view, space:create, space:update, space:delete). See Provisioning overview.

How it works

A space is not the cluster itself. It is ZopDay’s pointer to the cluster, plus the kubeauth permission to talk to it. ZopDay never stores a long-lived kubeconfig; it mints a short-lived one per operation (see Kubeauth).

How spaces get created

Both paths produce the same kind of space.

Space status

There is no timed probe. The Infrastructure board keeps each cluster and VM space’s status in step with the resources ZopDay discovers on your cloud account, using the PATCH /spaces/{id}/status route. Only users with space:update trigger these updates; a read-only viewer never does.

A new space has a 15-minute grace period after registration before it can be marked inactive. ZopDay also skips the check when a discovery read is incomplete, so a partial sync never deactivates spaces in bulk. A VM space reactivates as soon as it reappears in discovery. A cluster must also pass the live reachability check, because being present proves the cluster exists, not that ZopDay can reach it.

Status drives gating in the UI:

• Inactive spaces are gated. Flows that need the cluster show a clear message instead of a raw SDK error.
• Active deployments on an inactive space keep running. ZopDay can’t push new revisions until the space recovers.
• Queued revisions stop after their retries run out. Once the space recovers, redeploy the service to ship a fresh revision.

Multi-cluster organisations

Most ZopDay organisations end up with several spaces. Common layouts:

• Per-environment: one cluster per environment (prod, staging, dev). Highest isolation, highest cost.
• Per-region: one cluster per region for latency or compliance. Often paired with a global ingress in front.
• Per-team / per-product: one cluster per major team or product line. Useful when teams want full autonomy.
• Shared dev + dedicated prod: a single shared dev cluster and dedicated prod clusters per environment. A common way to cut cost.

ZopDay doesn’t enforce any of these. The space picker in the environment wizard accepts any registered space, whichever environments already point at it.

Synthetic vs real spaces

Some parts of the UI need a “space-shaped” object that isn’t a real cluster, such as topology grouping and picker placeholders. These synthetic entries are filtered out of the autoscaler picker, the event-readiness picker, and any scaling-aware UI, which operate only on real, scalable clusters.

Add a space

1. Connect the cloud account

   Connect the account that owns the cluster or VM in Settings → Cloud Accounts, with the permissions for the path you want. See Cloud permissions.

2. Register or provision

   To use a cluster you already run, open Infrastructure, select the discovered cluster, and click Enable (Cluster registration). On AWS EKS, first grant ZopDay access to the cluster: in Settings → Cloud Accounts, open the account’s menu, choose Manage Clusters, and click Register on the cluster row. To create one, go to Infrastructure → Provision and choose Kubernetes Cluster or Virtual Machine (Provisioning overview).

3. Confirm it on Infrastructure

   The new space appears on Infrastructure in the Graph and List views, and in the space picker when you create an environment.

Deregister a space

Deregistering a space (DELETE /spaces/{id}) removes ZopDay’s pointer to the cluster and also deregisters any child spaces under it. It leaves the cluster, its workloads, and ZopDay’s cluster access in place. The effects on dependent objects:

To reverse a deregistration, re-register the cluster. ZopDay matches the registration to the same underlying cluster by its cloud identity, never by name, and restores the original id. Environments, deployments, attached registries, and custom domains keyed on that space line up again without re-binding.

Reference

Anatomy of a space

Provider-specific config

The config JSON varies per provider because each cloud identifies clusters differently. These examples show the identifying fields; a space’s config can carry more, such as attached domains and registries.

{
  "clusterName": "prod-eks-1",
  "region": "us-east-1"
}

{
  "clusterName": "prod-gke-1",
  "region": "us-central1",
  "projectId": "my-project"
}

{
  "clusterName": "prod-aks-1",
  "region": "eastus",
  "resourceGroup": "rg-prod-eus"
}

You can’t edit these fields on an existing space, because they are the cluster’s identity rather than its config. To point at a different cluster, deregister and re-register.

Endpoints

Deployment catalogue operations (/spaces*):

GET    /spaces                List
POST   /spaces                Add; register an existing cluster
GET    /spaces/{id}           Get one
PATCH  /spaces/{id}/status    Update status (needs space:update)
DELETE /spaces/{id}           Soft-delete (deregister)

Cluster-side operations that need a kubeconfig live under /space-discovery/*:

GET   /space-discovery/{spaceID}/namespaces   List existing namespaces on the cluster
POST  /space-discovery/{spaceID}/namespaces   Create a new namespace

Troubleshooting

Next steps