Skip to main content
Ankra-provisioned clusters on Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, AWS EC2 and Ankra Cloud (both k3s and kubeadm; Scaleway and Ankra Cloud are in closed beta) can automatically scale worker node groups based on pod demand. Ankra runs the upstream Kubernetes Cluster Autoscaler inside your cluster and wires it to the Ankra platform, which provisions and removes the actual cloud servers. When pods are unschedulable because a node group is full, the autoscaler adds nodes (up to the group’s max). When nodes sit underutilised and their pods fit elsewhere, it drains and removes them (down to the group’s min), respecting PodDisruptionBudgets throughout.

​
How it works

Autoscaling is configured per node group with three settings: Behind the scenes:
  1. The Cluster Autoscaler runs in your cluster and watches for unschedulable pods and underutilised nodes.
  2. It talks to the Ankra agent in-cluster (over mutual TLS), which forwards scaling decisions to the Ankra platform.
  3. The platform creates or drains/deletes the actual cloud servers through the same provisioning pipeline used for manual scaling - every change shows up as an operation and an audit entry attributed to cluster-autoscaler.
Scale-down drains nodes before removal and honours PodDisruptionBudgets. Scale-up clones the group’s existing worker configuration (instance type, labels, taints).
Enabling autoscaling requires a recent ankra-agent (the platform tells you the minimum version if the cluster’s agent is too old). The Cluster Autoscaler itself is installed automatically the first time you enable autoscaling on any group - no manual Helm work needed.

​
Enable at cluster creation

In the create wizard for any of these providers, toggle Enable autoscaling on a node group and set Min/Max. The node count becomes the group’s initial count and must lie within the bounds. Via the API, include an autoscaling object per node group:

​
Enable on an existing cluster

​
Via the Platform UI

1

Open the node groups

Open Nodes in the cluster sidebar, then the Node groups tab.
2

Toggle autoscaling on the node group

On the node group card, switch Autoscaling on and set Min and Max. The manual node-count stepper becomes read-only (“Managed by autoscaler”).
3

Save

Saving persists the bounds and installs the Cluster Autoscaler (plus metrics-server) on first enable.

​
Via the CLI

The cloud provider is detected automatically from the cluster.

​
Via the API

​
Interaction with manual scaling

Per-group manual scaling stays available while autoscaling is enabled, but the requested count is clamped into [min, max] - you cannot manually push an autoscaled group outside its bounds. The legacy whole-cluster worker scale (ankra cluster scale) is refused while any group is autoscaling-enabled, since it removes workers across all groups indiscriminately. To take full manual control again, disable autoscaling first. New nodes added by the autoscaler carry the group’s labels and taints, plus the canonical ankra.cloud/node-group label Ankra uses to track group membership.

​
Behaviour details

  • Scale-down is conservative by default: a node must be unneeded for ~10 minutes, and scale-down pauses for 10 minutes after any scale-up.
  • Failed provisioning is self-healing: if a cloud server fails to create or join, the autoscaler is told about the failure and backs off; stuck half-created servers are garbage-collected automatically.
  • Node upgrades and autoscaling do not fight: a node the autoscaler is draining for removal is skipped by Kubernetes version upgrades.
  • Control planes are never autoscaled - only worker node groups.

​
Limitations (v1)

  • Min must be at least 1. Scale-to-zero is not supported yet: the autoscaler templates new nodes from a live node of the group.
  • While a group has zero Ready nodes, scale-up is degraded for the same reason.
  • Deleting a node group removes its autoscaling settings with it.
  • The cluster’s pod range caps the whole cluster. A cluster created with a network identity holds at most 64 nodes, control planes included (see Network ranges and their limits). A Max that would let the groups grow past that is refused when you set it, and a scale-up the autoscaler asks for past it is refused, so the autoscaler backs off instead of adding a node that could never become Ready.
Operators can globally suspend autoscaler-driven scaling without touching clusters by setting AUTOSCALER_ENDPOINTS_ENABLED=false on the platform - the in-cluster autoscaler keeps observing, but its scaling requests are refused until the switch is turned back on.