Cluster Autoscaler adjusts the number of machines available to run Kubernetes workloads. When a Pod cannot be scheduled because suitable capacity is missing, it can grow a configured node group; when machines can be removed safely, it can shrink that group. Teams use it to avoid keeping every possible worker running all the time. It changes machine capacity, while a separate application autoscaler decides how many copies of an application should run.
Deployment and operating notes
Cluster Autoscaler remains a Kubernetes project that adjusts node capacity for unschedulable pods and removes eligible underutilized nodes. The historical stable chart has been superseded by the chart in kubernetes/autoscaler. The project recommends the latest Cluster Autoscaler patch release for the same Kubernetes minor version; matching patch numbers is not required. Follow release-specific documentation rather than treating an old provider README's minimum version as a current compatibility promise.
Identify who owns node-pool scaling before installing anything: a managed cloud service may already run the controller. Configure discovery, pool limits and cloud permissions explicitly. For scale-up diagnosis, inspect resource requests, affinity, taints and available node shapes. For scale-down, inspect disruption budgets, local data, placement restrictions and controller logs. Rehearse one pending-pod scenario and one drainable-node scenario while observing application availability. Keep minimum capacity sufficient for rollback and disable the old controller before transferring ownership of the same groups. Do not expect Cluster Autoscaler to resize application replicas or optimize a workload whose scheduling requests are inaccurate.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-09T14:58:58+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
This chart bootstraps a cluster-autoscaler deployment on a Kubernetes cluster using the Helm package manager. Cluster Autoscaler is a tool that automatically adjusts the size of the Kubernetes cluster when one of the following conditions is true:
- works with autoscaling groups on AWS, AKS and GCE
- there are pods that failed to run in the cluster due to insufficient resources,
- there are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes.ns.
When does Cluster Autoscaler change the size of a cluster?
Cluster Autoscaler increases the size of the cluster when:
- there are pods that failed to schedule on any of the current nodes due to insufficient resources.
- adding a node similar to the nodes currently present in the cluster would help.
- Cluster Autoscaler decreases the size of the cluster when some nodes are consistently unneeded for a significant amount of time. A node is unneeded
- when it has low utilization and all of its important pods can be moved elsewhere.
What are the key best practices for running Cluster Autoscaler?
- Do not modify the nodes belonging to autoscaled node groups directly. All nodes within the same node group should have the same capacity, labels and system pods running on them.
- Specify requests for your pods.
- Use PodDisruptionBudgets to prevent pods from being deleted too abruptly (if needed).
- Check if your cloud provider’s quota is big enough before specifying min/max settings for your node pools.
- Do not run any additional node group autoscalers (especially those from your cloud provider).
Releases
We recommend using Cluster Autoscaler with the Kubernetes master version for which it was meant. The below combinations have been tested on GCP. We don’t do cross version testing or compatibility testing in other environments. Some user reports indicate successful use of a newer version of Cluster Autoscaler with older clusters, however, there is always a chance that it won’t work as expected. Cluster Autoscaler 0.5.X is the official version shipped with k8s 1.6. We’ve done some basic tests using k8s 1.6 / CA 0.6 and we’re not aware of any problems with this setup. However, Cluster Autoscaler internally simulates Kubernetes’ scheduler and using different versions of scheduler code can lead to subtle issues.
Deployment
Cluster Autoscaler is designed to run on Kubernetes master node. This is the default deployment strategy on GCP. It is possible to run a customized deployment of Cluster Autoscaler on worker nodes, but extra care needs to be taken to ensure that Cluster Autoscaler remains up and running. Users can put it into kube-system namespace (Cluster Autoscaler doesn’t scale down node with non-mirrored kube-system pods running on them) and add a scheduler.alpha.kubernetes.io/critical-pod annotation (so that the rescheduler, if enabled, will kill other pods to make space for it to run).
The post Cluster-Autoscaler appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →