This topic describes the cluster autoscaler, which automatically controls the size of your node pools.
Autoscale a node pool
The cluster autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of your workloads. You don't need to manually add or remove nodes or over-provision your node pools. Instead, you specify a minimum and maximum size for the node pool, and the rest is automatic.
If resources need to be deleted or moved while autoscaling your cluster, your workloads might experience transient disruption. For example, if your workload consists of a controller with a single replica, that replica's Pod might be rescheduled onto a different node if its current node is deleted. Because of this, you must design your workloads to either tolerate potential disruption or ensure that critical Pods are not interrupted.
How the cluster autoscaler works
The cluster autoscaler works on a per-node pool basis. When you use the cluster autoscaler to configure a node pool, you specify a minimum and maximum size for the node pool. You can change the minimum and maximum size when you Create a node pool or Update a node pool.
The cluster autoscaler increases or decreases the size of the node pool automatically, based on the resource requests (rather than actual resource utilization) in that node pool. The cluster autoscaler adds nodes if Pod objects are unschedulable and there is not enough capacity in the node pool to meet requests.
The cluster autoscaler also removes nodes if they are underutilized and all Pod objects could be scheduled on a smaller number of nodes. If the node cannot be drained gracefully after 10 minutes, the node is forcibly terminated. This period is not configurable.
If a Pod requests too few resources (for example, if the defaults are insufficient), the cluster autoscaler does not correct the situation. You can help ensure that the cluster autoscaler works as accurately as possible by creating adequate resource requests for all of your workloads. For more information, see Managing resources for containers.
Operating criteria
The cluster autoscaler makes the following assumptions when resizing a node pool:
- All replicated Pod objects can be restarted on some other node, possibly causing a brief disruption. If your workload doesn't tolerate disruption, configure the workload to run on a node pool with autoscaling disabled. For more information, see Controlling scheduling with node taints.
- The cluster autoscaler can override any manual node management operations that you perform.
- All nodes in a single node pool have the same set of labels.
- The cluster autoscaler selects a node group that has the least idle CPU or unused memory after scaling up. This behavior affects which node pools are scaled up if you have different sizes of nodes (for example, high CPU or high memory nodes) in the same cluster.
Minimum and maximum node pool size
You can specify the minimum and maximum size for each node pool in your cluster
with the min-nodes and max-nodes flags. To disable autoscaling, set
min-nodes and max-nodes to the same number. The cluster autoscaler makes
scaling decisions within these size boundaries.
When you set the maximum size of your node pools, make sure that it is large enough to run all of your workloads. If the node pools in your cluster don't have enough memory and CPU available to run all of your workloads, outages might occur.
Use a PodDisruptionBudget to protect workloads
You can configure GKE on AWS to protect against workload disruption with a PodDisruptionBudget. When you create a PodDisruptionBudget, you specify the minimum number of Pod replicas that should be available, or the maximum number of Pod replicas that can be unavailable at any given time. For more information, see Specifying a Disruption Budget for your Application.