Node pools

A node pool is a group of identical worker nodes within a cluster. Your workloads run on the nodes in your pools. A cluster can have one pool or several, and you manage them all from the portal.

Exact sizing — no tiers

Aether has no fixed machine “tiers.” When you create a pool, you choose the exact size of every node in it:

• vCPUs
• Memory (GB)
• Disk (GB)

Every node in a given pool is identical. If you need a different node size, create another pool.

Fixed vs autoscaling pools

Every node in a pool is always the same per-node size (vCPU/RAM/disk). What differs is how many nodes the pool runs. In the Add Node Pool form a Fixed | Autoscaling toggle picks one of two kinds:

• Fixed pool — the pool’s CPU/memory budget permits no scaling (minimum and maximum total vCPUs equal, and the same for total memory), so it runs a constant number of nodes. You set that node count. Best for steady, predictable workloads.
• Autoscaling pool — you set a CPU/memory budget for the whole pool whose maximum exceeds its minimum on total vCPUs or on total memory: a minimum and maximum total vCPUs and a minimum and maximum total memory (GB), plus an initial node count. Aether’s autoscaler adds nodes (of the pool’s fixed per-node size) when pods can’t be scheduled and removes them when they’re no longer needed, keeping the pool’s totals within that budget. Best for bursty or variable workloads.

The choice also affects how the pool is billed. Every node — in either kind of pool, whether or not it becomes Ready, and whether it is one of the pool’s first nodes, one added later, or a replacement — has a 15-minute grace period, measured from the moment it first appears in the cluster’s node list, and a node removed within that window carries no node charge. A node counts as removed when you ask for its removal; the time it then spends draining is never billed.

Past that, the pool’s mode applies. Fixed pools bill per pool rather than per node: the flat monthly fee isn’t charged if the pool is removed within 15 minutes of its first node appearing in the cluster’s node list, and once the pool is past that the calendar month is locked — full month, no proration. Autoscaling pools bill per started node-hour, per node, counted from the moment each node first appears in the cluster’s node list — the same event the grace period starts from, so the grace period is not deducted from the hours billed. See the Billing model for the details.

Drain timeout

Whenever a pool loses a node — you scale it down, the autoscaler removes surplus capacity, or you delete the pool — Aether cordons that node and evicts its pods so they can move elsewhere first. The pool’s drain timeout is how long it waits for that before removing the node anyway.

• Set it in seconds, from 30 to 3600.
• Leave it empty and the pool uses the platform default of 600 seconds (10 minutes). A pool you leave unset keeps tracking that default rather than being pinned to today’s value.
• You can change it later on an existing pool — unlike labels and taints, it isn’t fixed at create time.
• Raising it never costs you anything: billing for a node stops when you ask for its removal, and the drain that follows is never billed.

Think of it as the graceful-shutdown budget for your workloads. Within the timeout your PodDisruptionBudgets are respected and your pods get their full terminationGracePeriodSeconds; when it expires the node goes away regardless. Raise it for workloads that need to drain connections or flush state, lower it for stateless workloads you’d rather replace quickly.

Scale-down delay and utilisation threshold

Autoscaling pools only. An autoscaling pool gives capacity back when it no longer needs it. Two per-pool settings control when the autoscaler decides a node is surplus. They are the counterpart to the drain timeout above, which controls how the node is removed once that decision has already been made.

• Scale-down delay — how long a node has to stay underutilised before the autoscaler decides to remove it. Set it in seconds, from 60 to 3600. Leave it empty and the pool uses the platform default of 600 seconds (10 minutes).
• Scale-down utilisation threshold — how empty a node has to be to count as underutilised. A node is underutilised when both its CPU and its memory requests are below this share of the node’s allocatable capacity. Set it as a percentage, from 10 to 90. Leave it empty and the pool uses the platform default of 50 %.

Both can be set when you add a pool and changed later on an existing pool. They don’t appear on fixed pools — a fixed pool has no autoscaler making scale-down decisions, so the settings would do nothing there.

A pool you leave unset keeps tracking the platform default rather than being pinned to today’s value. Once you have set a value you can change it to another value, but you can’t clear it back to the default — an empty box on an edit means “leave unchanged”, not “reset to default”. To go back to default behaviour today, set the value explicitly to 600 seconds or 50 %.

Picking values:

• Raise the delay for spiky traffic, so a short lull doesn’t cost you a node you’ll need again minutes later. Lower it to hand capacity (and cost) back faster.
• Lower the threshold to make scale-down more conservative — the node has to be emptier before the autoscaler will touch it. Raise it to reclaim nodes that are only lightly used.

Remember these act on requests, not actual usage: a pod that requests 2 vCPU and uses 0.1 keeps its node looking busy.

Protecting a workload from scale-down

Sometimes a specific pod must not be interrupted, whatever the pool’s settings say. Kubernetes’ cluster-autoscaler honours two annotations that you apply to your own objects with kubectl — they aren’t Aether settings and there’s no portal field for them:

• Protect a pod — annotate the pod cluster-autoscaler.kubernetes.io/safe-to-evict: "false". The autoscaler will not remove the node hosting that pod until the pod finishes. Useful for batch jobs and long-running tasks that can’t be restarted mid-flight.
• Freeze a node — annotate the node cluster-autoscaler.kubernetes.io/scale-down-disabled: "true". The autoscaler leaves that node alone entirely.

Caution

Both annotations hold on to nodes the pool would otherwise release, and an autoscaling pool bills per node, per hour. A safe-to-evict: "false" pod that never finishes, or a node left frozen after the debugging session that needed it, keeps paying for capacity you aren’t using.

Node labels and taints

When you create a pool you can optionally give its nodes Kubernetes labels and taints:

• Labels — key=value, comma-separated. Leave empty for none.
• Taints — key=value:Effect, comma-separated, where Effect is one of NoSchedule, PreferNoSchedule, or NoExecute. Leave empty for none.

Aether applies them to the pool’s nodes automatically at provisioning — you don’t run kubectl label or kubectl taint yourself.

A taint repels pods that don’t tolerate it. To run a workload on a tainted or labeled pool, add a matching nodeSelector and toleration to your own pods — Aether never modifies your workloads. Aether’s own platform components already tolerate the taints, so the node stays functional.

Caution

Some key prefixes are reserved and rejected: keys starting with aether.cloud/, kubernetes.io/, k8s.io/, node-role.kubernetes.io/, or node.kubernetes.io/.

A cluster must always keep at least one pool with no NoSchedule or NoExecute taint so platform services have somewhere to run — Aether rejects a configuration that would leave none.

Labels and taints are set at create time and can’t be changed later. To re-tier, create a new pool with the labels/taints you want and drain the old one.

Managing pools from the portal

On a cluster’s Node Pools tab you can:

• Add a pool — choose its per-node size, pick Fixed (a node count) or Autoscaling (a CPU/memory budget), and optionally set node labels, taints, and a drain timeout. Autoscaling pools also offer the scale-down delay and scale-down utilisation threshold. Aether provisions the new nodes and joins them to the cluster.
• Scale a pool — change the node count (or the autoscaling range). Aether adds or removes nodes to match. The drain timeout can be adjusted here too, as can the scale-down delay and utilisation threshold on an autoscaling pool.
• Delete a pool — Aether tears down all of the pool’s nodes and removes them from the cluster.

Caution

Deleting a pool destroys its nodes. Any workloads pinned to that pool will be rescheduled onto your remaining nodes if capacity allows — make sure you have somewhere for them to go.

For hourly nodes, billing stops the moment you confirm the deletion, before the drain runs — that instant is when they stop accruing. A fixed pool’s flat charge for the month stays payable: deleting a fixed pool past its 15-minute grace period does not cancel or refund it.

Deleting a pool and creating another, even with the same name in the same month, is a new pool with its own grace period and its own monthly charge. See the Billing model.

Learn more

• Node-pool model — the lifecycle states and semantics in depth.
• Billing model — how fixed and autoscaling pools are charged.