Wrong target kind for PrometheusAgent workloads

[wI2L]

What happened?

Hello,

Using the Prometheus operator, we're deploying several PrometheusAgent CRs that own and manage a linked StatefulSet, which itself manages a variable number of pod replicas.

I have noticed that Goldilocks actually resolves the PrometheusAgent kind as the VPA target, instead of the StatefulSet in such situation, example:

Name:         goldilocks-cxxx
Namespace:    core-system
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
Spec:
  Target Ref:
    API Version:  monitoring.coreos.com/v1alpha1
    Kind:         PrometheusAgent
    Name:         xxx

What did you expect to happen?

In our case, the Prometheus pods are owned by a StatefulSet:

apiVersion: v1
kind: Pod
metadata:
[...]
  name: prom-agent-xxx-0
  namespace: xxx
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: StatefulSet
    name: prom-agent-xxx

The StatefulSet is itself owned by the PrometheusAgent custom resource:

apiVersion: apps/v1
kind: StatefulSet
metadata:
[...]
  ownerReferences:
  - apiVersion: monitoring.coreos.com/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: PrometheusAgent
    name: xxx

I was expecting to get a VPA with a StatefulSet as the target kind, instead of PrometheusAgent. Goldilocks seems to resolve the top-most owner kind, instead of the direct owner of the pods.

How can we reproduce this?

Create a PrometheusAgent CR managed by the prometheus operator, and allow Goldilocks to watch those resources using extra RBAc rules:

  rbac: 
    extraRules: 
    - 
      apiGroups: 
      - "monitoring.coreos.com"
      resources: 
      - "prometheusagents"
      verbs: 
      - "get"
      - "list"

Version

Chart: 9.0.1, App: v4.13.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[wI2L]

Not stale ? /reopen