About the Autoscaling / KEDA Config Builder
Autoscaling configuration is where two independent decisions get conflated: how many replicas to run, and how much each replica may consume. A HorizontalPodAutoscaler adjusts the first; requests and limits govern the second. Get them out of step and the autoscaler makes decisions on numbers that do not reflect reality.
The dependency people miss is that CPU-based horizontal autoscaling is a percentage of the CPU request. If a Deployment has no CPU request, the utilisation figure is undefined and the autoscaler cannot function at all — it simply reports unknown and never scales.
The second is that scaling up and scaling down want different speeds. Scaling up should be quick, because the cost of being slow is dropped requests. Scaling down should be slow and heavily damped, because the cost of being quick is flapping — removing capacity just before the next traffic peak and paying the cold-start cost repeatedly.
Frequently asked questions
Why does my HPA report unknown for current metrics?
Two usual causes. Either metrics-server is not installed or not reporting, so there is no data at all, or the target pods have no CPU request set. Utilisation is expressed as a percentage of the request, so with no request there is no denominator and the value is undefined. Both fail the same way and produce an autoscaler that never acts.
What utilisation target should I set?
Lower than feels intuitive. A target of 80 percent leaves very little headroom for the time it takes to notice load, schedule a pod, pull an image, and pass readiness — which is often a minute or more. Something in the 50 to 70 percent range is a common starting point for a service with meaningful start-up time, and higher is reasonable for one that starts instantly.
How do I stop the autoscaler from flapping?
Use the scaling behaviour fields to make the two directions asymmetric. Give scale-down a long stabilisation window, several minutes at least, so it acts on a sustained decline rather than a dip, and cap how much it may remove per step. Leave scale-up responsive. Most flapping is a scale-down that is too eager rather than a scale-up that is too aggressive.
Should I use HPA or VPA?
HPA for anything that scales horizontally, which is most stateless services. VPA suits workloads that cannot be replicated usefully, and is genuinely valuable in recommendation mode for discovering what requests should be. Do not run both on CPU or memory for the same workload — they fight, since one changes the replica count while the other changes the per-pod request the first is measuring against.
Can I scale on something other than CPU?
Yes, and usually you should. CPU is a poor proxy for load in I/O-bound services. Custom and external metrics let you scale on queue depth, requests per second, or connection count, which correspond much more directly to whether users are waiting. Queue depth is the clearest signal for worker pools; KEDA is the common way to wire it up.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.