Native support for ArgoRollout CRD to improve efficiency

[ejholmes]

Which component are you using?:

VPA

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:

We use VPA in combination with Argo Rollouts. In the cluster we're using this with, each namespace has many hundreds of Rollout objects (~500) and many namespaces (~7). Because Rollout is not a well known controller this results in VPA making lots of API calls to the Rollout's /scale endpoint, thanks to this loop

As a result, the webhook takes many seconds to finish, sometimes more than 30 seconds leading to a timeout and fail open. We've done our best to tweak the kube-api-qps/kube-api-burst flags, but this feels like a bandaid.

Describe the solution you'd like.:

It would be nice if VPA natively supported Rollout objects as a well known controller, so that it can use a shared informer to keep a cache of Rollout objects to make the admission controller more performant.

Describe any alternative solutions you've considered.:

If direct support for Rollout wouldn't be accepted, since it's a third party CRD, maybe VPA could support a dynamic informer so that users of VPA could add a flag of CRD's they want to use VPA with.

[adrianmoisey]

/area vertical-pod-autoscaler

[voelzmo]

/triage accepted

I don't think it's feasible to add each and every CRD to the list of well-known controllers, but it seems that we can do much better performance-wise in how VPA determines the Pods that belong to VPA.

[voelzmo]

/retitle Native support for ArgoRollout CRD to improve efficiency