Autoscaler: vpa object should record info about pod resizing on its events property

Created on 8 Oct 2020  路  8Comments  路  Source: kubernetes/autoscaler

I am working on a benchmark between VPA and HPA using Kubernetes and to do that I am basing myself in metrics like time of events, application and resources usage in the node. So, one of my goals is to identify when a pod is recreated with more resources when using VPA, and I thought this information would be stored in the events property when describing my VPA object, but it doesn't happen, this property is always empty even if my POD gets recreated many times.

So, any thoughts about this? Do you guys think it is a feature that isn't working as expected or it is some missing config on my deployments?

https://github.com/kubernetes/autoscaler/blob/ac3946664db3cb9a15a5a6e43730a7ea0fe2a193/vertical-pod-autoscaler/pkg/updater/eviction/pods_eviction_restriction.go#L142

I think events property should store this information together with a timestamp of the events.

help wanted kinfeature vertical-pod-autoscaler

Most helpful comment

That sounds reasonable, would you be interested in contributing?

All 8 comments

Currently the event is recorded on the pod object (as in the code snippet you included). Do I understand correctly that in addition to/instead of recording event on the pod, you would like to record the event on the VPA object?

@bskiba Yes. I think that would be better because, in the context of VPA, the Pod itself can be destroyed/replaced and the information about events can be lost/hard to track. Pods resized vertically don't save information about events of previous pods.

That sounds reasonable, would you be interested in contributing?

Yes, of course. But I need to say that It would be my first time ever contributing to an open source project of this magnitude. But I think I can handle it.

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

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-contributor-experience at kubernetes/community.
/lifecycle rotten

It seems that there has not been any progress to solve this issue. I will try to fix it and come up with a pull request.

/remove-lifecycle rotten

Was this page helpful?
0 / 5 - 0 ratings

Related issues

adamrp picture adamrp  路  7Comments

jadelafuente picture jadelafuente  路  4Comments

hprotzek picture hprotzek  路  5Comments

whereisaaron picture whereisaaron  路  7Comments

hjkatz picture hjkatz  路  4Comments