voelzmo
commented
1 year ago Just re-iterating what I tried to say in the SIG meeting: I'm not sure if we really should assign a meaning to VPA version numbers, if we don't need to do this. Right now, we can release VPA and decide freely, if this should be a patch version update, a minor version update, or a major version update. If you're linking this directly to k8s versions, you lose this freedom.
As everything is a tradeoff, let's look at what we're gaining for this freedom. We could be dropping this table in the README, which tries to record the incompatible changes we made in VPA and specify which k8s versions definitely would break (e.g. because a certain API version doesn't exist in k8s versions smaller than x) and replace it with a single statement like Cluster-Autoscaler
We recommend using Cluster Autoscaler with the Kubernetes control plane (previously referred to as master) version for which it was meant. The below combinations have been tested on GCP. We don't do cross version testing or compatibility testing in other environments. Some user reports indicate successful use of a newer version of Cluster Autoscaler with older clusters, however, there is always a chance that it won't work as expected.
(source)
This would also mean that we would need to start maintaining (at least?) 3 VPA releases. Instead of rolling forward whenever we merge a security- or bugfix, we'd need to cherry-pick this to the VPA release branches for the 3 supported k8s versions. All of this is easily possible when releasing and cherry-picking is automated, but given the current state of how to do a VPA release, I'd rather avoid these complications.
k8s-triage-robot
Shubham82
sjwl
I'd like to change how we version VPA.
Since there's K8s version which:
I think it makes sense to name VPA like that K8s version. It would make it easier to decide which VPA version to use with which K8s version.
During SIG meetings the following downsides were pointed out:
I think 1. isn't likely to be a big issue (we have more of a problem of doing minor releases not frequently enough). I think that 2. we can address by documenting this properly.
During SIG meeting it was also pointed out that before we do a change like that we should check if Kubernetes community has any recommendations around changes like that.