Closed dongheeJeong closed 8 hours ago
/area vertical-pod-autoscaler
Honestly, I'm not too sure. The feature was added in https://github.com/kubernetes/autoscaler/pull/535 with no description
My understanding is that it allows for more flexibility with getting history of Pod metrics.
Oh another option is that metrics-api may not be installed on a cluster, and someone would prefer to use Prometheus.
Isn't the point that on recommender start up, by default it will look for VerticalPodAutoscalerCheckpoint
object per VPA, whereas with Prometheus it can query a configurable amount of historical data?
AFAICT, the main difference is when you are deploying recommender for the first time using VerticalPodAutoscalerCheckpoint
resources will be inaccurate until it has collected a good amount of data (over the course of days / weeks I would guess)?
Yup, that's definitely an advantage of Prometheus over metric-server. Thanks for mentioning it.
I've recently had a look at this code and it seems like the only advantage is to that the history is loaded into the VPA for Prometheus. After that, the VPA gets metrics per Pod from the metrics-server.
I hope that answers your question, please re-open if not.
/remove-kind bug /kind support /close
@adrianmoisey: Those labels are not set on the issue: kind/bug
@adrianmoisey: Closing this issue.
/remove-kind feature
Hello everyone,
I’m currently exploring the Vertical Pod Autoscaler (VPA) and considering the --storage option for the recommender component, which can be set to either checkpoint (default) or prometheus.
I understand that configuring prometheus might require additional setup and integration steps. Could someone please clarify the benefits of using prometheus over the default checkpoint method?
Specifically, I’m interested in understanding:
If there are any documents or resources that cover this comparison, please point me to them.
Thank you so much for your time and assistance!