Draft-K8s-Roadmap

DRAFT

Fedora Kubernetes Package Roadmap for 2022-2023

Vision

Establish Fedora as a first class platform for Kubernetes.

Details

1. All supported versions of Kubernetes are available as packages in the Fedora dnf repository.
2. Documentation is available.
3. Upstream releases are avaiable in a timely manner.
4. Upstream beta (?) and/or rc (?) candidates available as packages.
5. Communication plan

Current State

Kubernetes rpms are available from the Fedora rpm repository but updates have been slow to very slow. The spec file has not been reviewed in light of current standards, especially go-sig standards. The spec file also creates several artefacts as systemd units that are also now created duing cluster initiation as static pods. There is no documentation on what version of Kubernetes will be available for each Fedora release.

Kubernetes is not available as modular rpms in Fedora even though upstream maintains 3 concurrent minor versions (e.f. 1.25, 1.24, and 1.23). A cluster manager may want to stay on a specific Kubernetes release over multiple Fedora releases on the underlying machines. Both the CRI-O container runtime and CRI-Tools are available as modular rpms and are version synchronized with Kubernetes (major:minor but not patch sync).

Goals and Deliverables

1. Review and revise spec file
   1. Rename child rpms (e.g. kubernetes-control-plane instead of kubernetes-master)
   2. Resolve all rpmlint errors and warnings - mitigate if needed in rpmlint config
   3. Remove systemd units for proxy, controller, apiserver (or move to kubernetes-legacy rpm).
2. Add readme to kubernetes repo
3. Create/publish/maintain release rpm version roadmap that identifies what version(s) of Fedora support a given Kubernetes release. For example Kubernetes 1.25 is built with go 1.19 which is available starting in Fedora 37 but not in Fedora 36. Kubernetes 1.25 will go EOL in October 2023 while Fedora 37 reaches EOL mid-November 2023. Cluster managers will want a continuity plan that covers all transitions from Fedora. Coordinate with CRI-O and CRI-Tools maintainers.
4. Create (revive?) modular Kubernetes and coordinate with CRI-O and CRI-Tools maintainers.
5. Create communication plan
   1. Fedora magazine article on using Fedora RPMs to create a cluster with attendant good practice. For example, most existing write-ups on line advise disabling selinux and the firewall on Fedora which are not desirable or necessary any more. Supporting ansible tasks to automate.
      1. Fedora server/Fedora CoreOS variants?
   2. Fedora docs page describing differences between release rpms and modular rpms (and nuances of switching from one to the other with Kubernetes).
   3. Matrix group?
   4. Sig?
   5. Identified customers (ie. users of the rpms)

Questions and Issues to Resolve

1. What role should the go-sig have?
2. Will go2rpm be useful?