Clusters

An Anycloud cluster is a reusable Kubernetes execution target for Jobs and Services. Create the cluster once, then pass --cluster <id-or-name> instead of VM placement flags when you submit a workload. The workload remains an Anycloud Job or Service and keeps its normal lifecycle.

How workloads use a cluster

Anycloud workload	Kubernetes resources	Behavior
Job	batch/v1 Job	Runs to completion
Service	apps/v1 Deployment and ClusterIP Service	Runs until upgrade or termination

Cluster-backed workloads share the cluster's fixed-capacity VMs. They do not provision one VM per deployment or create synthetic VM records, so VM counts and costs continue to represent real virtual machines.

Placement

Cluster hosting, capacity, and retained API state are selected independently:

Resource	Selected by
Hosted API and control plane	api serve --credentials
Cluster capacity VMs	cluster create --credentials
Hosted API state	api serve --checkpoint-storage-credentials

The hosted API and cluster capacity can use different supported providers. A single cluster's capacity remains within one provider and region.

Create a cluster

Cluster creation requires an active hosted API; local APIs do not support it.

For example, host the API and control plane on AWS:

anycloud api serve \
  --id team-api \
  --credentials aws-host \
  --vm-type t3.medium \
  --checkpoint-bucket team-api-state \
  --use

Save the capacity credential to the newly active hosted API, then create the cluster:

anycloud credentials new gcp-capacity --provider gcp

anycloud cluster create training \
  --credentials gcp-capacity \
  --region us-central1 \
  --vm-type e2-standard-2 \
  --min-vms 2 \
  --max-vms 2

anycloud cluster status training

The minimum and maximum must currently be equal. Creation stores durable intent first, then the hosted API brings up the control plane and capacity VMs.

Run workloads

anycloud job ghcr.io/acme/batch:latest \
  --cluster training \
  -- python batch.py

anycloud service ghcr.io/acme/api:latest \
  --cluster training \
  -- python -m myapp

Cluster-backed Jobs support status, logs, exec, termination, and resubmission through the normal deployment commands. Cluster-backed Services can be created, upgraded, inspected for their persisted lifecycle state, and terminated. They currently expose only a cluster-internal address: public Anycloud URLs, live Pod health in status, logs, exec, and checkpoint buckets are not yet supported for them.

See Jobs, Services, and the cluster reference for workload options and current constraints.

Delete a cluster

anycloud cluster delete training

Deletion is asynchronous and is rejected while a deployment still references the cluster.