Kubernetes Autoscaling Introduction

So far, every time we wanted more pods we typed it ourselves: kubectl scale deploy telusko-deploy --replicas=5, or edited replicas: in the YAML. That works when you know the traffic in advance. Real traffic does not ask permission. A sale starts, a link goes viral, a batch of users logs in at 9 AM, and by the time someone notices, the pods are overloaded.

The opposite problem costs money: ten pods running at 3 AM for nobody.

Autoscaling means increasing and decreasing resources automatically, based on demand. Demand is measured with metrics such as:

• CPU utilization
• Memory utilization
• Requests per second (traffic)
• Custom metrics, for example the length of a queue

The goals are simple: handle high traffic without manual work, save resources when demand is low, keep the application available, and keep the infrastructure bill under control.

Horizontal vs vertical scaling

For stateless applications, horizontal scaling is what teams use most. More copies also means better availability: if one pod dies, the others carry on. Vertical scaling has its place (some databases, finding the right request values), but it has a ceiling and usually means restarting pods. Recent Kubernetes versions can resize a running pod's CPU and memory in place, but the HPA is still the standard tool for handling traffic.

The autoscalers you will hear about

Kubernetes scales two different things: pods and nodes.

These work together. The HPA adds pods. If the nodes are full, the new pods stay Pending, and a node autoscaler such as Karpenter adds EC2 instances. Our lab cluster has a fixed node group of two t3.small nodes, so in this course only the pods scale.

The Metrics Server comes first

The HPA cannot guess how busy a pod is. Something must measure it. That is the job of the Metrics Server:

• A small cluster add-on that collects CPU and memory usage of every node and pod from the kubelets
• Keeps only the latest values, in memory, and serves them through the metrics.k8s.io API
• Used by kubectl top and by the HPA and VPA

Without it the HPA has no data, and its targets show <unknown>.

Plain Kubernetes, and Amazon EKS itself, do not include the Metrics Server by default. But if you created your cluster with a recent eksctl (v0.201.0 or later, as in this course), eksctl already installed it as an EKS add-on. Check before installing anything:

kubectl top nodes
kubectl get deployment metrics-server -n kube-system

If kubectl top nodes prints CPU and memory per node, you are ready. If it says Metrics API not available, install it as an add-on (preferred on EKS):

eksctl create addon --name metrics-server --cluster telusko-learning --region ap-south-1

The Metrics Server is for autoscaling, not monitoring. It keeps no history. For graphs and alerts over time you use Prometheus and Grafana, which come later in Kubernetes Monitoring and Installing Prometheus.

Try It Yourself

1. Run kubectl top nodes and kubectl top pods -A on your cluster. Which namespace uses the most memory?
2. Run eksctl get addon --cluster telusko-learning --region ap-south-1 and check whether metrics-server is listed.
3. For each of these, choose horizontal or vertical scaling and explain why: a Spring Boot REST API, a single-instance PostgreSQL database, a nightly report job.
4. Your HPA wants 10 pods, but only 6 are Running and 4 are Pending. What is the likely reason, and which kind of autoscaler fixes it?

Official references

• Kubernetes: Autoscaling Workloads
• Kubernetes: Horizontal Pod Autoscaling
• Kubernetes: Resource metrics pipeline
• Amazon EKS: View resource usage with the Kubernetes Metrics Server

Written By: Shramik Masti