Why an HPA CPU Percentage Changes When the Request Denominator Changes

Establish what the supplied CPU percentage measures

A supplier's statement that an inference workload is at 50% CPU needs a denominator. For an HPA CPU Utilization target, that denominator is the relevant requested CPU. It is not the CPU limit, the whole node's processor capacity or GPU utilization. A percentage from another dashboard needs its own definition before it can be compared.

Kubernetes expresses 1000m as 1 CPU, so 500m is 0.5 CPU. For one container using 250m against a 500m request, the request-relative calculation is 100 x 250 / 500 = 50%. Usage of 750m against that request gives 150%. Exceeding 100% of a request does not by itself show that a CPU limit was exceeded; requests and limits are different quantities.

The Metrics API reports CPU usage as an average rate over a measurement window. Ask for the measured objects and interval alongside the requests that apply to them. This article uses archived Kubernetes v1.34 documentation and tagged v1.34.0 controller code to explain the calculation, with ordinary container-level requests and no Pod-level resource budgets or init containers. It interprets supplied evidence rather than prescribing an operating configuration.

References: [KA1][KU1][KM1][KR1][RC1]

HPA-61: two 500m requests produce a basic count of four

HPA-61 is an invented comparison with two current replicas, each represented by one Ready Pod containing one application container. Each container requests 500m CPU. Their supplied CPU usage is 250m and 750m over the same observation window. Stipulate complete valid metrics, readiness throughout the relevant period, one CPU Utilization metric, a 50% target and nonbinding replica bounds and scaling policies. These are explanatory inputs, not recommended settings or an actual scaling run.

The first Pod's utilization is 100 x 250 / 500 = 50%. The second's is 100 x 750 / 500 = 150%. Because the requests are equal, their arithmetic mean is (50 + 150) / 2 = 100%. The total calculation agrees: 100 x (250m + 750m) / (500m + 500m) = 100%.

The documented basic recommendation rounds up current replicas multiplied by current metric divided by target metric. Here that is ceil(2 x 100 / 50) = 4. The 100 and 50 are both percentages on the same basis, so their ratio is two. Four is the basic desired replica count under the supplied assumptions.

References: [KH1][KU1][KR1]

Change only the denominator and the basic count becomes two

Now compare a separate hypothetical snapshot in which both application containers request 1000m. Keep the two current replicas, supplied usage of 250m and 750m, 50% utilization target and all other assumptions unchanged. This is an alternative input set, not an instruction to resize a running workload.

The percentages become 100 x 250 / 1000 = 25% and 100 x 750 / 1000 = 75%. Their equal-request mean is 50%. The basic recommendation is now ceil(2 x 50 / 50) = 2. Total measured CPU usage remains 250m + 750m = 1000m in both snapshots. Only the declared request denominator changed.

The target itself has a different CPU equivalent in each snapshot. Half of a 500m request is 250m; half of a 1000m request is 500m. Four replicas at a target-equivalent 250m each and two at a target-equivalent 500m each both account for 1000m. This explains the different arithmetic without assuming that the workload will redistribute evenly or achieve any particular throughput after scaling.

Equal requests make the simple mean valid here. The tagged v1.34.0 utilization helper actually divides summed matching usage by summed matching requests, with integer percentage arithmetic. For unequal requests, do not substitute an unweighted mean of individual Pod percentages. Establish the aggregation and population used by the supplied implementation.

References: [KU1][KR1]

Keep the Pod and named-container populations consistent

For the ordinary container-request scope used here, a Pod Resource CPU metric includes the Pod's container usage together. A ContainerResource metric instead tracks a named container across the target workload's Pods. An application-only numerator cannot be combined with a whole-Pod request denominator and still describe the same metric.

Consider another invented observation: an application container requests 500m and uses 400m; an ordinary logging companion requests 500m and uses 100m. Combined usage is 500m against combined requests of 1000m, giving 50%. The application alone is at 400m / 500m = 80%. Both percentages can correctly describe this same observation, but they answer different questions. The companion changes the aggregate denominator as well as its numerator.

Ask which workload the HPA targets, whether the metric is Resource or ContainerResource and, for the latter, which container name is tracked. The v1.34 HPA guide states that Pods lacking the named container are ignored and the recommendation is recalculated. A container-specific metric therefore also needs evidence of which Pods actually contribute.

References: [KH1][KR1][KA1]

A CPU quantity target has a different comparison basis

An HPA CPU AverageValue target compares average CPU usage with a target quantity. It does not divide that usage by CPU requests. A target expressed in milliCPU must therefore be read as a quantity, rather than silently converted into a utilization percentage.

In both HPA-61 snapshots, average supplied usage is (250m + 750m) / 2 = 500m. If a separate hypothetical comparison used a 500m AverageValue target, its basic ratio would be 500m / 500m = 1, giving a count of two in either snapshot. Holding usage fixed while changing requests would not change this raw-value ratio. That is a statement about this metric calculation, not about the wider effects of changing resources.

A proposal that supplies only 'CPU target 50' leaves both the unit and target type unresolved. Ask for those definitions before comparing its scaling claim with another offer.

References: [KA1][KU1][KR1]

Separate the basic result from the controller's actual decision

The two-to-four calculation deliberately supplies valid measurements for every contributing Pod. Real evidence may contain missing metrics or CPU samples affected by startup and readiness. The replica calculator excludes or sets aside relevant Pods and can recompute the ratio conservatively; tolerance can also retain the current count. A displayed utilization value alone does not reconstruct all those decisions.

A missing required CPU request is a different defect from a missing usage sample. In the ordinary container-request utilization path, the request calculation can fail when a relevant container has no CPU request. There is then no valid request-relative recommendation from that metric to reproduce. Do not treat an undefined value as zero utilization.

After metric calculations, the controller applies replica bounds and the applicable scaling behavior, including rate limits and stabilization. With multiple metrics, another metric may drive the requested scale. Obtain the actual recommendation, conditions and applicable policy context when a supplier claims to demonstrate a controller outcome. A basic result of four is not evidence that a particular observed controller issued four.

References: [KR1][HC1][KA1]

Use the reconstructed percentage to assess the capacity claim

For HPA-61, the second snapshot supports a narrower conclusion than 'CPU demand fell by half': the same measured consumption occupies half the request-relative percentage after requests double. A buyer comparing the two offers should retain the absolute usage values, request values, target definition, included containers and measurement interval together. Otherwise a resource-declaration difference can be mistaken for an application improvement.

Then distinguish the basic calculation, the actual desired replica count and the replicas available to serve. The request denominator establishes none of the available worker resources, successful application readiness or useful output at the required response time. Ask the platform supplier to connect those observations to the same workload and operating interval before treating a scaling percentage as delivered GPU capacity.

The related CPU request, limit and observed-usage article explains the separate placement and runtime resource questions. The inference replica-versus-node-autoscaling article explains the separate demand and worker-provisioning loops. Use those owners when the comparison reaches their boundaries; this calculation resolves what the CPU scaling input means.

References: [KA1]

Scope physical installation only after the equipment decision

A different HPA percentage does not establish that another physical server is needed. If the platform team's separately selected capacity plan does require equipment installation, Leviathan's Complete Physical Infrastructure Deployment service covers agreed physical stages such as receiving, rack integration, onsite installation, cabling and handoff records.

Use the related service and project inquiry to share a nonconfidential equipment list, quantities, site, rack and IT connection requirements, and the team receiving the physical handoff. The inquiry concerns the physical scope and availability. Autoscaler administration and application performance assessment remain with the appointed platform team.

References: [L1]