How to Stop Overpaying for the Cloud and Start Living with Kubernetes Autoscaler

Imagine this: you've launched an advertising campaign, traffic spikes, and your pods in Kubernetes start "choking" under the load. Or the opposite: night falls, users are asleep, but dozens of expensive instances keep spinning in the cloud, burning through your company budget. Sound familiar?

Usually in moments like these, people remember autoscaling. In the Kubernetes ecosystem, this is handled by the kubernetes/autoscaler repository. It's not just a single utility, but a whole suite of tools that help the cluster "breathe" with the load. I decided to figure out what's inside and why it's a must-have for any production environment.

What's Under the Hood

The repository houses three main components. Each solves its own specific task, and they're often confused with each other.

Cluster Autoscaler: When There's Not Enough "Iron"

This is probably the most popular tool in the set. Its job is simple: if pods appear in the cluster that can't start due to lack of resources (Pending status), Cluster Autoscaler goes to the cloud provider and asks to add a new node.

It works the other way around too. If some node has been sitting half-empty for a long time and its pods can be safely moved to other nodes, the autoscaler will remove the extra hardware. This is direct cost savings, especially if you're on AWS, GCP, or Azure.

Vertical Pod Autoscaler (VPA): The Magic of Resource Tuning

If Cluster Autoscaler changes the number of nodes, then VPA changes the "size" of the pods themselves. Often developers set requests and limits by eye. The result is either the application crashes with OutOfMemory, or we reserve 2 GB of RAM where only 200 MB is needed.

VPA monitors actual resource consumption and automatically adjusts the limits. The project is currently in beta status, but it already does something really cool — recommendation mode. You can just watch what resources it suggests setting, without trusting it to automatically restart pods.

Addon Resizer: Micro-Management for System Services

This is a simplified version of the vertical autoscaler. It's needed for services whose resource consumption scales linearly with cluster size. For example, the metrics server needs more memory if you have 100 nodes instead of 10. Addon Resizer monitors the number of nodes and scales such auxiliary components accordingly.

How It Works in Practice

Let's say you're using Go. To start working with the project code locally, you need to follow the path structure that Kubernetes is used to. The code should live in k8s.io, not in github.com.

Interesting point: Cluster Autoscaler supports dozens of providers. There are not only giants like AWS, but also specific solutions for bare-metal or local clusters. If you're building your own cloud service, you'll need to implement the CloudProvider interface, and your cluster will learn to scale too.

Why This Matters for Developers

Many think autoscaling is the DevOps engineer's job. In reality, understanding how vertical-pod-autoscaler works makes life much easier for backend developers.

1. You can forget about guesswork when configuring resources.
2. Applications become more resilient to sudden traffic spikes.
3. You see the real memory and CPU consumption profile of your code.

By the way, the repository contains official Helm charts for quick installation. That's much more convenient than trying to manually deploy manifests.

Should You Adopt It Right Now?

If you're working in the cloud and your infrastructure bills are growing, then Cluster Autoscaler is the foundation. It pays back the setup time within the first month of operation.

The situation with Vertical Pod Autoscaler is more complicated. Since it restarts pods to change resources (until K8s gets proper in-place resource updates), it needs to be used carefully. I'd suggest starting with Recommender mode. You'll get a list of resource optimization tips, but VPA won't touch anything.

The project is alive and well, backed by a huge community (almost 9,000 stars and thousands of forks). If you have questions, the folks are active in the Kubernetes Slack channel #sig-autoscaling.

So if your cluster is still static — take a look at this repository. It's time to make the cloud work for you, not against you.