Skip to main content
Closed beta. Ankra Cloud clusters are part of Ankra Cloud as a cluster provider, which is in closed beta and enabled per organisation on request. Contact support to have it turned on for your organisation.
Use this guide to choose the servers and disks of an Ankra Cloud cluster and to make sure the account has room for them, before anything is built. The same choices apply when you add a node group later.

​
Before you start

  • An Ankra Cloud credential and an SSH key credential. Find their ids with ankra credentials ankracloud list and ankra credentials ssh-key list.
  • Ankra CLI logged in to the organisation.

​
1. Pick the zone

A zone that is only a network location runs no servers, and a zone with no public IPv4 left needs --network-mode ipv6_only. The preflight below names the mode a zone needs.

​
2. Pick server plans

A plan is a server size. Every role takes one: the bastion, the control planes, the workers, and the etcd nodes when etcd runs outside the control plane.
The template is the operating system the servers boot, debian-13 unless you pass --template. For an existing cluster, --cluster <name> lists the plans under that cluster’s own credential, for node groups and control-plane or bastion resizes.

​
Pin workloads that need AVX2 to a CPU pool

A zone’s compute nodes are grouped into CPU pools by exact CPU, and a server’s guest sees its host’s CPU. Images built for x86-64-v3 (many Python, Rust and ML wheels) need AVX2 and crash with an illegal instruction, exit 132, on a lower level.
A pool with x86-64 level 3 or more has AVX2. Every server the group creates, scale-ups included, is pinned to the pool.

​
3. Size and tier the root disks

Each server’s root disk is its plan’s included disk on the zone’s default storage tier unless you choose otherwise, per role: Sizes are in GiB, from the plan’s and template’s minimum up to 4096. The tiers are:
  • local-nvme - the compute node’s own disks: fastest, a single copy, pinned to one server.
  • standard, maxiops and hdd - the zone’s replicated Ankra Storage tiers.
CI workers belong on small local-nvme disks when their data lives on persistent volumes:
A node group takes the same choice with --disk-gib and --disk-tier on ankra cluster node-group add, for every server it creates. Persistent volumes are separate: they take their tier from their StorageClass. See Cloud controller and storage.

​
4. Check the quota

The Ankra Cloud account behind a cluster has limits on servers, cores, memory, storage, floating IPs, private networks and routers. For an existing cluster, see what is used and what is left:
Storage is shared by the servers’ disks and every PersistentVolumeClaim the Ankra Cloud CSI provisions, so a claim larger than what is left stays Pending. Applies and stack deploys that need more storage than is left say so in their warnings. A row marked (full) is exhausted. Storage and public IPv4 are priced separately from the plans:

​
5. Preflight the request

preflight takes exactly the flags create takes and builds nothing. It checks the credential, the zone, the plans, the template and the network, and counts the chosen disk sizes against the account’s storage quota:
When it passes, run the same command as create.

​
Change it later

  • Workers: add a node group with another plan, disk or CPU pool, and scale or remove the old one. See Node groups.
  • Control planes: ankra cluster ankracloud control-plane set-instance-type resizes every controller, one at a time on a cluster with three. control-plane get says whether a live resize is possible now.
  • Bastion: ankra cluster ankracloud bastion resize.

​
Troubleshooting