Autoscaler: [feature request] Optionally allow VPA to manage pod limits
I remember seeing this in the codebase in v0.2 IIRC and I couldn't find any real explanation for why it was removed. If anyone can speak to that or what the long-term roadmap looks like here, I'm very curious.
The use case I would love to see supported is fairly narrow – I want VPA-managed pods with guaranteed QoS. We do also use LimitRanges to enforce default limits, so ideally this would include a mechanism for overriding existing limits (perhaps the initial limit could function as a hard upper bound?).
Related: #1812
davidquarles
All 7 comments
This is reasonable feature requests.
The initial support was very limited and did not cover your use case (it set limits a bit above request, which made the pods burstable not guaranteed). We removed it mostly as it significantly worsened the time-to-converge on a good request for memory when starting with unset request. Pods were getting multiple Out of Memory errors and taking a lot of time to stabilize.
Nevertheless support for modifying limits is on our roadmap.
bskiba
on 29 Mar 2019
Very interested in this too!
complex64
on 12 Jun 2019
This is actually in the works. The next released version of VPA will support limit modification as well as request.
The general idea is if there was originally a limit specified in the pod specification, VPA will keep the request to limit ratio constant.
bskiba
on 12 Jun 2019
@bskiba, that's great news, thanks! Looking forward to the release.
complex64
on 12 Jun 2019
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 10 Sep 2019
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 10 Oct 2019
This is fixed
bskiba
on 10 Oct 2019
Related issues
clamoriniere
·
5Comments
pkelleratwork
·
5Comments
mboersma
·
6Comments
hadifarnoud
·
7Comments
losipiuk
·
7Comments
Most helpful comment
This is reasonable feature requests.
The initial support was very limited and did not cover your use case (it set limits a bit above request, which made the pods burstable not guaranteed). We removed it mostly as it significantly worsened the time-to-converge on a good request for memory when starting with unset request. Pods were getting multiple Out of Memory errors and taking a lot of time to stabilize.
Nevertheless support for modifying limits is on our roadmap.