F40 Change Proposal: Restructure Kubernetes Packages

Project Discussion Change Proposals
,
1

Restructure Kubernetes Packages

Discussion for Changes/RestructureKubernetesPackages - Fedora Project Wiki

Summary

New or revised (sub)package names are proposed for Kubernetes packages in Fedora. The new names will better align Kubernetes with current usage as documented upstream and improve alignment of package content with current Fedora practices and standards.

Owner

Detailed Description

Kubernetes provides “Open Source Production-Grade Container Scheduling And Management”.

The existing Kubernetes package and sub-packages are outlined in the table below. All packages include relevant configuration files and documentation (man pages).

Current package and sub-packages in the Kubernetes package:

Name Status (Sub )Package Notes
Kubernetes Main Package Empty. Requires the Client sub-package.
Client Sub-package Kubectl - Command line client. Used to manage a cluster from any computer connected to network.
Kubeadm Sub-package Kubeadm - Administrative client. Used to join or remove a node to/from a cluster.
Master Sub-package Kubernetes services packaged as obsolete systemd services. Modern installations of Kubernetes install these services as static pods.
Node Subpackage Kubelet - Kubernetes runtime.

Proposed package and sub-packages in the Kubernetes package:

Name Status (Sub )Package Notes
Kubernetes Main Package Provides kubelet (runtime) and kuberadm (node administation) binaries and configuration files. Requires the Client sub-package.
Kubernetes-doc Sub-package Documentation (man pages) for kubectl and kubeadm.
Client Sub-package Kubectl - Command line client. Used to manage a cluster from any computer connected to network.
Client-doc Sub-package Documentation for kubectl, command line client.

With the proposed sub packages a user that wants to install Kubernetes on a Fedora machine will only need to install the kubernetes rpm and optionally the kubernetes.doc rpm. This action installs all 3 needed Kubernetes binaries and configuration files and aligns with guidance from upstream (i.e. install kubectl, kubeadm, and kubelet on each machine in a cluster).

Kubernetes cluster managers will install, as before, the kubernetes-client rpm on any machine used by the manager to manage a cluster. The kubernetes-client-doc rpm will be optional.

Feedback

Benefit to Fedora

The primary beneficiary will be Fedora users that want to install Kubernetes on a Fedora machine and use that machine as a node in a cluster or as a management console to manage one or more local or remote clusters. It will also segregate out documentation (man files) so that a minimal install can be done with just the needed executables and
supporting configuration files. Installation of the kubernetes rpm is all that is needed to install all necessary binaries on a Fedora machine to participate as a node in a cluster. The current package structure requires the user to install either the kubernetes, kubernetes-kubeadm, and kubernetes-node rpms or install the kubernetes-client, kubernetes-kubeadm, and kubernetes-node rpms to obtain the same level of functionality.

Scope

  • Proposal owners:
    Modify the kubernetes.spec file to reflect the new package organization and new package content. Build and test new installs and updates across multiple Fedora flavors including server, workstation, and CoreOS.
  • Other developers:
    N/A
  • Release engineering: #Releng issue
    number
    N/A
  • Policies and guidelines: N/A (not needed for this Change)
    N/A
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

The primary effect will be changes to some of the kubernetes-related rpms, but there will not be any effects to existing functionality or configuration. Any scripts or system provisioning tools such as Ansible should continue to function.

How To Test

Two test scenarios are needed.

  1. Upgrade Test. Install Kubernetes or the Kubernetes client on a Fedora machine using legacy rpms. Optionally configure a cluster or the client. Upgrade the system using the new packages. No change in functionality or configuration should be detected.
  2. New Install Test. Install kubernetes or the client on a Fedora machine using the new rpms. Compare functionality to another machine that has Kubernetes or the client installed using the legacy rpms. No change in functionality should be detected.

User Experience

Users doing a new installation of Kubernetes on a Fedora machine will have a simplified experience. Installing the kubernetes rpm will actually install all needed components of Kubernetes and not just the client as the current rpms do. Similarly, updating a Fedora node in a Kubernetes cluster will only need updating one (1) rpm and not 3 as before.

Dependencies

N/A

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

TBD

2 Likes
2

Based on some feed back I would like to amend the proposal with a revised list of subpackages for Kubernetes. The revision folds the “docs” sub-packages back into their respective companion package and adds a sub-package with systemd services. Most modern kubernetes installations will use static pods for these services, but they are still a viable alternative for a manual install.

The revised list of packages:

  1. kubernetes - the main package. Installs kubelet and kubeadm. Requires the client sub-package resulting in all the necessary software to install and run kubernetes on a node.

  2. kubernetes-client - a sub-package containing kubectl - the command-line client used to manage remote kubernetes clusters.

  3. kubernetes-services - legacy systemd units for kubernetes services. Not needed when using kubeadm to install kubernetes. Available for those who want to install kubernetes “the hard way”.

3

Hi all,

This change proposal has now been submitted to FESCo for review & voting. Ticket can be found here. Thank you for your feedback!

1 Like
4

@zbyszek — you can do markdown tables, documented at Add a table to your post using markdown - users - Discourse Meta. (I’ve also added a discourse theme component to the site which has a table-creation helper – you can find it in the gear menu in the composure.)

You can also cut and paste rendered webpage tables into the composer, and it will translate.

5

Sorry for the slow handling of this. I guess that FESCo members who don’t use kubernetes directly just don’t have an opinion.

I would like to amend the proposal with a revised list of subpackages for Kubernetes. The revision folds the “docs” sub-packages back into their respective companion package

Yes, this sounds reasonable. In general, we don’t split out documentation subpackages, unless the documentation is very big. For installations where space it at premium, there’s always the option of installing with --excludedocs.

kubernetes-master and kubernetes-master have some man pages, but they are don’t take enough space to matter. (Or to phrase is slightly differently, kubectl is so huge that the space taken by the man pages is insignificant.)

and adds a sub-package with systemd services

I’m not sure how useful this is. The systemd service files are tiny and don’t bring in any dependencies on their own. All kube-*.service services have a preset of “disable”, so even if they are present, this doesn’t have any effect without further user action. Even if they were split out to a separate package, we wouldn’t want to change the preset, so the user would still need to take some action to enable them. So I don’t see any technical reason to split them out to a separate package.

The primary effect will be changes to some of the kubernetes-related rpms, but there will not be any effects to existing functionality or configuration.

It isn’t clear how upgrades will be handled. Will the right packages be installed on updates?

Hmm, so what is the scope of this change really? Rename kubernetes-master to kubernetes? (And possibly split out kubernetes-services?).

I would really love to see some feedback from people actually using this whether the change makes sense to them.

6

Thanks for the thoughtful response. I need to wait a day before responding in detail (recovering from minor surgery related anaesthesia so my thinking may be less clear than usual!) .

The mapping of old to new packages would be:

  1. kubernetes-client → kubernetes-client
  2. kuberntes-master → kubernetes-services (i suspect that this gets negligible use since modern installs of kubernetes deploys these services as static pods to the control plan (mostly).
  3. kubernetes-node and kuberntes-kubeadm → kubernetes

Installing the old kubernetes rpm results in kubernetes-client, kubernetes-node, and kubernetes-master.

More later

best regards

1 Like
7

First off propasal looks awesome, One question I have is this restructure include “GitHub - kubernetes-client/python: Official Python client library for kubernetes” as well ? I was checking current “kubernetes” spec file and I did not see any python package. If I miss please let me know but having clear name for that also would be beneficial for people write their workflow via python/api code or opening the possibilities to add other packages depends on python.

Thank you.

8

@thunderbirdtr - thanks for the question and comment. The kubernetes-client rpm only includes the kubectl command line client and supporting man pages. The python 'kubernetes client" is available as python3-kubernetes. This python client library, like kubectl, interacts with a kubernetes cluster via the standard API (provided by the kube-apiserver static pod in the cluster) allowing python developers to create software that interacts with a cluster in some way. I do not maintain the python client.

You raise an interesting question about naming. The kubernetes-client name was chosen by package maintainers several years before I became involved. The upstream kubernetes team also provides client libraries for java, c, ruby and others in addition to the python library you reference. Since there is also a kubernetes-kubeadm rpm one option might be kubernetes-kubectl, although this name seems to be somewhat redundant.

The upstream kubernetes team names their rpms as kubelet, kubeadm, and kubectl. I think Ubuntu adopts a similar naming convention.

I like having a ‘kubernetes’ rpm. The name is clear and well known. A main focus of this proposal is to actually install all the needed components for a modern cluster using ‘dnf install kubernetes’. That does not happen at the moment :slight_smile: . Since kubectl and kubeadm and kubelet components are subpackages to the main kubernetes package, the subpackage name has to include the ‘kubernetes-’ prefix.

Another option, albeit lengthy, kubernetes-commandline-client. I also considered kubernetes-cli at one point but stayed with ‘-client’ to respect the decisions of the earlier maintainers.

9

Actually, I kind of like ‘kubernetes-cli-client’. A bit long perhaps but clearly differentiates from the other clients kubernetes has such as the python client library.

10

It is not perfectly clear what is your intended meaning of has to include here.
In case you mean that it is technically not possible, that is not true.
See RPM reference’s Spec file format, section %package [-n]<name>:

By default subpackages are named by prepending the main package name followed by a dash to the subpackage name(s), ie <mainname>-<subname>. Using the -n option allows specifying an arbitrary (sub-)package name.

(I do not mean to suggest that this feature should be used in this case.
I am just commenting on RPM features and their (lack of) limitations.)

11

Thank you! Very helpful and much appreciated.

best regards

12

Is there a consensus on the package naming?

13

I will be using:

  • kubernetes - the main package. Installs kubelet and kubeadm. Recommends the client sub-package resulting in all the necessary software to install and run kubernetes on a node.
  • kubernetes-client - a sub-package containing kubectl - the command-line client used to manage remote kubernetes clusters.
  • kubernetes-systemd - legacy systemd units for kubernetes services. Not needed when using kubeadm to install kubernetes. Available for those who want to install kubernetes “the hard way ”.

Please let me know if you have any concerns or comments.

thanks

14

Hi Brad, I will give it a try. Would prefer to make it work with fedora packages instead of kubeadm…

15

hi Roman - I have not yet pushed the updated packages into the Fedora repository. I have been testing to make sure the obsoletes and provides are working as intended. I will place them in a COPR repository tomorrow and push the link here and elsewhere for any interested parties to test.

best regards

1 Like
16

Hi Brad @buckaroogeek I tagged you in a discussion about a draft article I am writing for deploying kubernetes 1.26 on fedora 38. It works well.

I did not use the kubernetes-systemd package since the article was supposed to be as short as possible and kubeadm does a good job as long as we use the proper configuration files. There is probably a reason for doing this. Maybe kubernetes should be deployed on other systems as well that don’t use systemd, I don’t know. Thank you for the help.

17

Good morning, I think this proposal would bring clarity to the kubernetes installation guides. Because of the kubernetes packages version skew and the fact that kubeadm updates only the kubelet configuration but not kubelet itself could create confusion for administrators. Having both in the same package would eliminate a lot of these cases and nowadays when kubernetes issues a new version each week, updating properly and fast is becoming a concern.

I also like that you keep the systemd package as well… There are a lot of beta changes in kubeadm that are not properly documented and confusion… Like for example deprecated cli arguments that were replaced with file configurations that are still in the alpha/beta state. So I understand why kubernetes experts might want to retain this package to avoid lockign themselves to kubeadm configuration changes.

All the best

18

Closing change proposals for F40. The ship has sailed. Of course we can still discuss if needed, but please open new topics for that.