I keep things up

Anshul Singh Chauhan

Autoscaling reacts late. Jump the dial and watch latency climb before pods arrive.

Simulated Runs in your browser on the repo's real config. Assumptions are listed below, dated 2 Nov 2026.

This demo runs in your browser and needs JavaScript. The picture shows its resting state.

Pods, running copies of the app

  • Ready
  • Ready

Latency: how long a request waits, log scale

10

200: 2 pods' limit 600: 6 pods' limit

Jump past the first mark. Turn it slowly and the pods keep up.
Latency
21 ms
Ready pods
2 of 2
Timed out
0
New pods took
no climb yet
Peak latency
no climb yet
Simulated time
0 s
Clock speed
5× real time

Ready pods

A floor with six pod slots in a row, two of them holding ready pods, and an empty queue pad where traffic enters.A floor with six pod slots in a row, two of them holding ready pods, and an empty queue pad where traffic enters.

This picture shows the resting state. The pods list is live.

Steady. 2 pods are handling 10 requests a second.

What breaks here

  • The CPU target is measured against the 100m request, not the 500m limit. At target, six pods use 360m of a 3,000m combined limit, so the autoscaler runs out of pods long before they run out of headroom.
  • The readiness probe calls /ok, which doesn't check MongoDB. A pod can be Ready with the database down.

Assumptions

From the repo
Minimum 2 pods, maximum 6, CPU target 60%. CPU request 100m, limit 500m. Readiness probe on /ok: first check at 5 s, then every 5 s.
Kubernetes defaults
The controller runs every 15 s with a tolerance of 0.1. Scale-down waits 300 s. Scale-up adds the larger of 4 pods or 100% every 15 s. Pods not yet ready count as 0% on the way up.
Assumed, 2 Nov 2026
Metrics every 15 s, the value in metrics-server's shipped manifest. 5 ms of CPU per request, 20 ms base latency, 12 s for a container to serve, 30 s client timeout, 5m idle CPU, 1 s to create a replacement. MongoDB and node capacity aren't modelled. Latency values depend on these assumptions.