F41 Change Proposal: Versioned Kubernetes Packages (Self-Contained)

Multiple Versioned Kubernetes Packages

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.


:link: Summary

Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release.

:link: Owner

:link: Detailed Description

The Kubernetes project maintains 3 concurrent versions with a new release every 4 months. Each version has a defined life-cycle of approximately 1 year (https://https://kubernetes.io/releases/ for details and current versions). In this proposal a release is a major:minor version combination such as 1.28 or 1.27 and ignores any patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same 1.28 minor release).

We currently match one version of Kubernetes with each Fedora release. See Overview - rpms/kubernetes - src.fedoraproject.org for the list of Kubernetes releases by Fedora release. Due to the differing release cadences between Fedora and Kubernetes this means that a new release of Fedora may not have the most current release of Kubernetes. And, given that the Kubernetes cluster upgrade process does not permit skipping major:minor releases, not providing a Kubernetes release in Fedora so that the most current Kubernetes release is available when a Fedora release goes into production becomes a barrier to using Fedora as a host OS for Kubernetes.

We propose to create packages for all current Kubernetes releases for each Fedora release starting with Fedora 40. The package name would follow the Fedora naming convention standard for multiple package versions of “kubernetes[major].[minor]”. Using the kubernetes-client rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora would offer kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41, and kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes versions available will depend on what is supported upstream.

We also propose that there not be any default version of Kubernetes for a given Fedora release. Fedora would not provide a kubernetes-client-1.30.1-1.fc41 package available, assuming that Kubernetes 1.30 is the “default” for Fedora 41. Default versions coupled to a given Fedora release can result in unplanned version updates to the installed Kubernetes version (i.e. v1.28 to v1.29) which can adversely affect cluster functioning.

It is also important to note that each Kubernetes release is built with a specific version of the Go language. The version of Go available in a Fedora release will potentially be a constraint on which version of Kubernetes can be provided for an older Fedora release.

We also maintain a Kubernetes page on Fedora Quick Docs with information about the change and how to install Kubernetes using Fedora provided packages.

:link: Feedback

To be provided.

:link: Benefit to Fedora

Fedora becomes a first class platform for Kubernetes using packages from Fedora repositories. That is, all current, maintained releases of Kubernetes are available in the main Fedora repositories, subject to the Go language constraint. This allows Fedora, as a host OS for a Kubernetes cluster, to be maintained and upgraded independently of the Kubernetes release used by the cluster. This also allows the cluster to be upgraded independently of the Fedora release using Fedora provided packages.

This also means that a Kubernetes cluster administrator using Fedora as their workstation can install and use or retain the appropriate Kubernetes command line client, kubectl, that matches the release of the cluster. Updating to a new Fedora release will not inadvertently install a command line client that is not compatible with the release version of the cluster(s) managed by the user.

:link: Scope

  • Proposal owners:

With each new minor release of Kubernetes, package owners would request a new repository on src.fedoraproject.org from engineering similar to what the nodejs team now does for the parallel-installable versions of nodejs. Documentation would be refreshed to inform users of the new version and what specific Fedora releases the new version of Kubernetes would be available on.

  • Other developers:

Releases of cri-o and cri-tools are version matched with Kubernetes release at the major:minor level. Cri-o uses modularity in Fedora 38 and older to provide multiple versions. The cri-o and cri-tools package maintainers will adopt a similar versioned approach to packaging and release in Fedora.

Release engineering would need to create the new dist-git repository for each new Kubernetes release.

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives:

:link: Upgrade/compatibility impact

This change will require documentation in on-line Fedora documentation such as the dedicated Quick Docs page and posts to various forums and mailing lists to raise awareness. Upgrading to Fedora 40 on a machine with Fedora 39 or Fedora 38 would require a manual step by the user to select the appropriate versioned Kubernetes package.

:link: How To Test

  1. Install a versioned Kubernetes package on a fresh instance of Fedora and create a functioning test cluster. 2. On a cluster node, replace a non-versioned Kubernetes package with a versioned package and rejoin cluster. There should not be any errors.

:link: User Experience

The user experience should remain unchanged except for the need to select a specific version of Kubernetes.

:link: Dependencies

No direct dependencies. If cri-o and/or cri-tools are installed and used then these packages and kubernetes should have the same major:minor version.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

Fedora Quick Docs: Using Kubernetes on Fedora :: Fedora Docs

N/A (not a System Wide Change)

:link: Release Notes


Removed f38, f39

This change proposal has now been submitted to FESCo with ticket #3194 for voting.

To find out more, please visit our Changes Policy documentation.

How do you feel about the proposal as written?
  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

1 Like

Looking forward to 1.30 then . I can only confirm I tested F40 packages. The only thing that came to my eyes was a small skew between kubeadm and cri-o version but I think it is in the acceptable version skew. I also discovered like a little kid that we already have firewalld services defined for the control-plane port range and the worker nodes, so I don’t have to write long lines of port ranges.

# control plane
firewall-cmd --permanent --add-service=kubelet --add-service=kube-control-plane-secure

# worker nodes
firewall-cmd --permanent --add-service=kube-worker

Whoever did this, thank you

1 Like

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.