kubernetes-cni depends on kubelet

[lewandom]

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[lewandom]

Still true for kubernetes-cni 1.2.0.

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

The kubernetes-cni package published to the official Kubernetes repos (pkgs.k8s.io) doesn't have this dependency.
/close

[k8s-ci-robot]

@xmudrii: Closing this issue.

In response to this:

The kubernetes-cni package published to the official Kubernetes repos (pkgs.k8s.io) doesn't have this dependency.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.