The Horizontal Pod Autoscaler cannot compute scaling decisions because containers are missing CPU resource requests. HPA calculates utilization as (current_usage / requested_resources), making resource requests mandatory.
The Horizontal Pod Autoscaler (HPA) cannot compute scaling decisions because one or more containers in your pods are missing CPU resource requests in their specification. HPA calculates utilization as a percentage by dividing the current CPU usage by the requested CPU amount (utilization = current_usage / requested_resources). Without a defined CPU request, this calculation is impossible, and the HPA cannot determine whether to scale up or down. This error typically appears as 'FailedGetResourceMetric' events on your HPA object, with messages like 'the HPA was unable to compute the replica count: failed to get cpu utilization: missing request for cpu'. The HPA controller requires CPU requests to be specified on every container in every pod that it manages, including sidecar containers that may be automatically injected by service meshes like Istio or Linkerd.
Describe the HPA resource to see the exact error:
kubectl describe hpa <hpa-name> -n <namespace>Look for 'Warning' events mentioning 'FailedGetResourceMetric' or 'missing request for cpu'. Note the target deployment/statefulset name.
The Metrics Server must be installed for HPA to retrieve CPU metrics:
kubectl get deployment metrics-server -n kube-system
kubectl top nodes # Should return CPU/memory data
kubectl top pods -n <namespace> # Should return pod metricsIf metrics-server is missing, install it:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yamlList all containers, including any sidecar containers that may be auto-injected:
kubectl get deployment <deployment-name> -n <namespace> -o yaml | grep -A 5 'containers:'Service meshes (Istio, Linkerd) may inject sidecars automatically. Check:
kubectl describe deployment <deployment-name> -n <namespace>Look at the 'Containers' section to see all container names, including injected ones.
Update your Deployment manifest to include resource requests for all containers:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: my-app
image: my-app:latest
resources:
requests:
cpu: "250m" # Required for HPA CPU-based scaling
memory: "64Mi"
limits:
cpu: "500m"
memory: "128Mi"Choose appropriate values based on your application's typical usage (e.g., 250m = 0.25 CPU cores).
Deploy the changes to your cluster:
kubectl apply -f deployment.yamlVerify the rollout completed:
kubectl rollout status deployment/<deployment-name> -n <namespace>Wait for all old pods to terminate and new pods with resource requests to start.
Check that HPA can now retrieve CPU metrics:
kubectl get hpa <hpa-name> -n <namespace>You should see the 'TARGETS' column showing something like '50%/80%' instead of '<unknown>'. Describe the HPA:
kubectl describe hpa <hpa-name> -n <namespace>Look for events without 'FailedGetResourceMetric' errors. Test scaling by generating load and monitor:
kubectl get hpa <hpa-name> -n <namespace> --watchHPA requires CPU requests to calculate the target number of replicas using the formula: desiredReplicas = ceil(currentCPUUsage / targetCPUUtilizationPercentage). Resource limits are NOT used in this calculation—only requests matter.
When using autoscaling/v1 with targetCPUUtilizationPercentage (deprecated), upgrading to autoscaling/v2 with the 'metrics' array provides more flexibility, allowing scaling on multiple metrics simultaneously.
For multi-container pods, each container must have its own resource requests; Kubernetes aggregates them for HPA calculations. Service mesh sidecar injection is a common source of this error—ensure your service mesh configuration includes resource requests for injected containers.
On Kubernetes 1.30+, HPA supports container-level resource metrics, enabling fine-grained scaling based on individual container CPU usage rather than pod-level aggregates.
For cost optimization, set conservative CPU requests (e.g., 100m-500m) proportional to your application's baseline usage; oversized requests reduce HPA aggressiveness and waste cluster capacity.
Failed to connect to server: connection refused (HTTP/2)
How to fix "HTTP/2 connection refused" error in Kubernetes
error: invalid configuration
How to fix "error: invalid configuration" in Kubernetes
etcdserver: cluster ID mismatch
How to fix "etcdserver: cluster ID mismatch" in Kubernetes
running with swap on is not supported
How to fix "running with swap on is not supported" in kubeadm
ReplicaSet has timed out progressing
How to fix "ReplicaSet has timed out progressing" in Kubernetes