Kubernetes Auto-Scaling Load Test Template

Does the autoscaler add pods before users notice?

An HPA scales on a metric that lags reality: CPU averaged over a window, then a scale-up decision, then image pull, startup and readiness. During that gap the existing pods take the load. This template ramps slowly enough for the autoscaler to react and steeply enough to expose the gap, and reads response time per step so you can see the exact minutes where pods were behind demand.

Configuration

Run this templateOpens the cloud test form with these values filled in. Free plan runs it at the free user limit; sign in or create a free account first.

The button prefills users, duration and the 15-step ramp. Add the endpoints and start; keep `kubectl get hpa -w` and `kubectl get pods -w` open in another window and note the timestamps of each scale event.

What to read in the results

• Response time per step against pod count. The Timeline tab at 1-minute granularity shows p95 per minute. Line it up with the HPA events: a bump that starts when CPU crosses the target and ends when new pods pass readiness is the scale-up lag, in minutes.
• Errors during scale events. 5xx or connection errors that coincide with new pods joining are readiness probes passing too early, or old pods being terminated with requests in flight (missing preStop or too short a grace period).
• The hold phase. Flat p95 means the cluster settled. A sawtooth means scale-down removes pods that the next minute needs; lengthen the stabilisation window.

Pass/fail thresholds for this template

Set them on the test and rerun after tuning the HPA target, the stabilisation window or the readiness probe; the Trend tab shows which change helped.

The same scenario as a k6 script

As a k6 script the ramp is 15 one-minute stages. Point it at endpoints that do work; a health check will not move the CPU metric.

import http from 'k6/http';
import { check, sleep } from 'k6';

const steps = [];
for (let i = 1; i <= 15; i++) steps.push({ duration: '1m', target: i * 100 });
steps.push({ duration: '15m', target: 1500 });

export const options = {
  stages: steps,
  thresholds: { http_req_duration: ['p(95)<800'], http_req_failed: ['rate<0.005'] },
};

export default function () {
  const res = http.get('https://app.example.com/api/render?report=monthly&rows=500');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1 + Math.random());
}

When to run it

• After changing HPA settings targets, min/max replicas, stabilisation windows.
• After changing the image or startup path a slower startup widens the gap.
• Before a known traffic ramp a launch, a marketing push, the morning peak.

FAQ on Kubernetes autoscaling load tests

The response time bump is two minutes long. Is that bad?

It is the scale-up lag: metric window plus decision plus pod startup. Two minutes is typical for CPU-based HPA. Shorten it by lowering the CPU target, scaling on request rate (KEDA or custom metrics), or keeping a warm buffer of replicas.

Should I test the cluster autoscaler too?

If pods can end up Pending for lack of nodes, yes: set the HPA max above what the current nodes fit and watch for Pending pods during the ramp. Node provisioning adds minutes to the gap.

Why not a fast spike?

A spike tests whether you have a warm buffer; this test measures the autoscaler. Run the spike separately (see the game launch template) once autoscaling behaves.

Can I run it against production?

At a quiet hour, with a target below the level you expect to break something, yes; the point is to observe scaling events, not to reach failure.