Skip to main content

Scale a workload to zero

Inspect 1.36

Scaling to zero removes a workload’s pods while it sits idle and starts them again on the first request. Paired with the cluster autoscaler, once an hcloud node has no pods left, the autoscaler removes it and you stop paying for it. This suits workloads that are idle much of the day, such as staging environments and internal tools.

Why the HPA cannot get there

An HPA can’t scale to zero. Its floor is one replica and it measures running pods, so reaching zero needs a separate component in front to catch the first request and cold-start a pod.

Wake on a request with Knative

If the workload serves HTTP, put Knative Serving in front of it. When traffic stops, Knative scales the workload to zero; when a request arrives, its activator holds the connection open, starts a pod from zero, and serves it the moment the pod is ready. Knative is not part of the platform, so install it and run the workload as a Knative Service.

Note

The cost of scaling a workload to zero pods is the cold start. The first request after an idle stretch waits for a pod to be pulled and started, which can be a few seconds. Fine for an internal tool; wrong for a latency-sensitive public endpoint. Keep a warm floor of one replica for anything a user waits on directly.

Drop the node too

Freeing the pods is only half the saving; the bill stops when the node itself goes away. Pair scale-to-zero with the : once the last pod leaves a burst node, the autoscaler removes it.

Verify it sleeps and wakes

Stop sending traffic and watch kubectl get deploy <name> -w. After the scale-down grace period the replicas fall to 0/0. Send one request and keep watching: the count climbs back to 1/1, and the delay you feel is the cold start. If it never reaches zero, the grace period is still holding a pod open.