kedacore
Provide support for Vertical Pod Autoscaler (VPA)
Proposal
Provide support for Vertical Pod Autoscaler (VPA) instead of HPA.
Use-Case
No response
Anything else?
No response
VPA doesn’t have any kind of interaction like we would need for custom metrics, at least not last time I looked. We would need that first. Overall not sure on this one, I think we should wait for some users to weigh in that they specifically need this :)
Yes, fully agree.
This came up a few times during our office hours so just using it to track demands.
@LH8PPL Could you provide a more specific use case that you're looking for?
We need support for vertical autoscaling for our case. In our case we gave background jobs which gets executed on the pods. The jobs are partitioned and a pod takes the lease for a partition. Our partitioning is already optimal as per our app demands but also our application is very spiky. Which means we do see a burst of jobs which gets executed and many pods starves for resources. Right now we have over provisioned the limits which is lot of wasted dollars. A VPA solution will help us adjust dynamically and scale as per the load patterns.
Horizantal scaling is awesome if serves us good when load could be handled by adding more pods and work getting distributed.
Thanks
cc/ @coderanger @tomkerkhove
In that case, is there anything that the VPA does not offer that blocks you?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I would also be very interested in this. We have some workloads that are not well suited to scaling horizontally which we would like to scale vertically.
Our application has a predictable but unusual usage pattern, where load will be very low, then very high for a period of as little as 15 minutes, then return to being very low again. As some of our workloads take a while to perform a rolling restart, by the time VPA has detected an increase of load and the workloads have restarted with increased resources, the period of high load has already passed.
What I would like to do is scale these workloads in advance of that high load, potentially via a cron source.
That's interesting, so it's purely for time-based/scheduled autoscaling?
Not necessarily only time-based. We have a time based need right now, but could definitely see us making use of vertical autoscaling based on other triggers. I'd say Kafka, Elasticsearch and Prometheus would be the most likely for us.
Regardless of the effort, because that will be a ton, I can see a lot of value there indeed. Thoughts on this @kedacore/keda-maintainers ?
Thanks Tom.
This line from the limitations section of the VPA documentation sums up best why I'm looking for alternatives:
Vertical Pod autoscaling does not generate recommendations based on sudden increases in resource usage. Instead, it provides stable recommendations over a longer time period. For sudden increases, use the Horizontal Pod Autoscaler.
We have several workloads that sit in the awkward space of not being suitable for horizontal scaling, but with load that's too spiky for the VPA. We know when our periods on increased load will be, but are currently faced with having to create our own tools to fill this gap.
I would love this feature to automatically scale a server application that can't be scaled horizontally (in-memory state).
Interesting use-case; but I think the integration with VPA is completely different compared to HPA and I'm not sure if we want to expand scope of the project. Thoughts @zroubalik / @JorTurFer?
I think that we could collaborate with the SIG-Autoscaling adding the support also the the VPA Controller. AFAIK, they don't support external metrics yet, but we could add the support to them and once it's that done, we just need to generate VPA from ScaledObjects. I think that it's doable if they agree with extending the VPA Controller with external metrics
https://github.com/kubernetes/autoscaler/pull/5576
@tomkerkhove we should do it imho :)
Oh interesting, I was not aware of this.
Let's do a design proposal then of what needs to be done and how.
Hi, has there been any further work done around a design proposal for this?
I have a number of projects that would be significantly easier to maintain if I can increase my Keda usage to also encapsulate my VPA usage, and am interested in contributing to this work!
Currently, there isn't any proposal, but you can tackle it if you want and draft one. I'd say that it's still interesting for KEDA :)
Hi, new to Keda. I would like to get some background on this and help since this work item is still open.
Hi, new to Keda. I would like to get some background on this and help since this work item is still open.
Currently, KEDA exposes external.metrics.k8s.io and manages the HPA under the hood. As the VPA controller now supports external metrics, we should check if we can integrate KEDA with the VPA controller to support that KEDA creates VPA or HPA (currently we only support HPA). We need to check if it's the integration is possible and add the support for it (not making the VPA CRDs mandatory as not all users will use VPA)
My team would be in favour of a VPA CRD. We just implmented KEDA in our production environment and it's been performing exceptionally. VPA is not an immediate priority for us, but to have it orchestrated by KEDA saves having to roll our own.
We don't have golang expertise, but we could potentially test as it's developed.
I'd personally love to see intergration with VPA, the ability to use target Utilisation would be very beneficial. Regretably I also have very limited golang experience but would be happy to help however I can.
