An autoscaler needs a usable signal
A HorizontalPodAutoscaler changes a workload's desired replica count using configured metrics. If the metric is unavailable or cannot be interpreted for the target, increasing maxReplicas does not repair the measurement path. Separate failure to calculate a scaling decision from failure to schedule or start the replicas that decision requested.
For CPU utilization expressed relative to requested resources, the relevant resource requests are part of the measurement contract. A missing request can prevent a meaningful calculation for the affected Pods. This guide investigates that contract and the metric pipeline rather than selecting a universal utilization percentage.
Setup: identify the target and metric type
Record the HPA object, workload, namespace, API version and configured metric source. Resource metrics, custom metrics and external metrics have different collection dependencies. Confirm that the HPA targets the intended controller and that no other process continually rewrites the replica count.
Read-oriented starting commands are:
kubectl describe hpa example-api -n example
kubectl top pods -n example
kubectl get deployment example-api -n example -o yaml
Inspect requests in the workload's Pod template and the actual running Pods. A pending rollout can leave old and new resource configurations present simultaneously. Keep the HPA conditions and events with the timestamped metric observations.
Illustrative incident: a request change breaks the utilization contract
In this illustrative example, a deployment update removes CPU requests from a container while an HPA still uses CPU utilization. The service receives traffic, but the autoscaler reports an unusable metric. Raising the maximum replica count does not restore the missing denominator.
The team compares the HPA's expected signal with the new Pod specification and metrics availability. It reviews appropriate requests based on workload behavior, then rolls out the corrected resource contract through a representative pilot. The scenario is fictional and contains no claimed capacity improvement.
Troubleshooting: locate calculation versus capacity failure
| Observation | Evidence | Boundary |
|---|---|---|
| CPU target is unknown | Requests, metric availability and HPA conditions | Can utilization be calculated? |
| Pod metrics are unavailable | Metrics API and collector health | Is the resource-metric pipeline healthy? |
| Desired replicas rise but Pods remain Pending | Scheduler events and available resources | Is eligible cluster capacity available? |
| Replica count oscillates | Workload demand and scaling behavior | Are windows and stabilization appropriate? |
A successful kubectl top result does not prove that an unrelated custom-metric adapter works. Likewise, a correct replica calculation does not prove new Pods become ready. Follow the metric source actually configured on the HPA and the resulting workload state.
Correct the signal with a workload-aware rollout
Repair the identified request, collector, adapter or target configuration. Define requests from representative measurements and application needs rather than choosing tiny values merely to drive a high utilization percentage. Resource changes also affect scheduling and must fit the cluster's capacity model.
Review scaling bounds and behavior only after the signal is usable. Account for startup, dependency capacity and the effect of scaling on a database or downstream API. Preserve the previous configuration and identify a safe operating replica count while the control loop is being repaired.
Verification, monitoring and SOP
Use an approved load exercise to verify available metrics, an explainable HPA decision, scheduled replicas and application readiness. Observe recovery as demand falls; success includes avoiding disruptive oscillation, not just adding Pods once.
Alert separately on prolonged metric unavailability, unavailable replicas and customer impact. An internal SLO can define scaling response under stated capacity and metric-freshness assumptions; an external SLA requires separate terms. The SOP should record the metric API, resource contract, workload owner, scaling bounds, test profile, rollback and escalation when the controller cannot make a safe decision.
See Clouvenix containers kubernetes for a reviewed implementation and operational handover.
Technical reference
Kubernetes Horizontal Pod Autoscaling, Kubernetes resource metrics pipeline. Reviewed 19 October 2026; use documentation for the installed product and release.