kubernetes-cni depends on kubelet #2952
Description
What happened:
When installing kubernetes-cni rpm package, it pulls in kubelet package as a dependency.
What you expected to happen:
kubernetes-cni is a standalone package that installs CNI plugins. This way it could be reused as a source of CNI plugins for containerd.
How to reproduce it (as minimally and precisely as possible):
N/A, see https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64/repodata/primary.xml, the kubernetes-cni package declares:
<rpm:requires>
<rpm:entry name="kubelet"/>
</rpm:requires>
Eventually, add the RPM repo to the system as described in https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ and run yum install kubernetes-cni:
Dependencies resolved.
==============================================================================================================================================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================================================================================================================================
Installing:
kubelet x86_64 1.18.4-0 kubernetes 38 M
Installing dependencies:
conntrack-tools x86_64 1.4.4-10.el8 XXX 204 k
libnetfilter_cthelper x86_64 1.0.0-15.el8 XXX 24 k
libnetfilter_cttimeout x86_64 1.0.0-11.el8 XXX 24 k
libnetfilter_queue x86_64 1.0.4-3.el8 XXX 31 k
socat x86_64 1.7.4.1-1.el8 XXX 323 k
Transaction Summary
==============================================================================================================================================================================================================================================
Install 6 Packages
Total download size: 39 M
BTW, see how it resolves to using kubelet version 1.18.4, which is certainly not the newest out there...
Anything else we need to know?:
Consider the following install flow / dependencies in an air-gapped environment:
- install containerd, which requires CNI plugins to spawn containers
- run image registry as a standalone container to host Kubernetes container images
- install Kubernetes pointing to the local image registry
It seems reasonable to share CNI plugins binaries between containerd and Kubernetes. However, it doesn't seem reasonable to pre-install kubelet before the Kubernetes installation step actually takes place. Breaking down the cyclic dependency between kubelet and kubernetes-cni in favor of just one-way (kubelet depends on kubernetes-cni) seems to be a better idea, at least for an outsider.
Furthermore: it's hard to understand why would kubelet in it's current shape depend on the CNI plugins directly AT ALL. In theory, the CNI and CRI interfaces should abstract out all network operations. Are there some implementation aspects that dictate otherwise? Or is this rather a historical issue (Kubernetes admins expecting automatic CNI upgrades?)?
I was trying to chase down the history of this dependency and at some point in time there's been a decision to bundle CNI plugins within kubelet and deprecate kubernetes-cni (#1309). I didn't found rationale for this decision. Then later on this has been partially undone in #1375. From the context it's not clear though what's the origin of that dependency and what's the rationale for the current state of things.
Environment:
- Cloud provider or hardware configuration: N/A
- OS (e.g:
cat /etc/os-release): any RHEL/Fedora - Kernel (e.g.
uname -a): N/A - Others: N/A