Horizontal Scaling with HPA on a Single Node: Honest Limits

The HorizontalPodAutoscaler (HPA) automatically adjusts the replica count of a Deployment based on observed metrics like CPU utilization. It is the classic "scale out during load, scale in during quiet" control loop. On a single node the loop works exactly as designed, but the outcomes are capped by what one node can hold. Understanding those honest limits prevents expecting magic from a single box.

How HPA works

HPA watches a metric (usually CPU average) against a target, then computes the desired replica count as current usage divided by target. If pods average 80% CPU and you set a 50% target, it scales roughly from 2 to 4 replicas. It only works when the metrics server is installed, because it needs per-pod metrics.

Creating the metric prerequisites

First ensure the metrics server is running, then create an HPA for a Deployment that already declares requests (HPA needs requests to compute utilization).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Applying and generating load

Watch the HPA react by driving CPU up, then let it settle back down.

kubectl apply -f hpa.yaml
kubectl get hpa api-hpa
kubectl describe hpa api-hpa
# generate load from another pod, e.g.:
# kubectl run load --image=busybox -- sh -c "while true; do wget -q -O- http://api; done"
kubectl top pods

The single-node ceiling

Here is the honest part: HPA can only scale within what the node fit. maxReplicas of 6 means little if the node runs out of CPU or memory first, and scheduling new replicas fails once requests exceed node capacity. It also cannot scale across nodes you do not have — a single node fault still takes everything down.

The real value of HPA here

On one node, HPA still delivers the core benefit: it keeps a Deployment matching load continuously, so you do not over- or under-provision by hand. It teaches the exact same control loop that multi-node clusters use, and it keeps pod count tight against demand.

Takeaway

HPA autoscales a Deployment on live utilization, but it can only scale within the capacity of the single node it runs on. Use it to learn the loop and right-size pod counts, and treat node capacity — not maxReplicas — as the real ceiling. The honest version of scaling on a single box is to keep workloads lean and monitor them. Try an HPA on a k3s cluster at Netbay and watch it react to load in real time — netbayhosts.in.