Akasha.
DocsAbout managed KubernetesManage worker pools

Manage worker pools

Scale, autoscale, label, and taint worker pools, add pools with data disks, and understand what can only be set at pool creation.

Workers are grouped into pools named <cluster>-md-<n>. Each pool has its own flavor, replica count, labels, taint, and data disk configuration. Manage pools from the cluster's Nodes tab; the Overview tab offers quick replica steppers.

Scale a pool

  1. Open the cluster and select the Nodes tab.
  2. On the pool's card, edit Replicas (minimum 0) and save.

Scaling down removes worker machines; Kubernetes reschedules their pods onto the remaining workers.

Autoscaling

Each pool has an Enable Autoscaler checkbox with Min and Max fields. When enabled, the cluster autoscaler adds workers when pods cannot be scheduled and removes underused workers, keeping the pool between the bounds you set.

Node labels and taints

Expand a pool's Worker Config Patches section to set scheduling metadata:

  • Node Labels — key/value labels applied to every node in the pool. The label node-role.kubernetes.io/worker is always added automatically.
  • Restrict scheduling (taint) — one taint per pool, with a key, value, and effect (NoSchedule, PreferNoSchedule, or NoExecute). The form shows a live YAML preview of the toleration your pods need in order to schedule onto the tainted pool.

Tainted pools are useful for dedicating workers to a workload — for example, pinning a database to its own pool.

Add a worker pool

  1. On the Nodes tab, open the Add Worker Pool form.
  2. Enter a Pool Name suffix; the full name is shown as <cluster>-md-<suffix>.
  3. Pick a flavor (same options as at cluster creation, or a custom c<vCPU>-m<GB> value) and Initial Replicas (minimum 1).
  4. Optionally attach a Data Disk: none, 20, 50 (default), 100, or 200 GiB, or a custom size; choose the Storage Pool and a Storage Type:
    • OpenEBS-LVM — LVM-backed local persistent volumes.
    • Longhorn — the disk is prepared for Longhorn's distributed, replicated storage.
    • Raw (unmanaged) — the disk is attached but left for you to manage.
  5. Optionally set node labels, a taint, and extra Talos machine config patches (YAML). These patches can only be set here, at creation time.
  6. Create the pool. New machines appear in the pool's machine table with their phase and IP.

If the pool name collides with leftover resources from a previously deleted pool, the form reports it — pick a different suffix.

Talos config patches are creation-only

Talos machine config patches on a worker pool cannot be edited after the pool exists — the Save Patches button is disabled with the note "Currently not supported — recreate the node pool instead". To change patches:

  1. Create a new pool with the desired patches.
  2. Move workloads over (labels/taints can help steer scheduling).
  3. Delete the old pool.

Delete a pool

Deleting a pool destroys all machines in it.

  1. On the pool's card, choose delete.
  2. Type the pool name to confirm.

The control plane

The Nodes tab also shows the control plane:

  • Replicas — 1 or 3. Changing the replica count requires typing the control plane's name (<cluster>-cp) to confirm, because destroying control-plane machines can result in data loss.
  • Kubernetes Version — read-only. The platform pins the version; there is no upgrade flow.
  • Flavor — read-only after creation.