Kubernetes HPA Resource Metric Scaling

Kubernetes HPA Resource Metric Scaling is the specific configuration and mechanics of using the Resource metric type — CPU and memory — as the signal driving Horizontal Pod Autoscaler decisions, the most common and most straightforward HPA metric source because it requires no additional metrics infrastructure beyond the standard metrics-server, but which carries its own subtleties around how utilization is calculated and aggregated.

How Resource Metrics Are Sourced

The Metrics Server Dependency

Resource-based HPA scaling depends on the metrics-server being deployed in the cluster, which collects CPU and memory usage from every node's kubelet (via the Summary API) and exposes it through the metrics.k8s.io aggregated API that the HPA controller queries.

kubectl get apiservices | grep metrics.k8s.io
kubectl top pods -n payments

Aggregation Across Container and Pod

For a multi-container pod, resource metrics are aggregated across all containers by default when using the Resource type, summing each container's usage and comparing against the sum of each container's corresponding resource request; this can be undesirable when a sidecar's resource profile differs substantially from the main application container, which is where the ContainerResource metric type becomes useful instead.

Utilization Versus AverageValue Targets

Utilization: Relative to Requests

target.type: Utilization expresses the target as a percentage of the pod's configured resource request, meaning the same percentage target produces different absolute thresholds for differently-sized pods — a pod requesting 500m CPU at 70% utilization targets 350m, while a pod requesting 2 CPU at 70% targets 1.4 CPU.

metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 70

AverageValue: An Absolute Threshold

target.type: AverageValue expresses the target as an absolute quantity per pod, independent of whatever resource request is configured, useful when the meaningful threshold is a fixed value (a specific memory ceiling in megabytes, for instance) rather than a proportion of an often-approximate request value.

metrics:
- type: Resource
  resource:
    name: memory
    target:
      type: AverageValue
      averageValue: 400Mi

The Dependency on Accurate Resource Requests

Utilization Targets Require Meaningful Requests

Because Utilization targets are computed relative to the pod's resource request, an inaccurate or placeholder request value (set far higher or lower than actual typical usage) directly distorts the utilization percentage the HPA observes, causing scaling decisions that do not reflect genuine capacity pressure.

Coordinating With Vertical Pod Autoscaler

Running a Vertical Pod Autoscaler alongside a CPU-utilization-based HPA on the same resource dimension creates a feedback loop, since the VPA changing the pod's CPU request directly changes the denominator of the HPA's utilization calculation — a common reason to separate VPA and HPA to different resource dimensions (VPA managing memory, HPA managing CPU-based replica count, for example) when both are needed on the same workload.

Memory as a Scaling Signal: Special Considerations

Memory Does Not Reliably Decrease Under Load Reduction

Unlike CPU, a process's memory usage often does not decrease simply because load decreases (due to caching, memory pooling, or garbage collection behavior specific to the runtime), meaning memory-based HPA scale-down can behave less responsively than CPU-based scale-down even when actual demand has genuinely dropped.

Choosing Between CPU and Memory as the Primary Signal

For most request-driven web workloads, CPU utilization tracks load more directly and responsively than memory, making it the more common primary scaling signal, while memory-based scaling is more often used as a secondary metric or for workloads (such as certain caching or batch-processing systems) where memory pressure is the genuine bottleneck.

Practical Configuration Guidance

Setting Realistic Targets

Choosing a target utilization with meaningful headroom below 100% — commonly in the 60-80% range — accounts for the delay inherent in the HPA's control loop, ensuring new capacity comes online before existing pods are saturated rather than only after they are already at their limit.

Validating Against Observed Baseline Usage

Before relying on a resource-metric HPA configuration in production, comparing the configured target against actual observed utilization patterns (via kubectl top or a monitoring dashboard) over a representative period confirms the target reflects real workload behavior rather than an assumption made without reference to actual usage data.