Discussion: Reduce the range of supported versions for various components (kubernetes / container engines / network plugins / ??? )

[VannTen]

What would you like to be added

Currently, we support for most components 3 minor versions (see roles/kubespray_defaults/defaults/vars/checksums.yml)

This is about whether we should keep doing that or reduce the number of supported versions, to 2, or 1 ; for some components, or all.

My personal opinions is that we should aim for 1 version per Kubespray version, with the same model as k8s itself, with 3 supported releases branches.

Why is this needed

There is several reasons motivating this:

• supporting several versions imply a certain amount of complexities, particularly for Kubernetes -> depending on the version, for instance, various version of different config file are supported (kubeadm : see Cleanup: kubeadm-config v1beta4 extra args defined conditions #12307 , structured authorization :

  kubespray/roles/kubespray_defaults/defaults/main/main.yml

  Line 528 in 9cce89d

  kube_apiserver_authorization_config_api_version: "{{ 'v1alpha1' if kube_version is version('1.30.0', '<') else 'v1beta1' if kube_version is version('1.32.0', '<') else 'v1' }}"

  ). For container engine, this can means several config format, for network plugins, different RBAC, etc.
• we only test the default versions, not the full matrix.
• since we support the last 3 minor releases, this means we ship upstream versions which are no longer supported or patched for security.

The questions I have:

• do users use not default minor versions of some components ?
• Is staying on a previous supported releases of kubespray an option ?

/priority important/long-term

@ant31 @tico88612 @chadswen @mzaian @yankay

Thoughts ?

[k8s-ci-robot]

@VannTen: The label(s) priority/important/long-term cannot be applied, because the repository doesn't have them.

Details

In response to this:

What would you like to be added

Currently, we support for most components 3 minor versions (see roles/kubespray_defaults/defaults/vars/checksums.yml)

This is about whether we should keep doing that or reduce the number of supported versions, to 2, or 1 ; for some components, or all.

My personal opinions is that we should aim for 1 version per Kubespray version, with the same model as k8s itself, with 3 supported releases branches.

Why is this needed

There is several reasons motivating this:

• supporting several versions imply a certain amount of complexities, particularly for Kubernetes -> depending on the version, for instance, various version of different config file are supported (kubeadm : see Cleanup: kubeadm-config v1beta4 extra args defined conditions #12307 , structured authorization :

  kubespray/roles/kubespray_defaults/defaults/main/main.yml

  Line 528 in 9cce89d

  kube_apiserver_authorization_config_api_version: "{{ 'v1alpha1' if kube_version is version('1.30.0', '<') else 'v1beta1' if kube_version is version('1.32.0', '<') else 'v1' }}"

  ). For container engine, this can means several config format, for network plugins, different RBAC, etc.
• we only test the default versions, not the full matrix.
• since we support the last 3 minor releases, this means we ship upstream versions which are no longer supported or patched for security.

The questions I have:

• do users use not default minor versions of some components ?
• Is staying on a previous supported releases of kubespray an option ?

/priority important/long-term

@ant31 @tico88612 @chadswen @mzaian @yankay

Thoughts ?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[VannTen]

/priority important-longterm

[mehrdadbn9]

Hi, I'd like to participate in this discussion about reducing the range of supported component versions. I can help analyze the impact and propose a versioning strategy. Could a maintainer please assign it to me? Thank you!

[tico88612]

@mehrdadbn9 I don't think we need to assign this. As the title, this issue should only be for discussion and evaluation. Collecting more suggestions from users and developers.

[vdveldet]

If this will make development easier, this is justifiatied in favour of stability.
I think the defaults version are used a lot, as a user you can consider them as tested and stable.