Autoscaling

Worker autoscaling has two layers. The first is per-pool configuration in the panel: whether a pool autoscales, and the bounds it scales within. The second is the Cluster Autoscaler, a deployment that runs inside your cluster, watches for pods that cannot be scheduled, and asks the panel to add or remove workers through the pool bounds.

Both layers are required. Panel bounds alone do nothing without the autoscaler running; the autoscaler never crosses the bounds you set.

Before you begin

A running cluster. See Clusters.
At least one pool with Enable autoscaling on. See Node pools.
kubectl working against the cluster with your admin kubeconfig.

Where to find it

In the user panel go to Services > Clusters, open the cluster, then use the Node pools tab for bounds and the Autoscaler tab for the autoscaler itself. The admin panel shows the same two tabs after opening a cluster from Platform services > Kubernetes clusters.

Set the pool bounds

On the Node pools tab, edit a pool and set:

Field	What it does
Desired Size	The floor. The autoscaler scales back down to this size, never below. `0` allows full drain.
Max Size	The ceiling. The autoscaler never crosses it.
Enable autoscaling	Without this, the pool stays at the size you set manually.

The collapsed Scaling Rate Limits and Autoscaler Overrides sections tune how fast and how eagerly the autoscaler acts, per pool. See Node pools for each field.

Install the Cluster Autoscaler

The Cluster Autoscaler is not auto-installed. You apply it once per cluster:

Open the Autoscaler tab. The manifest becomes available once the cluster is running.
Click Refresh to load the manifest, then Copy.

Apply it with your admin kubeconfig:

kubectl apply -f - <<'EOF'
...paste the manifest here...
EOF

The manifest is self-contained: it carries the autoscaler deployment and the panel credentials it needs, so the whole install is one copy-paste. One deployment manages every autoscaling pool in the cluster; each pool appears to it as its own node group with its own bounds.

The autoscaler image comes from the Cluster Autoscaler Image your provider registered for the cluster’s Kubernetes version, or the platform default when none is registered.

How scaling behaves

Scale-up: pods stuck Pending for want of a matching node trigger the autoscaler to request new workers from the panel, up to the pool’s Max Size. The panel provisions the VMs and joins them to the cluster; the pool’s Max provision time (s) override bounds how long the autoscaler waits for a new node.
Scale-down: when nodes stay under the pool’s Utilization threshold for the Unneeded time (s), the autoscaler marks them for removal. Marked workers move to the Pending Deletions panel on the Node pools tab, where Cancel keeps them. The panel then drains each marked worker using the pool’s drain configuration and destroys it; this queue is processed about every 2 minutes.
Credentials: the autoscaler’s panel credential is valid for a year and renews itself from inside the cluster about 30 days before expiry. Nothing to do, and no periodic re-apply of the manifest. Renewals are capped at 12 per day per cluster as an abuse guard; normal operation uses a fraction of that.
Rate limits: the pool’s Max surge / period, Max unavailable / period, Period length (s) and the two cooldowns cap how many nodes change inside one window. When a limit is hit, the rest of the request waits for the next cycle.

Common problems

Pods stay Pending and no nodes appear. Confirm the pool has autoscaling enabled and is below Max Size, and that the autoscaler deployment is running (kubectl -n kube-system get deploy cluster-autoscaler). The pod’s nodeSelector or tolerations must match a pool.
Nodes never scale down. Desired Size is a hard floor; the autoscaler stops there. A strict PodDisruptionBudget or a safe-to-evict: false annotation also pins a node.
The autoscaler logs 401 errors. Its credential was retired, usually because the manifest was re-fetched after install. Click Refresh, copy, and kubectl apply the new manifest.