cluster

1ctl cluster lets you explore the Kubernetes clusters that Satusky manages and the geographic zones available for your deployments. Each zone corresponds to a separate Kubernetes cluster with its own control plane. You choose which zones to deploy to; Satusky handles everything else.

1ctl cluster zones
1ctl cluster list

These are read-only inspection commands. Clusters are managed infrastructure — you do not create or delete them. To route deployments to a specific cluster, use 1ctl deploy --zone.

Commands

`1ctl cluster zones`

1ctl cluster zones

Lists every geographic zone where Satusky has capacity, along with the availability status of the cluster in that zone. This is the source of truth for valid --zone values you can pass to 1ctl deploy.

Under the hood: GET /v1/cli/clusters/zones

Output columns

Column	Description
`Zone`	Zone identifier used in deploy commands (e.g. `my-kul-1b`)
`Region`	Human-readable region name
`Status`	`available` or `unavailable`

Example

$ 1ctl cluster zones
ZONE         REGION            STATUS
my-kul-1b   Kuala Lumpur      available
my-bki-1a   Borneo             available
my-kul-1a   Kuala Lumpur      unavailable

Zones marked unavailable have a cluster that is either under maintenance or has insufficient capacity. Deployments targeting an unavailable zone will be rejected at submission time.

`1ctl cluster list`

1ctl cluster list

Lists the clusters that are currently enabled for your active organization. Not every available zone may be enabled for every org — contact support to enable additional zones.

Under the hood: GET /v1/cli/clusters

Output columns

Column	Description
`Name`	Cluster name
`Zone`	Zone this cluster serves
`Status`	Cluster health: `healthy`, `degraded`, or `offline`
`Enabled`	Whether this cluster is enabled for your organization

Example

$ 1ctl cluster list
NAME            ZONE         STATUS    ENABLED
kul-1b-prod     my-kul-1b   healthy   yes
bki-1a-prod     my-bki-1a   healthy   yes
kul-1a-prod     my-kul-1a   degraded  no

Cluster health is derived from the aggregate health of the machines in that cluster. Status updates are broadcast in real time by MachineStatusHub.

Using clusters with deployments

Pass --zone to 1ctl deploy to target a specific cluster. The zone value must match one of the Zone entries from 1ctl cluster zones.

# Deploy to Kuala Lumpur
1ctl deploy --zone my-kul-1b

# Deploy across multiple zones simultaneously
1ctl deploy --multicluster --zone my-kul-1b

For multi-cluster deployments, Satusky coordinates across clusters via the services/multicluster package. Each cluster receives its own copy of the workload; the control plane keeps replica counts and image versions in sync.

If --zone is omitted, 1ctl deploy uses the zone recorded in satusky.toml for the current project, or falls back to the default zone for your organization.

How clusters work

Each cluster is an independent Kubernetes cluster with its own kubeconfig stored in the Satusky control plane. The central API server talks to each cluster using those kubeconfigs — you never need to manage kubeconfigs yourself.

1ctl deploy
   └─ Satusky API (api.satusky.com)
         ├─ kul-1b-prod  K8s API (my-kul-1b)
         └─ bki-1a-prod  K8s API (my-bki-1a)

Cluster health is tracked through the machines table: as individual nodes report in via the health check job, the cluster-level status rolls up automatically. If enough nodes in a zone report degraded or offline, the cluster status changes and MachineStatusHub broadcasts the update.

Multi-cluster deployments (--multicluster) are coordinated by services/multicluster. Each participating cluster gets an independent deployment; traffic routing across zones depends on your ingress and DNS configuration.