Why might an HPA be unable to scale a Deployment even with plenty of spare CPU capacity on existing nodes?

The HPA has ceilings other than node capacity: maxReplicas on the HPA itself is the most common one (the HPA is working correctly but has hit its configured limit), followed by a ResourceQuota on the namespace capping total resource consumption, or a PodDisruptionBudget indirectly interacting with scaling in edge cases — check kubectl describe hpa and the namespace's ResourceQuota before assuming a scheduling or node-capacity problem.

Node capacity is only one of several independent ceilings that can cap scaling — the HPA's own maxReplicas, and namespace-level ResourceQuota/LimitRange policies, each operate at a different layer and can each independently block further scaling regardless of what the underlying nodes can actually support.

• The HPA's target metric (e.g., CPU utilization) is clearly above the configured target threshold.
• The replica count is not increasing despite this.
• No pods are stuck Pending, and nodes have visibly available capacity — ruling out the "not enough nodes" explanation directly.

• The HPA has hit its own configured maxReplicas ceiling — a deliberate, correct limit rather than a malfunction.
• A ResourceQuota on the namespace caps total CPU/memory or pod count, and the Deployment is already at that quota's limit even though the underlying nodes have spare capacity.
• A LimitRange in the namespace enforces a maximum resource request per pod that conflicts with what new pods would need, causing new pod creation attempts to fail admission (distinct from failing scheduling).

Check the HPA's maxReplicas against its current replica count first: kubectl get hpa <name> shows both directly — if they're equal, this fully explains the symptom and isn't a bug at all, just a capacity-planning ceiling that needs a deliberate decision to raise (or not).

Check the namespace's ResourceQuota: kubectl get resourcequota -n <namespace> — if a quota on requests.cpu, requests.memory, or pods is already at its limit, new pods (whether from the HPA or otherwise) will fail to be created even though the cluster's nodes have room, because the quota is enforced independently of actual node capacity.

Check for admission failures distinct from scheduling failures: kubectl get events -n <namespace> for FailedCreate events on the Deployment's ReplicaSet — a quota or LimitRange violation shows up as a pod creation failure at admission time, which looks different from (and happens before) a scheduling failure, and won't produce the Pending-with-FailedScheduling pattern people often expect to see when capacity is the issue.

Confirm the HPA's own status doesn't already explain it: kubectl describe hpa — the ScalingLimited condition being True with a reason referencing TooManyReplicas directly confirms the maxReplicas ceiling is the active constraint, which is the fastest way to rule this in or out.

If it's maxReplicas, this is a capacity-planning decision — raise it if the workload has legitimately outgrown its configured ceiling and the infrastructure can support more replicas, or leave it if the ceiling is intentional and the real fix is addressing the underlying load (caching, a more efficient code path) rather than scaling further. If it's a ResourceQuota or LimitRange, that's a namespace-level policy decision — raise the quota if the workload's growth is legitimate and expected, in coordination with whoever owns that policy for the namespace.

• Node-level spare capacity doesn't rule out other, independent ceilings — maxReplicas, ResourceQuota, and LimitRange all operate at different layers and can each independently block scaling.
• kubectl describe hpa's ScalingLimited condition directly confirms whether maxReplicas is the active constraint.
• A ResourceQuota-driven block shows up as a pod creation/admission failure, not a scheduling failure — check FailedCreate events, not just FailedScheduling.
• Distinguishing which specific ceiling is active determines who needs to make the next decision (capacity planning for maxReplicas, namespace policy owner for quota).

• Kubernetes: Resource Quotas
• Kubernetes: Horizontal Pod Autoscaling