kubernetes/autoscaler: Cluster Autoscaler, VPA and Addon Resizer in one repository

Three components, three different scaling problems

The repository is not one autoscaler. It contains Cluster Autoscaler, Vertical Pod Autoscaler, Addon Resizer and a set of Helm charts, plus directories such as balancer/ and multidimensional-pod-autoscaler/ that are not described in the README. Cluster Autoscaler adjusts the size of a Kubernetes cluster so that all pods have a place to run and there are no unneeded nodes. It reached version 1.0 (GA) with Kubernetes 1.8 and supports several public cloud providers. Vertical Pod Autoscaler adjusts the CPU and memory requested by pods already running in the cluster, and the README marks it beta. Addon Resizer is described as a simplified version of VPA that modifies resource requests of a deployment based on the number of nodes in the cluster, also beta.

The split matters because these components answer different questions. Cluster Autoscaler answers whether the cluster has enough nodes. VPA answers how much CPU and memory each pod should request. Addon Resizer answers how much a cluster-wide addon should request as the node count changes. If you need horizontal pod replication, none of them does that; the README does not cover Horizontal Pod Autoscaler at all, and that lives in the main Kubernetes tree, not here.

How Cluster Autoscaler decides to add or remove a node

The mechanism described in the README is reactive at the cluster level. Cluster Autoscaler watches for pods that cannot be scheduled and grows the node group so those pods have a place to run. In the other direction it looks for nodes that are not needed and removes them. The README states the goal plainly: all pods have a place to run and there are no unneeded nodes.

That design has a direct consequence. Scaling up is triggered by scheduling failure, not by a predicted load curve. A pod that fits on existing capacity produces no scale-up event, even if the cluster is close to full. Scale-down depends on the autoscaler judging a node unnecessary, which means workload placement and disruption budgets influence the result as much as raw utilisation does. The README does not document the internal scoring, thresholds or cooldown behaviour, so anyone tuning this needs the provider-specific documentation under cluster-autoscaler/ rather than the top-level file.

Provider support is the other half of the architecture. The README says several public cloud providers are supported, and the cluster-autoscaler/ directory is where those implementations live. That is why the install path differs per cloud and why a generic tutorial rarely transfers cleanly.

VPA and Addon Resizer: changing requests instead of replica counts

Vertical Pod Autoscaler is described as a set of components that automatically adjust the amount of CPU and memory requested by pods. The README gives no detail on the recommender, updater or admission controller split, so the component-level architecture has to be read from the vertical-pod-autoscaler/ directory rather than the top-level README. What the README does establish is the state: beta.

Addon Resizer takes a narrower approach. It modifies resource requests of a deployment based on the number of nodes in the cluster. That is a simpler signal than observed CPU and memory usage, and it fits addons whose footprint scales with cluster size rather than with traffic. The trade-off is obvious: node count is a coarse proxy. A cluster that grows nodes without growing addon load will still see requests rise.

Both tools change requests rather than replica counts, which means they interact with the scheduler instead of the deployment controller. That is a different failure surface from Cluster Autoscaler. A bad VPA recommendation can make a pod unschedulable on existing nodes; a bad Cluster Autoscaler decision can leave pods pending or remove nodes that were still needed.

Getting the code and installing Cluster Autoscaler with Helm

The README's checkout instructions are specific about path layout. The code must be checked out as a subdirectory of k8s.io, not github.com, because the Go import path depends on it. The README gives this example, with the fork step done first in the GitHub UI:

mkdir -p $GOPATH/src/k8s.io
cd $GOPATH/src/k8s.io
# Replace "$YOUR_GITHUB_USERNAME" below with your github username
git clone https://github.com/$YOUR_GITHUB_USERNAME/autoscaler.git
cd autoscaler

After that, the repository layout is what you work from. The README points at a supported Helm chart for Cluster Autoscaler under cluster-autoscaler/charts. The README does not print an install command for that chart, so the chart's own values file is the place to look; the top-level file only names the chart as supported. The same pattern applies to Vertical Pod Autoscaler, which has its own supported chart under vertical-pod-autoscaler/charts and its own release stream. The most recent releases listed for the repository are vertical-pod-autoscaler-chart-0.12.0 on 2026-09-05 and addon-resizer-1.8.24 on 2026-08-06, which tells you the charts are versioned separately from the components.

If you are not installing from a chart, the README's only other guidance is the contributor workflow: fork, clone into k8s.io, and follow the Kubernetes GitHub workflow guide. There is no documented single-command deployment for the whole repository, and the README does not describe rollback.

Where this approach stops working

The clearest limitation is that Cluster Autoscaler reacts to unschedulable pods. If your workload is not blocked from scheduling, the cluster will not grow, even when headroom is thin. Teams that expect predictive scaling will find the behaviour counterintuitive, and the README offers no mitigation.

Second, VPA is beta. The README says so directly, and beta status in Kubernetes generally means the API and behaviour can still change. Anyone building automation on top of VPA objects should plan for that.

Third, the repository is a monorepo of components with separate release cadences. The chart versions do not track the component versions, so a chart upgrade and a component upgrade are two decisions, not one.

Finally, the README is thin on operations. It documents what each component is, not how to tune it, monitor it, or roll it back. If you need documented failure modes before you deploy, this README will not give them to you; the per-component directories and provider documentation are where that information lives.

Cluster Autoscaler versus Karpenter

Karpenter appears in the search data alongside Cluster Autoscaler, and the difference in approach is worth stating precisely. Cluster Autoscaler works through node groups: it adjusts the size of a group of nodes, and the cloud provider's node group implementation decides what instance type appears. The README frames the goal in terms of pods having a place to run and nodes not being wasted, which is a group-level accounting problem.

Karpenter provisions nodes directly from pod requirements rather than resizing a pre-defined group. That changes what you configure: with node groups you define the shapes in advance, with direct provisioning you describe constraints and let the provisioner choose. The practical consequence is that Cluster Autoscaler's behaviour is bounded by the node groups you created, while a direct-provisioning approach is not. The README does not compare the two, so this is a design distinction rather than a claim about which performs better. If your cluster is already organised around managed node groups and you want the supported chart from this repository, Cluster Autoscaler fits that structure. If you want instance selection driven by pod specs, that is a different tool.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-21, which is the same day as this assessment. Chart releases continue: vertical-pod-autoscaler-chart-0.12.0 on 2026-09-05, addon-resizer-1.8.24 on 2026-08-06, and vertical-pod-autoscaler-chart-0.11.0 on 2026-07-26. That release pattern shows active chart maintenance, but it also shows the upgrade cost: three releases in roughly two months across two chart names, each of which is a separate upgrade event.

The licence is Apache-2.0, stated in the repository metadata and present as the LICENSE file at the top level. Apache-2.0 permits commercial use and modification and includes a patent grant. It also requires that you keep the licence and notice files when you redistribute. That is a general description of the licence, not legal advice; if you are redistributing modified components, have your own counsel review the notice requirements. The repository also carries SECURITY_CONTACTS, CONTRIBUTING.md and a code of conduct, which is the standard Kubernetes project structure.

Editorial conclusion

Adopt this repository if you run Kubernetes on a supported public cloud and need node-level scaling or automatic CPU and memory request tuning; the code is Apache-2.0, current, and the Helm charts are the supported install path. Do not adopt it expecting a scheduling replacement: Cluster Autoscaler reacts to unschedulable pods and does not bin-pack workloads the way Karpenter does, and VPA is still beta. Before rollout, verify that your cloud provider has a Cluster Autoscaler implementation in cluster-autoscaler/, confirm the VPA admission controller webhook does not conflict with existing mutating webhooks, and check whether your workloads can tolerate pod restarts, since VPA updates requests by evicting pods.

Frequently asked questions

Official sources

1. Issues
2. kubernetes/autoscaler on GitHub
3. License: Apache-2.0
4. README
5. Releases