Question about support matrix for kubernetes-cni package and confusion about its versioning in different repos

[haiwu]

What happened:

Where is the support matrix for 'kubernetes-cni' package?

What you expected to happen:

Expect to have some support matrix for this package for different k8s versions.

How to reproduce it (as minimally and precisely as possible):

I could see these deb packages for 'kubernetes-cni' available from both Google-hosted repo and the new repo:

# apt-cache madison kubernetes-cni
kubernetes-cni |  1.2.0-2.1 | https://pkgs.k8s.io/core:/stable:/v1.28/deb  Packages
kubernetes-cni |  1.2.0-2.1 | https://pkgs.k8s.io/core:/stable:/v1.27/deb  Packages
kubernetes-cni |   1.2.0-00 | https://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
kubernetes-cni |  1.1.1-2.1 | https://pkgs.k8s.io/core:/stable:/v1.27/deb  Packages
kubernetes-cni |   1.1.1-00 | https://apt.kubernetes.io kubernetes-xenial/main amd64 Packages
kubernetes-cni |   0.8.7-00 | https://apt.kubernetes.io kubernetes-xenial/main amd64 Packages

But which version of kubernets-cni package are good for which k8s 1.25, 1.26, 1.27?

Some words from https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/: Kubernetes repositories for v1.24 to v1.27 have same versions of these packages as the Google-hosted repository.

But as shown above, the Google-hosted repository has 1.1.1-00 version, while the new repo has 1.1.1-2.1 version, not exactly the same. Same thing could be said about 1.2.0-00 in Google-hosted repository, but 1.2.0-2.1 in the new repo.

And any difference between these versions in different repo? This is very confusing. Please clarify.

Anything else we need to know?:

N/A

[xmudrii]

Hello @haiwu,

The package version has two parts: the version of the component and the package revision, usually separated with -. In this concrete case, 1.1.1-2.1 means that you'll get kubernetes-cni 1.1.1, and that the package revision is 2.1. Package revision is important in case we need to rebuild the package for the same version of the component for any reason.

It's mentioned in the announcement blog post that the package revision format got changed in the new repos:

The revision part of the package version (the -00 part in 1.28.0-00) is now autogenerated by the OpenBuildService platform and has a different format. The revision is now in the format of -x.y, e.g. 1.28.0-1.1

x is number of commits in OBS for the given component version, while y is number of rebuilds of x. Some info about that can be found in the following Slack thread: https://kubernetes.slack.com/archives/C03U7N0VCGK/p1691738497514679

Revisions for the RPM packages are following a slightly different format, but we're addressing that as part of #3221

I hope the revision part is more clear now, but if not, please let us know if you have any other questions.

[xmudrii]

But which version of kubernets-cni package are good for which k8s 1.25, 1.26, 1.27?

I missed this question, but we don't have a formalized compatibility matrix. Most of these releases are requiring at least kubernetes-cni 1.1.1, as can be seen here: https://github.com/kubernetes/release/blob/master/cmd/krel/templates/latest/metadata.yaml

Starting with 1.29, we'll publish only kubernetes-cni versions that were tested with the given Kubernetes minor version, providing a sort of compatibility matrix. We'll also try to document that in some form.

[haiwu]

Hi @xmudrii: Thanks for clarifying!

Does this mean that we could just go ahead and use 'kubernetes-cni' package latest version '1.2.0-2.1' for all k8s installations, covering k8s 1.25, 1.26, 1.27 and 1.28? Meaning we could always just go with latest 'kubernetes-cni' for all k8s releases?

[saschagrunert]

@haiwu In theory yes, but it also depends on the used container runtime. What we tested can be found in the corresponding release branch via dependencies.yaml:

• v1.25.0: https://github.com/kubernetes/kubernetes/blob/a866cbe/build/dependencies.yaml#L19-L21
• v1.27.0: https://github.com/kubernetes/kubernetes/blob/1b4df30b/build/dependencies.yaml#L19-L21

[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