Open ejholmes opened 1 month ago
/area vertical-pod-autoscaler
/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.
/retitle Native support for ArgoRollout CRD to improve efficiency
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). BecauseRollout
is not a well known controller this results in VPA making lots of API calls to the Rollout's/scale
endpoint, thanks to this loopAs 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.