From Fedora Project Wiki
No edit summary
(add note on past use of copr for skipped k8s releases)
Line 76: Line 76:
Kubernetes update guidelines do not permit a version skip. For example, if a Kubernetes cluster is currently using Kubernetes v1.27, then in order to update to k8s v1.29, first v1.28 needs to be deployed. Skipping versions, as this proposal does, requires effective communications and an effective replacement. In this instance, Kubernetes v1.28 will be available from COPR. There is another change request in DRAFT form that addresses this problem by shifting to multiple versioned packages of Kubernetes for each release (i.e. the package changes from kubernetes-1.29.f40 to kubernetes1.29-1.29.f40 and so on.
Kubernetes update guidelines do not permit a version skip. For example, if a Kubernetes cluster is currently using Kubernetes v1.27, then in order to update to k8s v1.29, first v1.28 needs to be deployed. Skipping versions, as this proposal does, requires effective communications and an effective replacement. In this instance, Kubernetes v1.28 will be available from COPR. There is another change request in DRAFT form that addresses this problem by shifting to multiple versioned packages of Kubernetes for each release (i.e. the package changes from kubernetes-1.29.f40 to kubernetes1.29-1.29.f40 and so on.


A version skip for Kubernetes happens with every 3rd Kubernetes release due to the release cadence differences between Fedora releases and Kubernetes versions.
The Kubernetes user community is somewhat used to using COPR for past releases. Kubernetes 1.23 was also skipped in Fedora and only available in COPR. Kubernetes 1.25 was initially provided in Fedora 37 but moved to COPR when upstream adopted a version of the go language not available for F37.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Revision as of 18:18, 22 December 2023

Update Kubernetes to v1.29 in Rawhide

Important.png
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.

Summary

Replace Kubernetes 1.28 in rawhide (F40) with v1.29.

Owner


Current status

  • Targeted release: Fedora Linux 40
  • Last updated: 2023-12-22
  • [<will be assigned by the Wrangler> devel thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The upstream Kubernetes project just released Kubernetes (K8S) v1.29. The upstream k8s team maintains 3 versions concurrently. Fedora provides a target version of Kubernetes with each release. Fedora 38 has k8s v1.26; Fedora 39 has k8s v1.27, and rawhide (F40) currently has k8s v1.28. If approved this change will replace k8s v1.28 with k8s v1.29 in rawhide for the F40 release.

See https://src.fedoraproject.org/rpms/kubernetes for the current k8s packages in Fedora.


Feedback

TBD


Benefit to Fedora

Fedora F40 will have the most current Kubernetes version when F40 is released to production. This will enable Fedora users to deploy and maintain current Kubernetes on Fedora Server and Fedora CoreOS using Fedora provided rpms.

Scope

  • Proposal owners:

Execute communication plan (community blog and mailing list posts) announcing the change. Test and deploy the update (already available in COPR).

  • Other developers:

Coordinate with the CRI-O packager so that they release a compatible version of CRI-O. Kubernetes and CRI-O have the same release cycle and version numbering, i.e kubernetes v1.29 requires cri-0 1.29 (if cri-o is used as the container runtime interface).

  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

n/a

Upgrade/compatibility impact

Kubernetes update guidelines do not permit a version skip. For example, if a Kubernetes cluster is currently using Kubernetes v1.27, then in order to update to k8s v1.29, first v1.28 needs to be deployed. Skipping versions, as this proposal does, requires effective communications and an effective replacement. In this instance, Kubernetes v1.28 will be available from COPR. There is another change request in DRAFT form that addresses this problem by shifting to multiple versioned packages of Kubernetes for each release (i.e. the package changes from kubernetes-1.29.f40 to kubernetes1.29-1.29.f40 and so on.

The Kubernetes user community is somewhat used to using COPR for past releases. Kubernetes 1.23 was also skipped in Fedora and only available in COPR. Kubernetes 1.25 was initially provided in Fedora 37 but moved to COPR when upstream adopted a version of the go language not available for F37.


How To Test

User Experience

Users managing kubernetes clusters using Fedora packages on Fedora machines will need to be aware of this change. An unplanned version update can break a cluster, hence rawhide is the best starting point for this update.

Dependencies

None.


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


Documentation

N/A (not a System Wide Change)

Release Notes