Skip to content
Aether Docs

Node-pool model

This page covers the node-pool model in depth. For step-by-step instructions on creating and managing pools, see the Node pools guide.

Identical nodes per pool

Section titled “Identical nodes per pool”

A node pool is a set of identical worker nodes. Every node in a pool has the same size, so your workloads see uniform capacity wherever they’re scheduled within the pool. To run different node sizes in one cluster, you create multiple pools.

Exact sizing

Section titled “Exact sizing”

There are no machine tiers. You specify the exact resources for each node in a pool:

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

This lets you size nodes to your actual workload rather than rounding up to the nearest predefined tier.

Fixed vs autoscaling

Section titled “Fixed vs autoscaling”

The per-node size is always fixed for a pool. What a pool’s kind controls is how many of those nodes run:

  • Fixed pool — you set a constant node count. The pool always holds that many nodes. Predictable capacity and predictable cost.
  • Autoscaling pool — instead of a node count you set a CPU/memory budget for the whole pool: minimum and maximum total vCPUs and minimum and maximum total memory (GB) (plus an initial node count). Aether’s autoscaler adds nodes — each one the pool’s fixed per-node size — when pods can’t be scheduled, and removes them when capacity is no longer needed, keeping the pool’s totals within the budget.

The kind also determines billing — fixed pools bill a flat monthly fee, while autoscaling pools bill per node by the hour. See the Billing model.

Node labels and taints

Section titled “Node labels and taints”

A pool can carry Kubernetes labels and taints, set when it’s created:

  • Labels are key=value pairs; taints are key=value:Effect, where Effect is NoSchedule, PreferNoSchedule, or NoExecute. Either may be empty.
  • Aether applies them to the pool’s nodes automatically at provisioning — there’s no manual kubectl label or kubectl taint step.
  • A taint repels pods that don’t tolerate it. To target a tainted or labeled pool, add a matching nodeSelector and toleration to your own pods; Aether doesn’t modify tenant workloads. Aether’s platform components already tolerate the taints, so a tainted node still runs the cluster’s own services.

Two guardrails apply:

  • Reserved prefixes are rejected. Keys beginning with aether.cloud/, kubernetes.io/, k8s.io/, node-role.kubernetes.io/, or node.kubernetes.io/ can’t be used.
  • At least one schedulable pool must remain. A cluster must always keep one pool with no NoSchedule or NoExecute taint so platform services have somewhere to run; Aether rejects a change that would leave none.

Labels and taints are immutable after create — to re-tier, create a new pool with the labels/taints you want and drain the old one.

Lifecycle states

Section titled “Lifecycle states”

The portal surfaces each pool’s current state so you always know what’s happening:

  • Provisioning — the pool’s nodes are being created and joined to the cluster.
  • Scaling — nodes are being added (e.g. after you raise the count, or when an autoscaling pool grows).
  • Running — the pool is at its target size and healthy.
  • Degraded — one or more nodes are unhealthy or not at the expected state; Aether works to reconcile it.
  • Deleting — the pool is being torn down and its nodes removed.

These states let you follow scaling and provisioning operations in real time and confirm a pool is healthy before relying on it.

Learn more

Section titled “Learn more”