This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/sig autoscaling

Since the spec is using a scaleTargetRef and not a labelSelector, I think it makes sense to scope the HPA to the deployment and not to the set of pods matching the labelSelector of that deployment. This is what is done in the VPA and also in the Deployment Controller.

This being said the documentation clearly says:

The controller manager finds the target resource defined by the scaleTargetRef, then selects the pods based on the target resource's .spec.selector labels,...

So fixing this would be a change in behaviour as discussed in the SIG. Does it really makes sense to have deployment having overlapping selectors? It is technically possible yes, but is it a good practice... probably not! This leads to so many problems, like overlapping PDBs, that result in 500 when you try to evict pods. If there is a real need for doing labelSelector to define the scope of the HPA, maybe next HPA spec should explicitly introduce that capability by offering in the spec both scaleTargetRef and labelSelector (only one can be used at a time). I am clearly not in favour of such a change, but if the need really exists that would be a clear way to address it.

I would be in favour of giving a mean to fix this issue to align the behaviour of all the controllers (VPA, Deployment). If there is a consensus for fixing, to protect backward compatibility, maybe we can propose to pilot the activation of the fix at controller (or HPA object) level using a new parameter (or annotation on the HPA). Thanks to that new parameter the user can decide on the behaviour: "strict scaleTargetRef using ownerRef" versus "labelSelector"

I think it makes sense to scope the HPA to the deployment and not to the set of pods matching the labelSelector of that deployment. This is what is done in the VPA and also in the Deployment Controller.

As an end user, I think this is what one would "expect" when starting out on Kubernetes.
I also really like the consistency that this would add.

I think we might need a KEP to change the way that Kubernetes interprets the spec of a HorizontalPodAutoscaler.

VerticalPodAutoscaler is not part of the formal Kubernetes API (yet), whereas HorizontalPodAutoscaler already is.

Just ran into the same issue I believe.

We have following situation:

• one namespace app
• two deployments in the same namespace app-frontend and app-backend
• both deployments, replicasets and their pods have overlapping labels, like this as everything belongs sort of together:
  -- app: app
• in the same time, they also have a different label per deployment/replica set/pod like this (just fyi):
  -- Deployment 1: app-role: app-frontend
  -- Deployment 2: app-role: app-backend
• both have the following thing in their Deployment spec:

  selector:
    matchLabels:
      app: app

• they have the following default replica count:
  -- app-frontend: 2
  -- app-backend: 1
• and the following resource requests / limits (cpu) per Pod:
  -- app-frontend: 200m / 1000m
  -- app-backend: 600m / 1200m

The backend one is performing some heavy load operations in the background, causing nearly 100% utilization of that single pod in the deployment all the time (that is fine for us), while the frontend one is having near 0 load, as it is produces only load on a per request basis.

We have configured an HPA that has scaleTargetRef like this:

scaleTargetRef:
    kind: Deployment
    name: app-frontend
    apiVersion: apps/v1

So my assumption would be that metrics defined like this:

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

would only apply to that single app-frontend Deployment as this is also the target.
From what I observe, the metrics seem to also consider the heavy-load app-backend Pods, therefore leading to undesired upscaling operations on the app-frontend Deployment. This is in my opinion nowhere documented. I have tried to find explanations for the observations I have made , but haven't found anything. Additionally, I think, this is also undesired behaviour...

btw. scaling itself happens only on the app-frontend, but not on app-backend, which is fine.

What are the label selectors for each deployment?

I've updated my description.

After adjusting the matchLabels selectors there accordingly, it seems to work properly actually.

same here, when create different deployment with same label and change hpa to select different deployment, hpa reporting usage is wrong(targets always same), after make sure reference target deployment is unique, this issue is gone
Before

kl get hpa 
NAME                REFERENCE                      TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
danswer-api         Deployment/danswer-api         87%/80%   1         3         3          15m
danswer-indexing    Deployment/danswer-indexing    87%/80%   1         3         3          59m
danswer-inference   Deployment/danswer-inference   87%/80%   1         3         3          59m

After

kl get hpa 
NAME                REFERENCE                      TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
danswer-api         Deployment/danswer-api         28%/80%   1         3         1          14m
danswer-indexing    Deployment/danswer-indexing    98%/80%   1         3         3          79m
danswer-inference   Deployment/danswer-inference   68%/80%   1         3         3          79m

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

I think I'll take a try at making a KEP for this
/assign

I've been digging into this more.
It seems that the existing behaviour of matching pods outside of a Deployment doesn't actually work. The HPA artificially increases the replica count, I think it's due to this:

https://github.com/kubernetes/kubernetes/blob/v1.32.0/pkg/controller/podautoscaler/replica_calculator.go#L103

readyPodCount could be too high, since additional pods are matched