ankra-cloud-clusters

name

ankra-cloud-clusters

description

Provision and manage Ankra-managed Kubernetes clusters (K3s or kubeadm) on Hetzner Cloud, OVHcloud, UpCloud, and DigitalOcean - creating clusters, storing provider credentials, and managing node groups, scaling, Kubernetes versions, and upgrades. Use when the user wants to create or provision a new Kubernetes cluster (rather than import an existing one), or mentions Hetzner, OVH, UpCloud, or DigitalOcean clusters.

Ankra Cloud Clusters

Besides importing existing clusters, Ankra can provision managed Kubernetes clusters on Hetzner Cloud, OVHcloud, UpCloud, and DigitalOcean - K3s by default, or vanilla upstream Kubernetes via kubeadm. This skill covers the provision-and-manage lifecycle. Provider subcommands share a common shape: ankra cluster hetzner|ovh|upcloud|digitalocean <verb>.

1. Store provider credentials

Provider credentials (and SSH keys) are scoped credentials held by Ankra. Create them first and note the returned credential ID - the create commands take the ID, not the name.

ankra credentials hetzner create --name hetzner-prod
ankra credentials hetzner ssh-key create --name ops-key      # SSH key credential
ankra credentials ovh create --name ovh-prod
ankra credentials upcloud create --name upcloud-prod
ankra credentials digitalocean create --name do-prod         # alias: ankra creds do
ankra credentials list                                       # find the IDs to pass below
ankra credentials get <name>                                 # resolve a name to its ID

DigitalOcean personal access tokens are prefixed with dop_v1_.

2. Create a cluster (per provider)

create provisions a brand-new cloud cluster. It submits asynchronously by default; add --wait (bounded by --timeout, default 10m) to block and print the agent install command on first import.

ankra cluster ovh regions --credential-id <id>               # pick a region the project can deploy in
ankra cluster ovh create \
  --name prod \
  --credential-id <ovh_cred_id> \
  --region GRA9 \
  --ssh-key-credential-ids <id>,<id> \
  --wait

Hetzner/UpCloud/DigitalOcean create take equivalent flags (--name, --credential-id, location/region, control-plane and worker sizes/counts, --ssh-key-credential-id[s], optional --kubernetes-version). Run ankra cluster <provider> create --help for the provider-specific server-type/location flags.

DigitalOcean discovery before create:

ankra cluster digitalocean regions --credential-id <id>
ankra cluster digitalocean sizes --credential-id <id> --region nyc3 --available-only
ankra cluster digitalocean create \
  --name prod \
  --credential-id <do_cred_id> \
  --ssh-key-credential-id <ssh_key_id> \
  --region nyc3 \
  --control-plane-size s-2vcpu-4gb \
  --worker-size s-2vcpu-4gb \
  --wait

Distribution: K3s (default) or kubeadm

--distribution kubeadm provisions vanilla upstream Kubernetes (containerd, pinned pkgs.k8s.io packages, Cilium CNI) instead of K3s. kubeadm-only extras:

ankra cluster kubeadm-versions                               # supported upstream versions (plain v1.31.0 tags)
ankra cluster hetzner create ... \
  --distribution kubeadm \
  --etcd-topology external \                                 # default: stacked (etcd on control planes)
  --etcd-node-count 3 \                                      # 3 or 5, external only
  --etcd-server-type cx33                                    # OVH: --etcd-flavor-id, UpCloud: --etcd-plan, DigitalOcean: --etcd-size

• Version tags differ per distribution: ankra cluster k3s-versions lists v1.30.0+k3s1-style tags; kubeadm-versions lists plain v1.31.0 tags. Upgrades reject the wrong format.
• External etcd is kubeadm-only, fixed at create time (no resize), on dedicated VMs.

ankra cluster provision and ankra cluster deprovision start and stop an already-created managed cluster - they are not how you create one. Creation is always ankra cluster <provider> create.

3. Manage the lifecycle

Same verbs exist under hetzner, ovh, upcloud, and digitalocean:

ankra cluster ovh k8s-version <cluster_id>                   # current Kubernetes version
ankra cluster ovh upgrade <cluster_id> ...                   # upgrade Kubernetes
ankra cluster ovh workers <cluster_id>                       # current worker count
ankra cluster ovh scale <cluster_id> ...                     # scale workers

ankra cluster ovh control-plane get <cluster_id>
ankra cluster ovh control-plane set-count <cluster_id> 3     # 1 or 3 controllers
ankra cluster ovh control-plane set-instance-type <cluster_id> ...

ankra cluster ovh nodes list <cluster_id>
ankra cluster ovh nodes get <cluster_id> <node>

ankra cluster ovh node-group list <cluster_id>
ankra cluster ovh node-group add <cluster_id> ...            # async by default; --wait to block
ankra cluster ovh node-group scale <cluster_id> <group> ...
ankra cluster ovh node-group upgrade <cluster_id> <group>    # instance/plan change, irreversible
ankra cluster ovh node-group delete <cluster_id> <group>

OVH-only extras (parity with the web UI)

ankra cluster ovh node-group add <cluster_id> --labels k=v,... --taints k=v:Effect,...
ankra cluster ovh node-group labels <cluster_id> <group> --labels k=v,...   # empty value clears
ankra cluster ovh node-group taints <cluster_id> <group> --taints k=v:Effect,...  # effect defaults NoSchedule
ankra cluster ovh stop <cluster_id>                          # stop compute, keep config
ankra cluster ovh start <cluster_id> [--scope all|control_plane]
ankra cluster ovh access-info <cluster_id>                   # bastion/control-plane IPs + ssh -J / port-forward commands
ankra cluster ovh ssh-keys get <cluster_id>
ankra cluster ovh ssh-keys set <cluster_id> --ssh-key-credential-ids <id>,...  # applies on next reconcile

(Hetzner, UpCloud, and DigitalOcean node groups support add/list/scale/upgrade/delete; labels/taints, start/stop, access-info, ssh-keys, and regions are OVH-specific today. DigitalOcean adds regions and sizes discovery commands.)

Provider-native managed Kubernetes (DOKS & UKS)

For DigitalOcean Kubernetes (DOKS, kind doks) or UpCloud UKS (kind uks) instead of self-managed K3s on VMs, use the platform API:

curl -X POST https://platform.ankra.app/org/clusters/managed/doks \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"prod","credential_id":"<do_cred_id>","location":"nyc3","node_pools":[{"name":"default","size":"s-2vcpu-4gb","count":2}]}'

4. Deprovision / delete (destructive)

ankra cluster deprovision <cluster_id>                  # stop; for cloud clusters releases cloud resources
ankra cluster deprovision <cluster_id> --auto-delete    # stop then delete the cluster record
ankra cluster <provider> deprovision <cluster_id>       # provider-specific teardown
ankra delete cluster <name>                             # delete the cluster (supports --dry-run)

Confirm the target with ankra cluster info first; deprovisioning releases infrastructure.

Rules

• Least-privilege provider credentials, stored in Ankra and validated (ankra credentials get) before provisioning. Pass credential IDs, not names, to create.
• Pick a valid region first (ankra cluster ovh regions, ankra cluster digitalocean regions); a region not enabled on the account fails the reconcile at private-network setup.
• Confirm the target before any deprovision, delete, scale-down, or version/instance upgrade. Node-group upgrade is irreversible.
• Use --wait when a follow-up step depends on the result; otherwise treat creates and node-group mutations as in-flight and don't re-submit.
• Plan node groups for workload isolation rather than one undifferentiated pool, and right-size them to avoid inflated cost.
• Upgrade deliberately - review the target Kubernetes version and upgrade non-prod first.

Related skills

• ankra-cli for the broader command surface, auth, and async/--wait conventions.
• ankra-stacks-addons / ankra-gitops to deploy workloads once the cluster exists.