Change VPA versioning

[jbartosik]

I'd like to change how we version VPA.

Since there's K8s version which:

• triggers VPA release and
• with which we test VPA the most

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:

1. We might sometimes have to delay releasing some changes. Some changes are being enough so that we can't release them in a patch release. So we'd have to wait up to 4 months for a new minor (K8s and VPA) release
2. CA has versioning like that and is much more tightly coupled with K8s

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.

[voelzmo]

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]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Shubham82]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Shubham82]

/remove-lifecycle stale /lifecycle frozen

[sjwl]

@voelzmo can you clarify the earlier comment:

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

My interpretation is the following: The Compatibility table clearly shows the minimum supported Kubernetes version for each VPA release. In addition, the maximum is derived by observing if there is a Kubernetes version in the table that is higher than the current row.

So for example.

VPA version	Kubernetes version
1.2.1	1.27+
1.2.0	1.27+
1.1.2	1.25+

VPA version 1.1.2 is compatible with Kubernetes versions 1.25-1.26

[ialidzhikov]

+1 for this issue.

node-problem-detector recently introduced the same versioning scheme that this issue suggests: Versioning Scheme for Node Problem Detector.

The reasoning section:

This versioning scheme provides the following benefits:

• Clarity: It is immediately clear which version of Node Problem Detector is compatible with which version of Kubernetes.
• Consistency: It aligns the project with the release cycle of Kubernetes and some other Kubernetes components versioning.
• Predictability: Users can better predict when new releases will be available.
• Easier Maintenance: By having separate version lines for each Kubernetes minor version (e.g., v1.34.x, v1.35.x), we can easily backport critical bug fixes and CVEs to older, still-supported release lines without being forced to also backport newer features.
• Targeted Testing: Each version of Node Problem Detector is tested against a specific Kubernetes version. This also implies testing against particular versions of related components like the container runtime and OS. New features in Node Problem Detector will not necessarily be tested against older versions of these components.

There are also other external components following the same versioning scheme in the Kubernetes ecosystem - cloud-controller-managers, openstack CSI drivers.