So when I was doing the implementation of in-place VPA, I noticed that it didn't work on any pods that didn't have limits.

• Doing some research/reverse engineering of the kubelet led me to here: https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L556 where it very obviously doesn't calculate if limits are missing.
• As an aside, I will also mention that it looks like memory requests are scaling without limits being present, but it really isn't, it's kind of a lie: https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L592  (that made this extra confusing to figure out  – "why does memory work but CPU doesn't")

We can still use it in the VPA, but telling folks "well, but all your pods need to have limits" when half our e2e suite doesn't use limits seems like it would be disappointing long term. Ideally the feature would have the same constraints as eviction so nobody has to learn weird corner cases, they just turn in-place on and it works.

Anyway, I can't find anything in the enhancement that would suggest this was super intentional in the design, e.g. "Thou shalt not scale without limits otherwise X bad thing will happen", and it came in with the initial implementation so I need to inquire upstream about it.

So what we need to do is:

• Figure out the rationale/intentionality/constraints governing the decision to only calculate resize for pods with limits
• Test the kubelet without that check and see if it explodes
• Figure out if there is some work we can do to get InPlacePodVerticalScaling to work on pods with limits

Done when:

• We know our constraints/next steps for InPlacePodVerticalScaling with regard to in-place VPA
• We know what effort (if any) we need to put in upstream on the InPlacePodVerticalScaling feature directly