Fedora 41 is going to be an exciting release, especially for those involved in the enterprise and cloud computing sectors. Containerization plays a crucial role in this field, with Kubernetes being the de facto standard for orchestrating containerized services these days.
Why am I saying all this? Fedora 41, due for release at the end of October, has prepared some very pleasant surprises. Here’s what it’s all about.
To give K8s administrators using Fedora more flexibility and control, the distro has announced significant changes to its Kubernetes packaging strategy, starting with Fedora 41, which marks a shift from offering a single Kubernetes version per release to multiple supported versions simultaneously.
Traditionally, each Fedora release was tied to a specific Kubernetes version, creating a dependency that sometimes complicated system updates and maintenance. However, this is about to change.
With the upcoming Fedora 41, users can access Kubernetes versions 1.31, 1.30, and 1.29, all packaged as individual RPMs. This initiative decouples Fedora updates from Kubernetes upgrades, allowing administrators more leeway to update their systems or Kubernetes independently.
The initial release of these versioned RPMs will appear in Fedoraโs Rawhide branch (current development version of the distro), featuring:
- Kubernetes 1.31 (RPM named kubernetes1.31)
- Kubernetes 1.30 (kubernetes1.30)
- Kubernetes 1.29 (kubernetes1.29)
Itโs important to recognize that this strategy is about adding flexibility and extending the lifecycle of Kubernetes installations. In light of this, the unversioned RPMs for Kubernetes, starting with v1.29 in rawhide, will receive updates until February 2025, even as newer versions are rolled out.
This ensures continuity and support even as new versioned RPMs roll out. With its three annual releases and monthly patches, Kubernetes will see versions 1.28 nearing end-of-life and 1.27 no longer supported by the time Fedora 41 goes live.
And now a little more about the packages themselves. Each Kubernetes release will include four specific RPMs, such as “kubernetes1.31,” “kubernetes1.31-client,” “kubernetes1.31-kubeadm,” and “kubernetes1.31-systemd.”
The new versioned RPMs bring several internal changes that may affect how administrators configure clusters:
- User and Group Ownership: The RPMs now align the default user and group ownership of kubelet files with Kubernetes developer standards, removing the previous kube sysuser identity.
- Configuration Updates: Using
kubeadm, kubelet is now configured via a file instead of command-line parameters, aligning with Kubernetes recommendations. - Systemd Service Files: The default settings of systemd service files in the new RPMs have been standardized according to Kubernetes developer guidelines.
Lastly, aligning with Kubernetes, the versioned RPMs for CRI-O and CRI-Tools also adhere to minor-level version matching. This ensures consistency across the system components, facilitating smoother updates and compatibility.
For more information, visit the announcement.
