What is Kubernetes Autoscaling? HPA, VPA & Cluster Autoscaler, Benefits & Use Cases

A Kubernetes application that runs comfortably on four Pods at 10 a.m. may need twelve during a product launch, while another service may keep requesting 4 GiB of memory but use barely half of it. Both create different scaling problems.

Kubernetes autoscaling helps teams respond without permanently provisioning for peak demand. HPA can add or remove Pods as workload pressure changes, while VPA adjusts CPU and memory requests when individual Pods are poorly sized.

But even correctly scaled Pods cannot serve traffic if the cluster has no worker-node capacity to run them.

For DevOps and platform teams, the real question is not whether to autoscale. It is whether the workload needs more Pods, better-sized Pods, additional node capacity, or a combination.

What is Kubernetes Autoscaling?

Kubernetes autoscaling automatically adjusts workload or infrastructure capacity according to changing resource requirements. There are three main levels of scaling:

• Horizontal scaling: Changes the number of Pods.
• Vertical scaling: Changes CPU and memory resources assigned to individual Pods.
• Node scaling: Changes the amount of worker-node capacity available to the cluster.

For application workloads, HPA and VPA are the two primary mechanisms teams need to understand.

HPA responds to changing workload pressure by adding or removing replicas. VPA analyzes resource consumption and recommends or applies changes to Pod CPU and memory requests.

Node autoscaling operates underneath these workload-level mechanisms. Cluster Autoscaler is one implementation that can add worker nodes when unschedulable Pods would fit on new nodes from an eligible node group.

For the broader concepts behind these mechanisms, see our guide on scalability and elasticity.

The Kubernetes autoscaling documentation describes horizontal, vertical, and node-level scaling as separate but complementary mechanisms.

Comparing Horizontal Pod Autoscaling vs Vertical Pod Autoscaling

HPA and VPA both automate capacity management, but they solve different problems.

The easiest way to think about the difference is this:

HPA solves throughput pressure by adding or removing Pods. VPA improves resource efficiency by changing the size of those Pods. Kubernetes treats horizontal and vertical scaling as distinct workload-scaling mechanisms.

What is a Horizontal Pod Autoscaler?

HPA changes the replica count of workloads such as Deployments and StatefulSets.

Suppose an API runs with four Pods. Traffic rises and its configured metric exceeds the target. HPA can increase replicas so work is distributed across more Pods. When demand falls, it can scale them again.

Kubernetes runs HPA as a periodic control loop. By default, it evaluates metrics every 15 seconds, although administrators can change this interval.

How HPA calculates replicas?

At a simplified level:

Desired replicas = Current replicas × Current metric / Target metric

If five Pods are running at twice the desired metric level:

5 × 2 = 10 Pods

The simplified calculation points to approximately ten replicas. Kubernetes also considers factors such as missing metrics, Pod readiness, and tolerance before scaling.

What should HPA scale on?

HPA can work with several metric types.

1. Resource metrics
   • CPU
   • memory
2. Custom metrics
   • requests per second
   • application latency
   • active sessions
3. External metrics
   • queue depth
   • Kafka lag
   • external monitoring signals

For utilization-based scaling, Kubernetes calculates usage relative to configured resource requests. That makes accurate requests important. HPA can also evaluate multiple metrics. When several metrics are configured, Kubernetes calculates a desired replica count for each and uses the highest recommendation.

Best practice: Scale on real workload demand

CPU is useful only when it correlates with actual workload pressure.

For example:

• scale APIs using request rate or latency where appropriate
• scale workers using queue depth
• scale streaming consumers using lag
• scale inference services using concurrency, queue depth, or pending requests

The best metric is the one that tells you when the application genuinely needs additional serving capacity.

HPA configuration example

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

The values above are illustrative. Production thresholds should come from load testing, startup time, workload behavior, and service-level requirements.

HPA scale-up and scale-down behavior

HPA should not change replicas every time a metric fluctuates slightly. Kubernetes provides stabilization windows and scaling policies to control how aggressively replicas change. The default HPA scale-down stabilization window is 300 seconds, or five minutes.

Best practice: scale up quickly enough to protect application performance, but scale down more carefully to avoid repeated cold starts and replica flapping.

For applications with long startup times, configure readiness behavior carefully so new Pods are not treated as available before they can actually serve traffic.

Can HPA scale to zero?

Yes, under specific conditions. Kubernetes v1.37 promoted HPA scale-to-zero to Beta and enabled it by default. Workloads using suitable object or external metrics can configure minReplicas: 0.

This is particularly useful for queue consumers, asynchronous workers, batch processing, and workloads where idle resources are expensive.

However, scale-to-zero introduces cold-start delay. Kubernetes Services also do not buffer requests while no Pods are ready, so synchronous request-driven applications need an appropriate activation or buffering strategy.

For a closer look at when scale-to-zero favors a serverless model over managed Kubernetes, see our guide on serverless vs managed Kubernetes for AI workloads.

When HPA works best?

HPA is a strong fit when adding replicas increases throughput, such as:

• stateless APIs
• web applications
• microservices
• queue workers
• inference endpoints

Its main failure modes are poor metric selection, missing resource requests, slow Pod startup, restrictive maxReplicas, and insufficient node capacity.

Adding replicas also changes how traffic is spread across them. See our comparison of auto scaling vs load balancing for how the two work together.

What is a Vertical Pod Autoscaler?

VPA changes the CPU and memory requested by individual Pods.

Instead of asking whether Kubernetes needs more replicas, VPA asks whether each Pod is sized correctly.

If a workload requests far more memory than it uses, capacity remains reserved unnecessarily. Overprovisioned requests are one of the most common cloud waste patterns. See our guide on cost optimisation strategies in cloud computing. If requests are too low, the workload may run close to its limits or require more resources.

VPA analyzes usage and recommends more appropriate CPU and memory values.

How VPA determines resource needs?

VPA has three core components:

• Recommender: calculates CPU and memory recommendations from resource usage
• Updater: determines when recommendations should be applied
• Admission Controller: applies recommended resources when Pods are created

Unlike HPA, VPA may need to be installed separately if the Kubernetes platform does not provide it. VPA also needs a resource metrics source, such as Metrics Server, to evaluate CPU and memory consumption.

VPA update modes

VPA supports several update strategies.

• Off: Generates recommendations without applying them.
• Initial: Applies recommendations when Pods are created.
• Recreate: Can evict and recreate Pods when their resource requests need adjustment.
• InPlaceOrRecreate: Attempts an in-place change where supported, with recreation as a fallback.
• InPlace: Current VPA documentation also describes an in-place-only mode with specific VPA and Kubernetes version requirements.

The older Auto mode has been deprecated since VPA 1.4.0 and behaves as an alias for Recreate.

What about in-place pod resizing?

Kubernetes in-place Pod resizing became stable in v1.35. CPU and memory requests and limits can be changed on running containers without necessarily recreating the Pod.

VPA integration with in-place resize depends on the VPA mode and implementation version, so teams should verify their specific VPA release before designing around non-disruptive resizing.

Best practice: Start VPA with recommendations

For critical workloads, start VPA in Off mode. Use its recommendations to answer:

• Are CPU requests consistently too high?
• Are Pods frequently under-sized?
• Does resource usage change predictably?
• What minimum and maximum resources are operationally safe?

Then define minAllowed and maxAllowed guardrails before enabling automated changes. If using eviction-based VPA modes, also review PodDisruptionBudgets so rightsizing does not create unnecessary service disruption.

VPA configuration example

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: webapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  updatePolicy:
    updateMode: "Off"

Starting with Off mode lets teams inspect recommendations before VPA changes production resource requests.

When VPA works best?

VPA is most useful for workloads where per-Pod resource sizing is the real bottleneck. Examples include:

• JVM applications
• memory-heavy services
• background processors
• internal applications
• workloads with difficult-to-predict CPU or memory needs

Its main risks are overly aggressive recommendations, larger Pods becoming difficult to schedule, disruption from recreation, and interactions with HPA.

HPA vs VPA: When Should You Use Each?

The easiest way to choose is to identify the bottleneck.

Choose HPA when:

• workload volume changes significantly
• adding replicas increases throughput
• demand can be represented by traffic, queue, latency, or similar metrics

Choose VPA when:

• traffic is relatively stable but Pods are over- or under-sized
• CPU or memory requests are difficult to estimate
• improving per-Pod resource efficiency matters more than adding replicas

Consider both when:

• workload demand changes
• per-Pod resource needs also change

Simple rule: Use HPA when demand changes. Use VPA when Pod sizing is wrong. Use Cluster Autoscaler when eligible node groups need to expand to accommodate unschedulable Pods.

Can HPA and VPA Work Together?

Yes, but their responsibilities should be separated carefully. Utilization-based HPA calculates CPU usage relative to the CPU request. VPA can change that request. Consider this illustrative example:

Before VPA

• CPU usage: 500m
• CPU request: 500m
• HPA utilization: 100%

After VPA increases the request

• CPU usage: 500m
• CPU request: 1000m
• HPA utilization: 50%

The application is using the same CPU, but HPA now sees a different utilization percentage. That can create a feedback loop:

VPA changes requests → HPA sees different utilization → HPA changes replicas → workload per Pod changes

To reduce this risk, start with VPA in Off mode and let HPA use a workload-demand metric such as requests per second or queue depth.

If HPA scales on CPU utilization, avoid letting VPA dynamically modify the same CPU requests without testing the interaction. Another option is to limit VPA to memory recommendations or changes while HPA uses CPU utilization, where that separation suits the workload.

Monitor both controllers after enabling automation.

What Is Kubernetes Cluster Autoscaler?

Cluster Autoscaler (CA) manages worker-node capacity rather than Pod replica counts or per-Pod CPU and memory requests. It watches for Pods that the scheduler cannot place and checks whether adding nodes from a configured, eligible node group would make them schedulable.

Unlike HPA, Cluster Autoscaler does not scale an application simply because CPU usage rises. It responds to scheduling pressure and relies on node-group configuration, resource requests and the cloud provider’s ability to supply capacity.

How Does Cluster Autoscaler Work With HPA and VPA?

Consider an API running four Pods before a product launch. As traffic rises, HPA requests twelve replicas, but the existing nodes can accommodate only eight. Four new Pods remain Pending because the scheduler has insufficient capacity.

Cluster Autoscaler evaluates those unschedulable Pods and, if a suitable node group can expand, requests more worker nodes. Once the nodes are ready and registered, Kubernetes can schedule the waiting Pods.

This sequence is illustrative; actual scale-out time depends on node provisioning and application startup.

Demand increases → HPA adds replicas → Some Pods cannot be scheduled → Cluster Autoscaler adds eligible nodes → Pods become Ready

When demand falls, HPA can reduce replica counts. Cluster Autoscaler may then consolidate underutilized nodes, provided their remaining Pods can be moved safely.

When Does Cluster Autoscaler Not Add Nodes?

Pending Pods do not always trigger scale-out. Cluster Autoscaler may be unable to help when:

Node groups have reached their maximum size.

Cloud quotas or inventory are exhausted.

A Pod requests more resources than any available node type provides.

Scheduling rules such as affinity, taints or storage placement cannot be satisfied.

Scale-down also requires care. PodDisruptionBudgets, local storage and restrictive placement rules may prevent a node from being removed.

Configure node-group minimum and maximum sizes, protect critical workloads and monitor unschedulable Pods and node provisioning failures.

When VPA raises a Pod’s resource requests and that Pod must be rescheduled, node capacity can also become a bottleneck. Cluster Autoscaler helps only when an eligible node group can accommodate the larger Pod.

Cluster Autoscaler and Karpenter are different implementations of node autoscaling. Availability and supported configuration differ by Kubernetes platform, so verify which option your provider offers.

Accurate CPU and memory requests matter across all three layers because they influence HPA utilization, VPA recommendations and scheduler placement.

What is Kubernetes Cluster Autoscaler?

Cluster Autoscaler (CA) manages worker-node capacity rather than Pod replica counts or per-Pod CPU and memory requests. It watches for Pods that the scheduler cannot place and checks whether adding nodes from a configured, eligible node group would make them schedulable.

Unlike HPA, Cluster Autoscaler does not scale an application simply because CPU usage rises. It responds to scheduling pressure and relies on node-group configuration, resource requests and the cloud provider’s ability to supply capacity.

How Does Cluster Autoscaler Work With HPA and VPA?

Consider an API running four Pods before a product launch. As traffic rises, HPA requests twelve replicas, but the existing nodes can accommodate only eight. Four new Pods remain Pending because the scheduler has insufficient capacity.

Cluster Autoscaler evaluates those unschedulable Pods and, if a suitable node group can expand, requests more worker nodes. Once the nodes are ready and registered, Kubernetes can schedule the waiting Pods.

This sequence is illustrative; actual scale-out time depends on node provisioning and application startup.

Demand increases → HPA adds replicas → Some Pods cannot be scheduled → Cluster Autoscaler adds eligible nodes → Pods become Ready

When demand falls, HPA can reduce replica counts. Cluster Autoscaler may then consolidate underutilized nodes, provided their remaining Pods can be moved safely.

When Does Cluster Autoscaler Not Add Nodes?

Pending Pods do not always trigger scale-out. Cluster Autoscaler may be unable to help when:

• Node groups have reached their maximum size.
• Cloud quotas or inventory are exhausted.
• A Pod requests more resources than any available node type provides.
• Scheduling rules such as affinity, taints or storage placement cannot be satisfied.

Scale-down also requires care. PodDisruptionBudgets, local storage and restrictive placement rules may prevent a node from being removed. Configure node-group minimum and maximum sizes, protect critical workloads and monitor unschedulable Pods and node provisioning failures.

When VPA raises a Pod’s resource requests and that Pod must be rescheduled, node capacity can also become a bottleneck. Cluster Autoscaler helps only when an eligible node group can accommodate the larger Pod.

Cluster Autoscaler and Karpenter are different implementations of node autoscaling. Availability and supported configuration differ by Kubernetes platform, so verify which option your provider offers.

Accurate CPU and memory requests matter across all three layers because they influence HPA utilization, VPA recommendations and scheduler placement.

Where Does KEDA Fit?

KEDA extends horizontal autoscaling to event-driven workloads. It is useful when demand is better represented by signals such as:

• Kafka lag
• RabbitMQ queue depth
• message backlog
• asynchronous job count

For supported workloads, KEDA provides event-driven metrics that HPA can use to change replica counts. Use KEDA when the event itself reflects demand better than CPU utilization.

HPA vs VPA by Workload

For GPU inference, HPA can scale replicas using queue depth, concurrent requests, latency, or other application metrics. VPA primarily addresses CPU and memory sizing. It should not be treated as a GPU-count autoscaler.

Raw GPU utilization alone is not always the best scaling signal. A highly utilized GPU may be operating efficiently. Queue depth, concurrency, latency, and throughput often provide better context for deciding when another inference replica is required.

For scheduling and scaling GPU workloads beyond a single node, see our guide on multi-GPU orchestration on Kubernetes.

How to Build an Effective Kubernetes Autoscaling Strategy?

A reliable strategy connects application demand, Pod sizing and node capacity. Configure these layers in sequence rather than enabling every autoscaler at once.

1. Set Performance and Availability TargetsDefine acceptable latency, error rates, queue wait time and startup delay. Identify traffic peaks and workloads that cannot tolerate a cold start.
2. Establish Realistic Pod RequestsLoad-test CPU and memory needs, then use VPA in Off mode to compare its recommendations with actual consumption. Right-sized requests help the scheduler place Pods and reduce unnecessary node provisioning.
3. Configure HPA for DemandSelect CPU only if it tracks useful work; otherwise consider request rate, concurrency or queue depth. Define minReplicas, maxReplicas and scaling behavior using measured workload limits.
4. Connect HPA to Cluster CapacityEnable a supported node autoscaler for the relevant node groups. Check instance sizes, scaling bounds, quotas, node labels, taints, GPU availability where applicable and the time required for a new node to become Ready.
5. Separate HPA and VPA ResponsibilitiesAvoid coupling utilization-based HPA to the same resource requests that VPA changes automatically. Start with VPA recommendations or choose distinct metrics and resource controls before using both controllers on the same workload.
6. Test the Entire Scaling CycleSimulate a sudden traffic spike, watch replicas become Pending and Ready, and confirm node provisioning works. Then test scale-down, PodDisruptionBudgets, service latency and the cost of idle capacity.

Practical example:

For a latency-sensitive API, a sensible starting point might be HPA for request pressure, VPA in recommendation-only mode for CPU and memory rightsizing, and Cluster Autoscaler for additional nodes.

Keep enough baseline replicas and node headroom to absorb traffic while new capacity starts.

Bottom line: The goal is not to maximize scaling activity. It is to meet service-level targets with the fewest safe resources across Pods and nodes.

Kubernetes Autoscaling Best Practices

1. Identify the Bottleneck FirstDo not choose an autoscaler before identifying whether the problem is demand, Pod sizing, or node capacity.
2. Use Metrics That Represent Real PressureCPU is not automatically the right HPA signal. Choose the metric that best represents why users or workloads need more capacity.
3. Keep Resource Requests AccurateRequests influence HPA utilization calculations, scheduling, VPA decisions, and node autoscaling.
4. Add GuardrailsSet sensible HPA minimum and maximum replicas. Define VPA minimum and maximum resources before enabling automated changes. Set node-group scaling limits and use PodDisruptionBudgets where appropriate to protect availability during consolidation.
5. Design Around Startup TimePods, applications, model servers, and worker nodes do not become ready instantly. Maintain baseline capacity where the workload cannot tolerate provisioning delay.
6. Test the Entire Scaling PathTest demand spikes, scale-down, Pending Pods, resource changes, node shortages, and controller interactions. Monitor:
   • demand metrics
   • desired and Ready replicas
   • CPU/memory requests
   • VPA recommendations
   • Pending Pods
   • node capacity
   • application latency and errors

HPA vs VPA: Which Should You Use?

• Choose HPA when increased demand can be handled by adding replicas.
• Choose VPA when individual Pods are consistently over-sized, under-sized, or difficult to size correctly.
• Use both when demand and per-Pod resource requirements vary, but give each controller a distinct responsibility.
• Add Cluster Autoscaler when new Pods cannot fit on current nodes and a compatible node group can expand to accommodate them.

The most effective Kubernetes autoscaling architecture is rarely about choosing one controller everywhere. It is about assigning the right scaling mechanism to the right bottleneck.

Scale Kubernetes Smarter with AceCloud

Kubernetes autoscaling works best when each layer has a clear role. HPA responds to changing workload demand, VPA improves per-Pod resource sizing, and Cluster Autoscaler supplies eligible worker-node capacity when new Pods cannot be scheduled.

The challenge is making these mechanisms work together without creating unnecessary cost, scheduling pressure or unstable scaling behavior.

With AceCloud Managed Kubernetes, teams can run scalable containerized, data and AI workloads across flexible CPU and GPU infrastructure while aligning application-level autoscaling with the capacity underneath it.

If you are still comparing platforms, see our guide to the best managed Kubernetes providers. Planning a new Kubernetes environment or optimizing an existing cluster? Book a free consultation with AceCloud to review your workload metrics, resource sizing, node capacity, and autoscaling strategy.

Author Popular Post

Carolyn Weitz

author

Carolyn began her cloud career at a fast-growing SaaS company, where she led the migration from on-prem infrastructure to a fully containerized, cloud-native architecture using Kubernetes. Since then, she has worked with a range of companies from early-stage startups to global enterprises helping them implement best practices in cloud operations, infrastructure automation, and container orchestration. Her technical expertise spans across AWS, Azure, and GCP, with a focus on building scalable IaaS environments and streamlining CI/CD pipelines. Carolyn is also a frequent contributor to cloud-native open-source communities and enjoys mentoring aspiring engineers in the Kubernetes ecosystem.

• 7 Pillars Of Cost Optimization with AWS
• IaaS Architecture and Components – A 2025 Guide for Businesses
• 5 Key Benefits of Modernizing on AWS Cloud
• Cloud Computing Matrix: Public, Private, and Hybrid Cloud Architectures
• OpenStack: The Catalyst of the Public Cloud Market