Description
This control checks that every Utho Kubernetes (UKS) node pool that carries variable workload can grow and shrink its worker-node count automatically in response to demand, rather than being pinned to a single fixed size.
The Utho console exposes no per-pool autoscale toggle - a node pool is defined only by an instance size and a Desired (Node) Count - but the deploy/nodepool API does expose a per-pool maxCount alongside count. Setting count/maxCount on the pool alone does not make it scale, however: autoscaling on UKS is delivered by installing the Utho Cloud Controller Manager and the upstream Kubernetes Cluster Autoscaler (Utho is a supported provider in kubernetes/autoscaler) into the cluster, which then grows and shrinks each pool between its minimum and maximum node bounds. Utho supports this on clusters running Kubernetes 1.20 or above.
The check passes when a Cluster Autoscaler is running against the cluster with sane per-pool bounds; it fails when pools are fixed-size with no autoscaler present.
Node pools pinned to a fixed Node Count with no autoscaler managing them.
Clusters where a demand spike (or a request flood) can exhaust node capacity and evict or crash-loop pods.
Idle over-provisioned capacity kept online purely to absorb occasional bursts.
Rationale
A node pool pinned to a fixed size cannot absorb traffic spikes, so a burst of legitimate load or an attacker's request flood exhausts node capacity, and the scheduler starts evicting or failing to place pods. A demand surge then becomes an availability outage instead of a transparent scale-out event.
Fixed pools also cut the other way: to survive occasional peaks operators over-provision and leave idle nodes running, which widens the attack surface and wastes spend for no resilience benefit. Autoscaling ties capacity to real demand, so the cluster is neither starved under load nor bloated at rest.
Availability: extra nodes are added before pods are evicted for lack of capacity.
Cost efficiency: nodes are removed when idle instead of billing 24x7 for peak headroom.
Resilience against volumetric abuse: capacity can track a spike rather than collapsing at a fixed ceiling.
Impact
Pros:
Applications stay available through traffic spikes without manual intervention.
Idle capacity is reclaimed automatically, lowering steady-state node spend.
Reduces the temptation to permanently over-provision 'just in case'.
Cons:
Requires deploying and maintaining the Utho Cloud Controller Manager and Cluster Autoscaler yourself (no managed toggle).
Needs accurate CPU/memory resource requests on workloads or the autoscaler makes poor decisions.
An overly high maximum can drive unexpected billing during a spike or a runaway workload.
Default Value
Utho node pools launch at a fixed Node Count with no autoscaling; nothing scales the pool until you deploy the open-source Kubernetes Cluster Autoscaler yourself (supported on clusters running Kubernetes 1.20 or above).
Pre-Requisite
Utho console access to the Kubernetes cluster and its node pools (account owner or a role that can manage clusters).
kubectl configured against the cluster (download the kubeconfig from the cluster's manage page).
Utho Cloud credentials / API token for the autoscaler secret, as described in Utho's autoscaling guide.
Cluster on Kubernetes 1.20+ and workloads that declare CPU/memory resource requests.
Remediation
Test Plan
Using the Utho Console:
Log in to the Utho Cloud console and open Kubernetes in the sidebar.
Select the cluster and scroll to Manage Node Worker Pools; note that each pool shows only a fixed Node Count and no autoscale/Max Count field.
Download the cluster's kubeconfig from the manage page so you can inspect the in-cluster autoscaler.
Using kubectl, run 'kubectl -n kube-system get deploy cluster-autoscaler' and 'kubectl -n kube-system get configmap cluster-autoscaler-status -o yaml' to see whether an autoscaler is running and which pools it manages.
Confirm each managed pool has an explicit min:max node range configured for the autoscaler.
Pass: a Cluster Autoscaler deployment is Running and every variable-workload pool has a sane min:max node range.
Fail: no Cluster Autoscaler is deployed, or one or more workload pools are fixed-size with no min/max bounds.
Using the Utho API:
Utho exposes no API for the in-cluster autoscaler; the API can only confirm the pool's current node count (and its maxCount ceiling), so read live autoscaler state with kubectl and use the API for pool composition.
curl -s -H 'Authorization: Bearer $UTHO_API_TOKEN' https://api.utho.com/v2/kubernetes/<cluster_id>
The API returns the pool's current node count (and maxCount). Pass/Fail for autoscaling is decided from kubectl: Pass if 'kubectl -n kube-system get deploy cluster-autoscaler' shows a Ready replica with node bounds covering the pool; Fail if no autoscaler is present.
Implementation Steps
Using the Utho Console:
In the Utho console open Kubernetes, select the cluster, and confirm each pool's fixed Node Count under Manage Node Worker Pools (this is the floor the autoscaler will grow from).
Deploy the Utho Cloud Controller Manager into the cluster so the autoscaler can call Utho Cloud, following Utho's autoscaling guide.
Install the Kubernetes Cluster Autoscaler, supplying your Utho credentials via the autoscaler secret from the guide.
Give each node pool an explicit minimum and maximum node range, keeping the maximum sane to cap node count and billing.
Set CPU/memory resource requests on all workloads so the autoscaler has accurate signals.
Run a stress/scale test and confirm via kubectl get nodes that nodes are added under load and removed when idle.
Using the Utho API:
Utho has no single API call that 'enables autoscaling'; the Cluster Autoscaler is installed in-cluster with kubectl/Helm. The API below creates the underlying pool and sets its count (floor) and maxCount (ceiling), which are the bounds the autoscaler then scales between.
curl -s -X POST -H 'Authorization: Bearer $UTHO_API_TOKEN' -H 'Content-Type: application/json' https://api.utho.com/v2/kubernetes/<cluster_id>/nodepool/add -d '{"nodepools":[{"label":"pool-autoscale","size":"<size_id>","count":"2","maxCount":"5","ebs":[{"disk":"30","type":"nvme"}]}]}'
Backout Plan:
Scale the autoscaler deployment to zero ('kubectl -n kube-system scale deploy cluster-autoscaler --replicas=0') to freeze node count without deleting config.
Set each pool back to a known-good fixed Node Count in the console so capacity is deterministic.
If the autoscaler must be removed entirely, uninstall the Cluster Autoscaler and, if unused elsewhere, the Cloud Controller Manager, then verify workloads still schedule on the fixed pool.