Skip to main content

anycloud cluster

Manage durable Kubernetes placement targets whose cloud VM capacity is owned by Anycloud. Creation is available on hosted APIs; local APIs reject it before storing intent or creating cloud resources.

The active hosted API determines where the control plane runs. The --credentials option below selects cluster capacity only, so there is no separate --host-provider option. See Clusters for an end-to-end cross-provider example and how Jobs and Services use a cluster.

Create​

anycloud cluster create <name> \
  --credentials <name> \
  --region <region> \
  --vm-type <type> \
  --min-vms <count> \
  --max-vms <count>

The credential, region, and VM type are fixed for the cluster. The initial implementation supports on-demand AWS, Azure, and GCP VMs. --min-vms and --max-vms must be equal and at least one; both are persisted so autoscaling can later vary capacity within those bounds without replacing the cluster lifecycle.

Creation returns after durable intent is stored. Use status to follow control plane and VM convergence.

Inspect and delete​

anycloud cluster list
anycloud cluster status <id-or-name>
anycloud cluster delete <id-or-name>

status and delete accept either the cluster ID or its name, the same identifiers --cluster accepts when placing a workload.

Each command accepts --json. Status reports Anycloud lifecycle state and ready, starting, draining, and failed VM counts. It does not expose Kubernetes credentials, endpoints, Pods, or raw Node objects.

Deletion is durable and asynchronous. It is rejected while an active or cleanup-pending deployment references the cluster. Anycloud then drains and terminates the cluster-owned VMs, removes their isolated network and colocated control plane, and retains the cluster and VM history for accounting.

Place workloads​

anycloud job ghcr.io/acme/batch:latest --cluster <id-or-name>
anycloud service ghcr.io/acme/api:latest --cluster <id-or-name>

The target must be a Ready Kubernetes cluster with a durable runtime connection. Anycloud persists its ID on the deployment, so deploy, status, logs, exec, upgrade, termination, and cleanup continue to use that exact cluster after an API restart. There is no process-default Kubernetes fallback.

--cluster cannot be combined with workload-level compute placement such as --credentials, --region, --vm-type, --gpu-type, --spot, disk, or zone flags. Supported container and bucket options remain workload-level input. Kubernetes currently translates --gpus and --shm-size; --cpus and --memory fail at submission.

Bucket requests are checked against the Kubernetes runtime before the deployment is created. Kubernetes Jobs currently require explicit storage credentials capable of minting short-lived, bucket-scoped tokens. Cluster-native workload identity and CSI storage are not yet supported.