A fully utilized node turns each extra HPA replica into a Pending pod

The Karpenter number comes from a comparison against the classic Cluster Autoscaler, which scales predefined node groups. Karpenter instead calls the cloud API for the pods the scheduler could not place and picks the most cost-effective instance type that fits them, according to the dev.to guide ^[12]. The utilization gain transfers only where node groups are coarse enough to waste capacity and pod shapes varied enough that a per-pod instance choice beats a fixed one. Consolidation of underutilized nodes is how the slack comes back, and the guide describes it as aggressive ^[12], so the workloads have to tolerate eviction. A cluster running one pod shape on a well-matched instance type has less slack to recover.

The failure that costs the most to debug is the HPA/VPA death spiral, and it is division. Both tools read the same CPU metric. VPA lowers the request from historical data, and HPA then compares the same absolute usage against a smaller request, gets a higher percentage, and scales out ^[10]. Take a pod using 300 millicores against a 500m request: HPA sees 60 percent. Trim the request to 400m and the same 300m reads 75 percent, past a 70 percent target ^[2]. The guide's remedy is to split the signals: HPA on custom metrics such as RPS or queue depth, VPA on CPU and memory only, or VPA in Off mode where it writes recommendations and does not act ^[11]. Off mode leaves a human as the actuator. KEDA sits at the same level as HPA and reads queue depth; a misconfigured resource request is not something it can correct ^[3].

Scale-down timing is the other default worth reading before the incident rather than during it. HPA scales up aggressively and also scales down quickly, which can flap, and the guide recommends a stabilizationWindowSeconds of 300 for scale-down, a ceiling of 10 percent pod reduction per minute, and no delay on scale-up ^[5]. In wall-clock terms, taking 10 percent off the current count each minute, a 100-replica deployment needs seven steps to get under 50, and the five-minute window runs first, so about twelve minutes pass between the load dropping and the fleet halving ^[1].

Scale-to-zero is the capability KEDA adds over the classic HPA: more than 60 native scalers, including Kafka consumer lag and Redis list length, and a deployment that goes to zero replicas when no events are pending and back up when they arrive ^[6]. The KEDA HTTP Add-on buffers incoming requests and brings pods out of standby ^[8]. The guide's own pairings are conservative. A stateless, latency-sensitive web API gets HPA on CPU plus an RPS custom metric, VPA in Off mode, and Karpenter with a mix of Spot and On-Demand instances ^[15]. Queue-backed background workers get KEDA with scale-to-zero on Spot ^[16].