Recent observations show that a single deployment can be simultaneously driven by four distinct autoscaling mechanisms: the Horizontal Pod Autoscaler (HPA), the Vertical Pod Autoscaler (VPA), KEDA, and Karpenter. Each controller reads a different signal, writes to the same API fields, and makes scaling decisions in isolation. The result is a classic Kubernetes autoscaling conflict that manifests as contradictory replica counts, mismatched resource requests, and unnecessary node provisioning. Practitioners who build AI pipelines, run platform services, or secure production clusters must understand why this conflict matters and how to mitigate it.
Why Independent Autoscalers Clash
All four controllers operate on the same objects (.spec.replicas and .resources.requests) but assume exclusive authority. HPA bases its replica target on CPU usage expressed as a percentage of the declared request. VPA adjusts the request values based on historical consumption. KEDA scales replicas according to external queue depth. Karpenter adds nodes to satisfy the aggregate declared requests of pending pods. Because each loop runs concurrently, they never see the adjustments made by the others, leading to feedback loops that destabilize the workload.
Four Common Failure Modes
- Denominator collapse (HPA vs. VPA): VPA reduces CPU requests, shrinking the denominator used by HPA. A modest traffic increase then appears as a higher utilization percentage, prompting HPA to add more pods. Those pods further lower per‑pod usage, causing VPA to shrink requests again, creating a spiral of tiny pods and ever‑increasing replica counts.
- Multi‑writer race (HPA vs. KEDA): KEDA reacts to a Kafka lag spike by scaling the deployment up, while HPA sees low CPU usage on the newly added I/O‑heavy pods and scales the deployment back down. The API server records alternating scale events, and the application never clears the backlog.
- GitOps drift ping‑pong: When HPA expands replicas during a traffic surge, a GitOps engine such as Argo CD flags the live state as out‑of‑sync. If auto‑sync is enabled, the GitOps process reverts the replica count to the baseline stored in Git, starving the service at the peak of demand.
- Multiplier effect at the node layer: Karpenter provisions nodes based on declared pod requests, not actual consumption. Over‑provisioned requests from the previous loops cause Karpenter to launch extra instances, inflating cloud spend while cluster‑level CPU utilization remains low.
Path Toward an Autonomous Unified Autoscaler
The source argues that the current model answers narrow questions—"what should my replica count be?" or "what request size should I use?"—instead of solving the broader optimization problem: delivering latency SLOs at minimal cost. A unified autoscaler would need five capabilities:
- Ingest a combined signal set (CPU, memory, queue depth, latency, node pricing, IaC manifests).
- Compute a joint action vector that simultaneously decides replica count and pod resource requests.
- Submit reasoned changes back to the cluster in a single transaction, avoiding multi‑writer races.
- Synchronize with GitOps by generating automated pull requests that reflect the new desired state.
- Continuously evaluate cost versus performance to keep the system within SLO targets.
Such a controller would replace the reactive, single‑metric heuristics with a coordinated, cost‑aware decision engine.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Engineers should audit their clusters for overlapping autoscaling controllers and assess whether the observed scaling behavior matches expectations. If multiple controllers are active on the same workload, consider consolidating to a single solution or implementing guardrails (e.g., disabling HPA when VPA is active, or configuring GitOps to ignore replica drift). Monitoring should include not only pod‑level metrics but also node‑level utilization to spot the multiplier effect described above. Finally, keep an eye on emerging projects that aim to provide a unified autoscaling plane, as they may offer a more stable and cost‑effective alternative to the current fragmented approach.
