Skip to main content
POST
Add node group

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Headers

x-ankra-organisation-id
string

PAT organisation override.

Path Parameters

cluster_id
string<uuid>
required

Body

application/json
instance_type
string
required
name
string
required

Node group name. In a create-cluster request it must be 1 to 63 lowercase letters, digits and hyphens, starting and ending with a letter or digit (an RFC 1123 DNS label), or the create is refused and nothing is created. Adding a node group to an existing cluster applies the day-2 name check instead.

autoscaling
object | null
count
integer
default:1

Number of nodes in the group, 0 to 100. A cluster create accepts 0. Adding the group to an existing cluster (POST .../node-groups) refuses 0 with a 409, because a node group exists through its nodes and one added with none would not be stored: add it with 1 or more.

Required range: 0 <= x <= 100
cpu_pool
string

Ankra Cloud CPU pool of the zone every server of the group is pinned to, scale-ups included, for example a pool of x86-64 level 3 for workloads that need AVX2. Omit it to let the Cloud place each server. Must be one of the zone's pools (GET /api/v1/clusters/ankracloud/{cluster_id}/cpu-pools).

Pattern: ^[a-z0-9]{1,16}-f[0-9]{1,4}-[0-9a-f]{10}$
disk_gibibytes
integer

Root disk size of every server of the group in GiB, scale-ups included. Omit it for the plan's included disk; Ankra Cloud refuses a size below the plan's and the template's minimum.

Required range: 1 <= x <= 4096
disk_tier
enum<string>

Storage tier of the root disk of every server of the group, scale-ups included. Omit it for the zone's default_storage_tier. local-nvme is the node's own disks; standard, maxiops and hdd are the zone's Ankra Storage (Ceph) tiers.

Available options:
local-nvme,
standard,
maxiops,
hdd
labels
object
taints
object[]

Response

Successful response

count
integer
required
dispatch
enum<string>
required

What the write did about the operation that applies it. started: operation_id names it, created in the same transaction as the write. deferred: the change is stored but no operation was started for it now; dispatch_reason says why and what applies it instead (the reconcile loop once a running operation has finished, or the cluster's next start). none: the write left nothing for an operation to apply (a scale to the group's current count, a removal on a stopped cluster, which the write applies to the group's records itself).

Available options:
started,
deferred,
none
group_name
string
required
operation_id
string<uuid> | null
required

The operation this write started, created in the same transaction as the write; poll it on /api/v1/org/executions/{execution_id}. It is the operation that creates the group's nodes, so when it finishes the nodes have been created. When the nodes needed no operation of their own and the group was added with autoscaling enabled, it is instead the operation that installs the cluster autoscaler, which moves no node, and dispatch_reason says so. Null when the write started none; dispatch says why.

dispatch_reason
string

Why no operation was started (deferred, none); what a started operation leaves to the reconcile loop (an offline cluster's agent work); and, for a group added with autoscaling enabled, the second operation the write started, which installs the cluster autoscaler and moves no node. Absent when a started operation carries the whole change and the write started no other.