search

kubernetes / autoscaler

Autoscaling components for Kubernetes
Apache License 2.0
7.94k stars 3.93k forks source link

`fail to get pod controller`, due to pod created by custom controller #7077

Open jacobeatsspam opened 1 month ago

jacobeatsspam commented 1 month ago

Which component are you using?:

Vertical Pod Autoscaler

What version of the component are you using?:

1.1.1

What k8s version are you using (kubectl version)?:

1.29

What did you expect to happen?:

I expect VPA's controllerfetcher to only handle pods owned by a Deployment or Statefulset.

What happened instead?:

VPA prints errors because it's attempting to list a pod owned by a 3rd party controller: 

api.go:153] fail to get pod controller: pod=argo-rollouts-dashboard-66d98c5789-% err=Unhandled targetRef argoproj.io/v1alpha1 / Rollout / argo-rollouts-dashboard

How to reproduce it (as minimally and precisely as possible):

1) Install a 3rd party operator, such as Argo, Prometheus Operator, etc. 1) Monitor admission-controller's log output. Be sure to set the highest verbosity --v=5.

adrianmoisey commented 1 month ago

/area vertical-pod-autoscaler

voelzmo commented 1 month ago

Hey @jacobeatsspam, I think we're missing some information here: It seems the log statement you're pasting is truncated, usually it should continue with , last error <some error here> (source) Using custom resources is supported, as long as they implement the /scale subresource, and we have seen people use it for argo rollouts specifically (e.g. here someone has many of them and wants native support for argo rollout, but it does work for them).

Maybe this is a permission problem or there is any other reason why the admission-controller cannot access the /scale subresource for the CRD? How did you install VPA?

In general, I would also advise you to update to vpa release 1.1.2, as there has been an important bugfix in the vpa-updater.

/triage needs-information