Horizontal Pod Autoscaler HPA 2025 Updates

This guide explains the Kubernetes Horizontal Pod Autoscaler (HPA), how it works, and how to configure it both imperatively and declaratively. It preserves the original examples and diagrams while improving clarity and flow for hands‑on use in a cluster.

Manual horizontal scaling

Suppose you are running an application backed by this Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: nginx
        resources:
          requests:
            cpu: "250m"
          limits:
            cpu: "500m"

Key points:

The container requests 250m CPU and has a limit of 500m.
HPA computes percentage utilization against the CPU requests (not limits). The scheduler also uses requests for pod placement.
Limits cap actual CPU usage but do not change how HPA evaluates utilization.

If you were scaling manually, you’d monitor pod usage (requires a metrics provider such as metrics-server) and then run kubectl scale when you need more capacity:

# View pod resource usage (metrics-server must be installed)
kubectl top pod my-app-pod

# Manually scale the deployment
kubectl scale deployment my-app --replicas=3

Example scenario:

Pod CPU usage: 450m
CPU request: 250m
Average utilization = 450m / 250m * 100% = 180%

If your target threshold were 50%, you would manually increase replicas to add capacity. Manual scaling is reactive and error‑prone—HPA automates this process.

What HPA does

The Horizontal Pod Autoscaler continuously monitors one or more metrics (CPU, memory, custom, or external metrics) and adjusts the number of pods in a Deployment, ReplicaSet, or StatefulSet. When metrics exceed configured targets, HPA increases replicas; when metrics fall, HPA reduces replicas—always honoring the min/max bounds you configure.

An infographic titled "Horizontal Pod Autoscaler (HPA)" showing a central HPA block linked to four feature boxes: "Observes metrics," "Adds pods," "Balances thresholds," and "Tracks multiple metrics." The layout uses dashed arrows and blue gradient panels on a dark background.

How HPA computes desired replicas

When using resource metrics with averageUtilization, HPA scales proportionally using this formula: desiredReplicas = ceil(currentReplicas * (currentAverageUtilization / targetUtilization)) Using the example above:

currentReplicas = 1
currentAverageUtilization = 180%
targetUtilization = 50%

desiredReplicas = ceil(1 * (180 / 50)) = ceil(3.6) = 4 So HPA would scale the deployment from 1 to 4 replicas to meet the configured target.

Imperative (kubectl) example

Create an HPA quickly using kubectl autoscale. This sets a CPU target of 50% with min/max replicas 1 and 10:

kubectl autoscale deployment my-app \
  --cpu-percent=50 --min=1 --max=10

kubectl get hpa
# Example output:
# NAME     REFERENCE         TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
# my-app   Deployment/my-app 180%/50%   1         10        1          1m

Notes:

TARGETS displays the current average utilization versus the configured target (current/target).
HPA will not scale above maxReplicas or below minReplicas.
To remove the HPA:

kubectl delete hpa my-app

Declarative HPA (YAML)

Define HPA in YAML using the autoscaling API (example uses autoscaling/v2, which supports multiple metric types):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Important implementation notes

HPA is part of the Kubernetes control plane and does not require a separate control-plane installation. However, HPA depends on a metrics provider (commonly metrics-server) or an adapter to supply current metrics. Ensure metrics-server or a compatible metrics adapter is running in your cluster for resource-based autoscaling to function.

HPA evaluates utilization against the container requests, not the CPU limits. If your pods have low requests relative to limits, HPA may scale aggressively because utilization percentages are computed from the request value.

Metrics and adapters

HPA can consume multiple metric sources and adapters to support advanced scaling scenarios:

Metric source	Use case	Examples
Resource metrics	CPU and memory from the cluster	`metrics-server` exposes `pods` and `nodes` metrics
Custom metrics	In-cluster app metrics (per-pod)	Custom metrics adapter (e.g., Prometheus Adapter)
External metrics	External systems or SaaS metrics	Datadog, Dynatrace, or queue length from cloud services

Adapters and external providers enable use cases such as scaling on queue length, external API throughput, or APM-derived signals. Configuring and operating these adapters is specific to each adapter and is outside the scope of this guide. The diagram below illustrates how metrics flow from various sources into HPA using metrics-server and adapters:

A diagram of a Kubernetes metrics pipeline showing HPA → Metrics Server → Custom Metrics Adapter → External Adapter, with metrics forwarded to Datadog and Dynatrace.

Summary

Use HPA to automatically scale Deployments, ReplicaSets, and StatefulSets based on metrics.
HPA evaluates metrics (commonly CPU/memory) against configured targets and adjusts replicas automatically within configured min/max bounds.
Ensure a metrics provider (for resource metrics) or the appropriate adapter (for custom/external metrics) is installed and configured in the cluster.
Monitor both requests and limits in your Pod specs to avoid unexpected scaling behavior.

Links and references

Kubernetes HPA documentation: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
metrics-server: https://github.com/kubernetes-sigs/metrics-server
Prometheus Adapter: https://github.com/kubernetes-sigs/prometheus-adapter
Datadog: https://www.datadoghq.com/
Dynatrace: https://www.dynatrace.com/

Try these examples in a test cluster to see how HPA responds to workload changes.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Horizontal Pod Autoscaler HPA 2025 Updates

Manual horizontal scaling

What HPA does

How HPA computes desired replicas

Imperative (kubectl) example

Declarative HPA (YAML)

Important implementation notes

Metrics and adapters

Summary

Watch Video

Practice Lab

​Manual horizontal scaling

​What HPA does

​How HPA computes desired replicas

​Imperative (kubectl) example

​Declarative HPA (YAML)

​Important implementation notes

​Metrics and adapters

​Summary

Watch Video

Practice Lab

Manual horizontal scaling

What HPA does

How HPA computes desired replicas

Imperative (kubectl) example

Declarative HPA (YAML)

Important implementation notes

Metrics and adapters

Summary