02 Node Pool autoscaling

Topics:

• About autoscaling
• Why use Node Pool autoscaling
• Client Credential for the autoscaler
• Configuring autoscaling
• Activating autoscaling
• Most commonly used autoscaler parameters
• Autoscaling service billing

Autoscaling is a feature available for Kubernetes clusters that automatically adjusts cluster resources according to the workload. In particular, it can increase or decrease the number of active nodes in a Node Pool, without manual intervention, based on the cluster's ability to schedule new pods.

The autoscaler's behaviour is based on continuous analysis of the cluster state. The system automatically takes action in two main situations:

• there are pods in Pending state because there are not enough resources available (scale-up);
• one or more nodes have been underutilised for a certain period of time and the pods can be relocated to other nodes (scale-down).

These conditions are evaluated every 10 seconds (this value can be changed using the --scan-interval parameter).
This feature dynamically balances cluster costs, performance and availability.

Autoscaling is recommended in scenarios where the cluster application workload can vary over time. In particular, it is useful when:

• workloads increase or decrease during predictable time slots or periods;
• unexpected workload peaks may occur;
• available resources need to be optimised to keep costs down;
• you want to reduce manual cluster scaling operations.

Enabling autoscaling makes cluster management more efficient because:

• it provides adaptability, allowing the cluster to automatically adjust to the actual workload;
• it provides efficiency by keeping only the nodes that are strictly necessary active at any given time;
• it simplifies management by reducing the need for manual monitoring and intervention;
• it helps optimise costs by automatically removing unused nodes.

Autoscaling is particularly suitable for environments with variable workloads that require operational continuity without constant monitoring.
The system also supports clusters with multiple Node Pools configured with autoscaling, allowing resources to be managed flexibly and independently according to workloads.
The autoscaler is based on the Aruba Cluster API Provider, integrated into the system to ensure compatibility with Node Pools.

To install and activate the autoscaler component within the cluster, you must have a valid Client Credential. The Client Credential allows the component to authenticate with the Aruba Cloud infrastructure.
You will need to use the two values that make up the Client Credential: Client ID and Client Secret.

During scale-up, the system adds new nodes to run pending pods. During scale-down, it automatically removes underutilised nodes, relocating active pods to other nodes whenever possible.

To correctly enable autoscaling on a Node Pool, you must set two key parameters:

• minimum number of nodes: the minimum configurable value is 0 and indicates the number of nodes below which the Node Pool cannot scale down;
• maximum number of nodes: the maximum configurable value is 6 and indicates the number of nodes above which the autoscaler cannot scale up, even if there are unschedulable pods.

The minimum value must be equal to or lower than the maximum value. An incorrect configuration will prevent autoscaling from being activated.

Setting these limits correctly allows you to:

• avoid wasting resources due to automatic overprovisioning;
• ensure operational continuity even during unexpected workload peaks;
• optimise costs.

After configuring the minimum and maximum autoscaling values for your Node Pool, you must install the autoscaler component within the cluster to make it operational.
You can do this in a few steps using Helm. See the guide on activating the autoscaler.

Below is a list of the most common parameters that you can use to customise the autoscaler's behaviour. These values can be specified when configuring the component during installation or later, if necessary.
 

Parameter	Description	Default
--address	Address and port on which the autoscaler exposes metrics.	:8085
--cordon-node-before-terminating	Automatically cordons nodes before termination.	true
--emit-per-nodegroup-metrics	Exports detailed metrics for each Node Pool.	false
--enable-proactive-scaleup	Enables proactive scale-up based on predictions.	false
--enforce-node-group-min-size	Ensures that the minimum number of nodes is maintained for each Node Pool.	false
--frequent-loops-enabled	Enables more frequent checks of the cluster state.	true
--ignore-daemonsets-utilization	Ignores resource utilisation by DaemonSets when calculating scale-down.	false
--ignore-mirror-pods-utilization	Ignores mirror pods when calculating resource utilisation.	false
--max-drain-parallelism	Maximum number of nodes that can be drained at the same time.	1
--max-graceful-termination-sec	Maximum time allowed for pod termination during scale-down.	600
--max-nodes-per-scaleup	Maximum number of nodes that can be added in a single scale-up operation. [Currently limited to 6]	100
--max-pod-eviction-time	Maximum time allowed for pod eviction before terminating the node.	120s
--max-scale-down-parallelism	Maximum number of nodes that can be removed in parallel.	1
--node-delete-delay-after-taint	Delay between tainting a node and removing it.	30s
--scale-down-delay-after-add	Time to wait after adding a node before scale-down.	10m
--scale-down-delay-after-delete	Time to wait after removing a node before another scale-down operation.	10s
--scale-down-delay-after-failure	Time to wait after a failed scale-down attempt.	3m
--scale-down-enabled	Enables or disables node scale-down.	true
--scale-down-unneeded-time	Minimum time before a node is considered unnecessary.	10m
--scale-down-utilization-threshold	Threshold below which a node is considered underutilised.	0.5
--scale-up-from-zero	Allows Node Pools to start with zero nodes when necessary.	true
--scan-interval	Interval between consecutive scans of the cluster state.	10s

Autoscaling has no additional cost, but it affects the total resources used by the cluster. As the number of active nodes can change dynamically, costs can also vary over time. Billing is based on the nodes that are actually running at any given time. In particular:

• active nodes, including those started automatically, are always counted as resources used;
• nodes removed by the autoscaler are no longer counted from the time they are deactivated.

If the maximum value configured for the Node Pool is significantly higher than the minimum value, the cluster may scale up considerably during workload peaks, with a significant impact on costs.
To optimise costs:

• set minimum and maximum values that are appropriate for the expected workloads;
• regularly monitor the number of active nodes;
• consider using separate Node Pools for test and production environments.

Related guides:

Aruba Managed Kubernetes service

Creating a Kubernetes cluster

Activating the autoscaler