Changes/Kubernetes-1.29

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Report issues
To report an issue with this template, file an issue in the pgm_docs repo.

Update Kubernetes to v1.29 in Rawhide

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

• Name: Brad Smith
• Email: bradley.g.smith@gmail.com

Current status

• Targeted release: Fedora Linux 40
• Last updated: 2023-12-20
• [<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).

• Release engineering: #Releng issue number

• 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.

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)