[feature request] Allow to set limit/request ratio for vpa

[mfilotto]

Hi,
It's a very good new feature to have also limits updated.
It would be even better if we could set a limit/request ratio.

[mfilotto]

In my use case, I use vpa to set all the requests.
These request are all set to a default value.
But in the mean time we set limit resource.
the ratio in my case is not relevant, worse it will set bad values

[jgrahn-papajohns]

I'd like to second this request. We have a large non-production cluster containing many services controlled by many teams. Most of these services are idle, and are requesting more resources than they need. We are experimenting with adding VPAs to these services to optimally scale their resource requests. This used to work fine -- the cpu and memory requests would be adjusted to reasonable values. Now, however, the cpu limit is also being decreased, and some of the services can no longer start up fast enough to pass their healthchecks. This results in an infinite loop of starting and killing pods.

[jansony1]

+1

[bskiba]

In general, we don't advise setting limit on CPU, except maybe in some corner cases. Since CPU is compressible, there is no value from throttling the workloads to the limit, if you allow them to burst over their request, they will be simply throttled if there is shortage of CPU on the node.
If you feel like you have a compelling use case for CPU limits, please let me know.

That being said, can you clarify what this request is about? Currently VPA preserves the request/limit ratio from deployment, so the way to configure it is to set your desired ratio in the deployment spec.
What would you like to be able to configure?
@mfilotto What do you mean by default value for request? Do I understand correctly that you set some default request value on workloads but the limit is customized and the resulting ratio is not the desired one?

[buddyledungarees]

Since the request/limit ratio is already preserved, can we request a feature to have a flag to exclude setting the limit on pods?

The use case is that a lot of k8s deployments set requests == limits to follow an old "guaranteed" scheduling goal. With the fixed 1:1 ratio, the pods no longer become ready in time due to startup cpu costs being higher than the VPA target.

Startup costs being factored into VPA targets is a separate discussion as well as other ways to work around the problem (change resource limits, timeouts, etc). Having this feature flag to preserve the existing limit though will help operationally rollout VPAs.

[bskiba]

Closing in favour of #2387 which asks for the same control (disable scaling limits)
/close

[k8s-ci-robot]

@bskiba: Closing this issue.

In response to this:

Closing in favour of #2387 which asks for the same control (disable scaling limits)
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.