Kubernetes Autoscaling: HPA, VPA and 7 Production Checks

Kubernetes autoscaling works when demand, workload resources and infrastructure capacity are understood together. Increasing the replica count cannot repair a saturated database, and increasing memory requests cannot create free space on an already-full node.

This guide separates HPA, VPA and node scaling, then shows how to test the complete sequence from demand to usable capacity. The examples are intended for a lab Deployment called web-api in an existing demo namespace; the values are illustrative, not universal production defaults.

Technical review: 30 October 2026. Test configuration examples against your installed product version before using them in production.

Kubernetes autoscaling has three separate decisions

• HPA: change the number of workload replicas.
• VPA: recommend or adjust container resources through a separately installed component.
• Node scaling: provide infrastructure on which Pods can be scheduled.

These are related control loops, not substitutes for one another. An HPA can request eight replicas while only four are ready. The rest may be Pending because of resource requests, placement constraints or unavailable node capacity.

For a capacity review, follow the actual delivery path: metric rises, controller recommends capacity, scheduler places Pods, containers start, readiness succeeds and traffic reaches them. Each stage needs an observable signal and an expected delay.

A Kubernetes autoscaling review should distinguish demand for replicas from demand for larger resource requests.

Choose a metric that represents work

A CPU utilisation target is relative to CPU requests. A container using 200m with a 400m request is at 50% utilisation for that calculation. Requests that do not reflect the workload can therefore create confusing scaling behaviour.

HPA can use resource, custom or external metrics when the relevant APIs and adapters are available. CPU is a useful starting point for some services; queue depth or request demand may better represent others. Verify that the signal changes before user-facing performance becomes unacceptable.

Do not interpret a memory peak as a simple instruction to add replicas. Investigate leaks, heap settings, caches and workload distribution. A separate observability baseline helps distinguish a scaling problem from an application defect.

An autoscaling/v2 HPA example

Before applying this example, confirm that the Deployment exists, has realistic CPU requests for the containers being measured, and that resource metrics are available. A CPU request of 250m would make a 65% target approximately 162.5m per measured container, before the controller’s averaging and readiness handling.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api
  namespace: demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

The five-minute scale-down stabilisation window reduces immediate shrinkage after a temporary dip. The policy limits the reduction rate; it does not guarantee a particular application response time. Choose the minimum, maximum and policy from load tests and recovery requirements.

Test Kubernetes autoscaling with a representative traffic pattern and observe the downstream dependencies.

kubectl -n demo top pods
kubectl -n demo get hpa web-api
kubectl -n demo describe hpa web-api
kubectl -n demo get pods -o wide
kubectl -n demo get events --sort-by=.metadata.creationTimestamp

Use the official HPA walkthrough to build a controlled test. Run load only against a system you own and have capacity to test; observe latency and errors alongside replica counts.

Evaluate VPA before enabling automatic resource changes

VPA is not part of the core HPA API and must be installed separately. Start with updateMode: "Off" to inspect recommendations. Current upstream guidance deprecates Auto; explicit modes include Initial, Recreate and, where supported, InPlaceOrRecreate.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-api-recommendations
  namespace: demo
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  updatePolicy:
    updateMode: "Off"

Recommendation-only mode leaves the workload’s resources unchanged. Review recommendations over representative traffic and startup periods. In-place behaviour depends on the installed VPA release, Kubernetes features and provider support; do not promise zero restarts simply because a mode name includes “InPlace.”

Be cautious when VPA changes CPU requests while HPA scales on CPU utilisation: the denominator changes. A common evaluation approach is recommendation-only VPA plus HPA, or horizontal scaling on a carefully designed non-resource demand signal.

Seven production checks before raising maxReplicas

1. Replica safety: confirm the service can handle multiple instances without duplicate scheduled work or unsafe local state.
2. Startup: measure image pull, initialisation, readiness and warm-up time.
3. Dependencies: calculate maximum database and upstream connections across all replicas.
4. Infrastructure: check node capacity, quotas, subnet addresses and placement constraints.
5. Downscale: test termination handling and completion of in-flight requests.
6. Delivery: prevent a GitOps or deployment process from repeatedly resetting controller-managed replicas.
7. Cost and rollback: define a budget boundary, an owner and the conditions for reverting a change.

Consider eight replicas with a maximum pool of twenty database connections each: the theoretical pool total is 160, before other services are counted. That arithmetic does not prove all connections will be used, but it exposes a dependency limit worth discussing before a traffic test.

Record the limits of Kubernetes autoscaling so a saturated database is not mistaken for a replica-count problem.

Troubleshoot the stage that is failing

Capture the test timeline instead of changing several thresholds at once. A single before-and-after graph of replicas leaves too much unexplained; correlate ready capacity, response time, errors and the signal used by the autoscaler.

Kubernetes autoscaling: frequently asked questions

Does HPA add nodes?

No. Node scaling is a separate infrastructure capability. Ensure your platform can supply capacity for the Pods HPA requests.

Can I use HPA and VPA together?

Yes, with a deliberate design. Avoid independent resource changes that destabilise the same utilisation-based scaling signal.

Does autoscaling fix OOMKilled Pods?

Not automatically. Investigate the memory limit, application footprint, leaks and traffic distribution before selecting a resource or scaling change.

Official references

• Kubernetes HPA concepts
• Kubernetes VPA concepts and modes
• Kubernetes node autoscaling

Related reading: Kubernetes CronJobs: Scheduling, Retries and Troubleshooting