Enable autoscaling
The Cluster Autoscaler automatically adjusts the number of nodes in a node pool to meet demand. If pods cannot be placed due to a lack of capacity, it provision additional nodes; if nodes remain underutilised for a prolonged period, it removes them.
Autoscaling is configured per node pool. A cluster may contain pools with and without autoscaling at the same time.
Distinction from Horizontal Pod Autoscaling
| Mechanism | Scales | Configuration |
|---|---|---|
| Cluster Autoscaling (CA) | Number of nodes | Per node pool in Control Panel |
| Horizontal Pod Autoscaling (HPA) | Number of pods | Via a HorizontalPodAutoscaler object in the cluster |
The two complement each other: HPA launches additional pods, whilst CA provides the necessary nodes. For load-based scaling, both should be active. See Horizontal Pod Autoscaling.
Enable when creating a cluster
- In the creation dialogue, under Choose Cluster capacity, select the Set node pool to autoscale option.
- Specify Minimum Nodes and Maximum Nodes.
The two limit values therefore replace the Nodes field. The Summary then displays the costs as a range.
Enable for an existing node pool
- Open the cluster and go to the Resources tab.
- Open the Kebab menu (three dots) for the desired node pool.
- Tick Set node pool to autoscale and set the minimum and maximum values.
- Save the change.
In the overview, the Autoscale column then shows On, whilst the Nodes column shows the configured range, such as 3-5.
Choosing appropriate limit values
- Minimum: Determines the base capacity that is always available. For production pools, set this to at least 2 to ensure the application remains accessible during upgrades. If the minimum is set too low, sudden spikes in load will result in waiting times, as new nodes must first be provisioned.
- Maximum: Sets an upper limit on costs. Choose a value that covers the expected peak load – but not so high that a faulty application can request an unlimited number of nodes.
Estimating costs
Only nodes that are actually running are billed. The summary therefore shows a range.
Example of a C3-type pool – costs scale linearly with the number of nodes:
| Number of nodes | Cost per month |
|---|---|
| 3 (minimum) | 3 × node price |
| 5 (maximum) | 5 × node price |
The maximum costs are incurred only in the event of sustained full capacity utilisation.
Requirements for reliable scaling
The autoscaler makes its decision based on the requested resources (requests), not on the actual utilisation. Without requests set, it cannot determine the demand correctly:
spec:
containers:
- name: web
image: nginx:stable
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
If the requests value is set too high, nodes will be added even though there is still spare capacity. If the value is set too low, nodes will become overloaded.
Check behaviour
# Nicht platzierbare Pods erkennen
kubectl get pods --field-selector status.phase=Pending
# Ursache im Abschnitt Events
kubectl describe pod <pod-name>
# Reservierte Kapazität je Node
kubectl describe node <node-name>
The 0/3 nodes are available: Insufficient cpu message indicates that the Autoscaler should provision an additional node. If this does not happen, the configured maximum has already been reached.
Notes
- It takes a few minutes to provision a new node. Autoscaling therefore does not immediately handle peak loads – ensure you maintain sufficient base capacity above the minimum.
- Nodes are only removed once their pods can be placed elsewhere.
- Pods without a controller (i.e. without a Deployment or StatefulSet) can prevent a node from being removed.
- A
PodDisruptionBudgetis taken into account during downscaling.
Related topics
All prices are exclusive of VAT.