Kubernetes auto-scaling makes it possible to scale your application resource usage depending on load changes. It is no longer necessary to manually scale the application since it will be scaled depending on the metrics like CPU and memory usage.
There are two popular types of scaling that are Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA). In HPA, it is the number of pods which will be adjusted, while in VPA it is the amount of CPU and memory resources which will be allocated to the pods.
HPA vs VPA: What’s the Difference?
The Horizontal Pod Autoscaler (HPA) automatically adds or reduces the number of pods in terms of resource consumption or any other supported metrics. It helps in situations where the traffic to the application varies and hence the requirement of varying number of pods.
The Vertical Pod Autoscaler (VPA) scales the CPU and memory resources requested and limited by pods depending on their consumption. It helps in properly sizing the workload of an application.
To make it simple, HPA scales out by adjusting the number of pods, whereas VPA scales up/down by adjusting the resources of pods.
What Is Kubernetes Autoscaling?
Kubernetes autoscaling is the automated process of adjusting the compute resources allocated to your workloads based on real-time demand. Instead of manually tuning pod replicas or container resource limits, Kubernetes autoscaling lets the cluster respond dynamically to CPU usage, memory consumption, and custom metrics. There are three primary autoscaling mechanisms in Kubernetes: the Horizontal Pod Autoscaler (HPA), the Vertical Pod Autoscaler (VPA), and the Cluster Autoscaler. This guide focuses on HPA and VPA — the two most widely used pod-level autoscaling strategies.
What Is the Horizontal Pod Autoscaler (HPA)?
The Horizontal Pod Autoscaler automatically scales the number of pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics. The most common trigger is CPU utilization, but HPA also supports memory-based scaling and custom metrics via the Kubernetes Metrics API. HPA is best suited for stateless applications where spinning up additional identical pods distributes load effectively — think web servers, REST APIs, and event-driven consumers.
How HPA Works
The HPA controller runs a control loop every 15 seconds by default. It queries the Metrics Server — or a custom metrics adapter — to retrieve current resource utilization, compares it against the target threshold you define, and calculates the desired number of replicas. The formula works like this: take the current number of replicas, multiply it by the ratio of current metric value to desired metric value, and round up to the nearest whole number. If your target CPU utilization is 50% and your pods are running at 90%, HPA scales out by adding more replicas. If utilization drops well below the threshold, HPA scales back in — always respecting the minimum and maximum replica bounds you configure.
HPA continually tracks the resource utilization levels of the pods and then compares it with the target value set in the autoscaling settings. In case the resource usage goes above the target value, HPA is able to increase the number of replicas of the pods. If the usage falls below the target value, HPA is able to reduce the number of replicas.
CPU and memory are common resource types used by HPA, although there may be other available resources too, based on the Kubernetes monitoring.
Setting Up HPA in Kubernetes
Before configuring HPA, make sure the Kubernetes Metrics Server is installed in your cluster. You can deploy it by applying the official components manifest from the kubernetes-sigs metrics-server GitHub releases page.
Once the Metrics Server is running, deploy your application with clearly defined CPU resource requests — this is mandatory for HPA to function correctly because without them, the autoscaler has no baseline to measure utilization against. Your Deployment should specify a container image, CPU requests (for example, 100 millicores), and CPU limits (for example, 200 millicores). Once the Deployment is live, you create an HPA object that references it, sets a minimum of 2 replicas and a maximum of 10, and targets an average CPU utilization of 50%. Running kubectl get hpa lets you verify the autoscaler is active and observe its current state in real time.
Example: Kubernetes HPA Configuration
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
In this example, HPA maintains between 2 and 10 replicas of the web-app deployment. When the average CPU utilization reaches the target of 70%, Kubernetes can increase the number of replicas to handle additional workload. As demand decreases, HPA can scale the deployment back down while respecting the configured minimum and maximum replica limits.
HPA with Custom Metrics
Beyond CPU and memory, Kubernetes HPA supports scaling on custom metrics — such as requests per second, queue depth, or active database connections — through adapters like Prometheus Adapter or KEDA (Kubernetes Event-Driven Autoscaling). KEDA is particularly popular in 2026 for scaling workloads based on external event sources like Kafka topics, RabbitMQ queues, Azure Service Bus, and AWS SQS. This makes HPA with custom metrics the go-to Kubernetes autoscaling strategy for event-driven microservices. If you want to get hands-on with these tools in a structured environment, our DevOps Course covers Kubernetes autoscaling, KEDA, and real-world cluster management from the ground up.
What Is the Vertical Pod Autoscaler (VPA)?
The Vertical Pod Autoscaler automatically adjusts the CPU and memory requests and limits of containers within a pod — rather than changing the number of replicas. VPA is ideal for stateful workloads, batch jobs, and applications that cannot scale horizontally, such as single-instance databases or legacy monoliths running in containers. VPA observes historical and current resource consumption and recommends — or automatically applies — right-sized resource configurations, preventing both over-provisioning and out-of-memory (OOM) kills.
VPA Components
VPA consists of three main components. The Recommender continuously monitors resource usage and generates resource recommendations based on observed patterns. The Updater evicts pods that need to be restarted with new resource settings when live utilization drifts significantly from the recommendation.
The Admission Controller intercepts pod creation requests and mutates resource requests to match VPA recommendations before the pod even starts — meaning newly scheduled pods launch with correctly sized resources from the very first second.
Installing and Configuring VPA
VPA is not bundled with Kubernetes by default. You install it by cloning the official Kubernetes autoscaler repository from GitHub, navigating into the vertical-pod-autoscaler directory, and running the vpa-up shell script. Once installed, you create a VPA object targeting your Deployment.
The key field to configure is updateMode, which controls how aggressively VPA applies its recommendations. Setting it to Off means VPA only generates recommendations without touching any pods — ideal for auditing before you commit. Initial applies recommendations only at pod creation without evicting running pods. Auto applies recommendations dynamically and will evict pods when their resource usage drifts too far from the target. You also define minimum and maximum allowed resource bounds per container to keep VPA's adjustments within safe operational limits.
Kubernetes Autoscaling Best Practices in 2026
Always define resource requests and limits for every container — autoscaling breaks without them. Set conservative minimum replicas in HPA to maintain baseline availability during cold starts. Use VPA in Off mode first to collect recommendations before enabling Auto in production. Implement Pod Disruption Budgets alongside VPA to prevent all pods from being evicted simultaneously during updates.
Pair HPA with Cluster Autoscaler so that when HPA demands more pods than the current node pool can support, Cluster Autoscaler provisions new nodes automatically. Monitor autoscaling behavior with Prometheus and Grafana dashboards, tracking metrics like current replica counts, VPA status recommendations, and container OOM kill events.
Kubernetes Autoscaling for Cost Optimization
One of the most compelling reasons to implement Kubernetes autoscaling in 2026 is cloud cost reduction. Over-provisioned clusters are one of the biggest sources of wasted cloud spend across AWS EKS, Google GKE, and Azure AKS. VPA eliminates memory padding and CPU buffers that engineers add out of caution. HPA ensures you are not paying for idle pod replicas during off-peak hours.
When combined with spot or preemptible node pools managed by the Cluster Autoscaler, HPA and VPA together can cut Kubernetes infrastructure costs by 30–60% without sacrificing reliability or performance. Professionals who want to apply these cost-optimization strategies at scale will find our DevOps Training program practical, project-driven, and directly aligned with what the industry demands today.
Troubleshooting Common Autoscaling Issues
If HPA shows unknown for current metrics, the Metrics Server is either not installed or not yet ready — check its logs through kubectl in the kube-system namespace. If HPA is not scaling despite high CPU, verify that your pods have CPU resource requests defined. If VPA recommendations seem too aggressive, tighten the minimum and maximum allowed bounds in the VPA resource policy.
If pods are being OOM-killed after VPA applies recommendations, increase the maximum allowed memory or switch to Initial update mode to prevent live evictions until you have a better handle on actual consumption patterns.
Choosing between HPA and VPA depends on your application's workload and resource requirements. HPA is ideal for handling changing traffic by adjusting pod replicas, while VPA helps optimize CPU and memory allocation. Using the right autoscaling strategy can improve application performance and Kubernetes resource efficiency.
Conclusion
Kubernetes autoscaling with HPA and VPA is not just a technical convenience — it is a foundational pillar of production-grade Kubernetes cluster management, cloud cost optimization, and application reliability engineering. HPA handles scale-out for stateless workloads.
VPA handles right-sizing for resource-hungry or stateful containers. Together, they form a complete Kubernetes pod autoscaling strategy that keeps your applications fast, available, and economical. As AI-driven workloads, real-time data pipelines, and microservices architectures continue to grow in complexity through 2026 and beyond, mastering Kubernetes autoscaling will remain one of the highest-leverage skills in any cloud-native engineer's toolkit.
Frequently Asked Questions
What is the difference between HPA and VPA in Kubernetes?
HPA (Horizontal Pod Autoscaler) scales the number of pod replicas up or down based on CPU, memory, or custom metrics, making it ideal for stateless workloads. VPA (Vertical Pod Autoscaler) adjusts the resource requests and limits of existing pods, making it the right choice for stateful or singleton workloads that cannot scale horizontally.
Can HPA and VPA be used together in the same Kubernetes cluster?
Yes, HPA and VPA can coexist in the same cluster, but running both on the same Deployment using CPU as the metric causes conflicts since VPA alters the resource requests that HPA depends on. The safest approach is to configure HPA on custom metrics like requests-per-second while letting VPA handle CPU and memory right-sizing independently.
Does Kubernetes autoscaling work without the Metrics Server installed?
No — the Metrics Server is a prerequisite for HPA to function, as it provides the real-time CPU and memory utilization data that the autoscaler queries every 15 seconds. Without it, HPA will show unknown for current metric values and will not scale your pods regardless of actual load.
Is Kubernetes autoscaling suitable for reducing cloud infrastructure costs?
Absolutely — when configured correctly, HPA prevents you from paying for idle pod replicas during low-traffic periods, while VPA eliminates over-provisioned CPU and memory buffers that silently inflate your bill. Combined with Cluster Autoscaler and spot node pools on AWS EKS, Google GKE, or Azure AKS, autoscaling can reduce Kubernetes infrastructure costs by 30–60%.
