Introduction

When a Horizontal Pod Autoscaler says it cannot find the target resource, the problem is usually not the scaling math. It is almost always a mismatch between the HPA's scaleTargetRef and the actual workload object, or a namespace and API-version mismatch that prevents the controller from resolving the target.

How HPA finds what to scale

An HPA does not scale pods directly. It targets another Kubernetes resource such as a Deployment, StatefulSet, or ReplicaSet through scaleTargetRef.

A typical HPA looks like this:

1apiVersion: autoscaling/v2
2kind: HorizontalPodAutoscaler
3metadata:
4  name: web-hpa
5  namespace: app
6spec:
7  scaleTargetRef:
8    apiVersion: apps/v1
9    kind: Deployment
10    name: web
11  minReplicas: 2
12  maxReplicas: 10
13  metrics:
14    - type: Resource
15      resource:
16        name: cpu
17        target:
18          type: Utilization
19          averageUtilization: 70

If apps/v1, Deployment, or web do not match a real object in the same namespace, the HPA cannot find its target.

The most common causes

The most common issue is a wrong name in scaleTargetRef. A close second is using the wrong kind or apiVersion.

Another frequent cause is namespace confusion. The HPA and the target workload must exist in the same namespace. An HPA in default will not scale a deployment in app.

A less obvious problem is targeting a resource type that does not expose the scale subresource the way HPA expects.

Basic checks to run

Start by describing the HPA and confirming the target workload exists exactly as referenced.

kubectl get hpa -n app
kubectl describe hpa web-hpa -n app
kubectl get deployment web -n app

If the deployment is missing, misnamed, or in a different namespace, the error is already explained.

You should also inspect the rendered YAML, especially if Helm or Kustomize is generating names dynamically.

kubectl get hpa web-hpa -n app -o yaml
kubectl get deployment web -n app -o yaml

API version and kind must match the target

The HPA resource itself may use autoscaling/v2, but the target resource reference must use the target's API group and version.

For a modern deployment, that is usually:

• 'apiVersion: apps/v1'
• 'kind: Deployment'

If you accidentally reference an obsolete API version or the wrong kind, the HPA controller may fail to resolve the scale target even when the workload name looks correct.

Metrics problems are different from target-not-found problems

People often blame the metrics server whenever HPA misbehaves. Metrics availability matters for scaling decisions, but it is a separate problem from target resolution.

If the HPA cannot find the target deployment at all, fixing metrics will not help. Metrics-server issues usually appear after the target is found, when the controller tries to read CPU or custom metrics.

That distinction helps narrow troubleshooting quickly.

A minimal working pair

Here is a matching deployment and HPA in the same namespace.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5  namespace: app
6spec:
7  replicas: 2
8  selector:
9    matchLabels:
10      app: web
11  template:
12    metadata:
13      labels:
14        app: web
15    spec:
16      containers:
17        - name: web
18          image: nginx:1.27
19          resources:
20            requests:
21              cpu: 100m

The HPA shown earlier can target this deployment because the name, kind, API version, and namespace all line up.

Common Pitfalls

A common mistake is creating the deployment in one namespace and the HPA in another. HPA target lookup is namespace-scoped.

Another issue is letting templating tools rename the deployment while the HPA still points at the old hard-coded name.

It is also easy to conflate target-not-found errors with metrics errors. If the controller cannot resolve scaleTargetRef, check the workload reference first and the metrics stack second.

Summary

• HPA scales another workload through scaleTargetRef, not pods directly.
• The target name, kind, API version, and namespace must match a real scalable resource.
• Use kubectl describe hpa and kubectl get on the workload to verify the reference.
• Metrics-server issues are separate from target-resolution issues.
• Most fixes come down to correcting the HPA YAML, not changing scaling thresholds.