Description of problem: If you install Kubernetes on a simple single node cluster on a baremetal Fedora 30 Minimal server with "dnf install kubernetes-cni containerd" (from Fedora) created by "kubeadm init --pod-network-cidr=10.10.0.0/16" following https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/, after get to the step where you do the step on https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ for Installing a pod network add-on, you'll eventually get to a point where the kubedns Pod remains stuck in STATUS ContainerCreating. A kubectl -n kube-system describe pod coredns-... and/or kubectl -n kube-system logs coredns-... will show: failed to find plugin "loopback" in path [/opt/cni/bin] This is because two packages, both shipped by Fedora, disagree on where Container Networking Interface (CNI) binaries should be: containernetworking-plugins (AKA kubernetes-cni) puts loopback (as well as bandwidth bridge dhcp firewall flannel host-device host-local ipvlan loopback macvlan portmap ptp sample sbr static tuning vlan) into /usr/libexec/cni/. containerd by default expects them in /opt/cni/bin. I can locally work around this by adding this to /etc/containerd/config.toml: [plugins.cri] [plugins.cri.cni] bin_dir = "/usr/libexec/cni/" It seems to me that this should be included out of the box in the package. If someone would like to guide me how to contribute this as a fix to Fedora, if there is a agreement that this would be the right way to fix this, then I may be interested in learning how to do this via this bug. Version-Release number of selected component (if applicable): * containerd 1.2.4-1.fc30 @fedora * containernetworking-plugins 0.8.1-1.fc30 @updates
I should probably mention that I have installed current Kubernetes 1.15.1 using "yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes" as per kubernetes.io/docs, after adding /etc/yum.repos.d/kubernetes.repo which pulls from https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64, so this is not using the kubernetes package from Fedora.. just because at 1.13.5-1.fc30 that seems way behind, and pulls that old docker 2:1.13.1-67 and what not, instead of modern containerd. Hopefully it's not crazy to expect that "dnf install containerd containernetworking-plugins" provides a consistent base in Fedora on top of which one can install Kubernetes from kubernetes.io instead of the old Fedora package.
I agree that if containerd is looking for those binaries it should be aware of the path Fedora ships them in. The quick fix would be to include your config workaround in the default config file, but I think it would be better to patch the code to look in the right place. If you have a patch file that does that, you can submit it as a pull request to https://src.fedoraproject.org/rpms/containerd. Should containerd also depend on containernetworking-plugins? Lokesh, I'd love your input here as well since you maintain containernetworking-plugins.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is still present in F34 containerd-1.5.3-1.fc34.x86_64: $ containerd config default | grep bin_dir bin_dir = "/opt/cni/bin" With this option, the "localhost" plugin cannot be found, and on a newly instaled k8s the coredns containers do not start up. The workaroud is either to edit the config file (set bin_dir="/usr/libexec/cni"), or create a symlink /opt/cni/bin -> /usr/libexec/cni.
FEDORA-2022-3e447ed7c1 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3e447ed7c1
FEDORA-2022-3e447ed7c1 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
This issue still exist on Fedora 37, I created link of "bridge" to make my kubernetes working. [root@fedora bin]# uname -a Linux fedora.rvsoni.com 6.1.18-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Mar 11 16:09:14 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux [root@fedora bin]# pwd /opt/cni/bin [root@fedora bin]# ll total 189864 -rwxr-xr-x. 1 root root 3797127 Mar 19 11:57 bandwidth lrwxrwxrwx. 1 root root 23 Mar 19 14:15 bridge -> /usr/libexec/cni/bridge -rwsr-xr-x. 1 root root 58163972 Mar 19 11:57 calico -rwsr-xr-x. 1 root root 58163972 Mar 19 11:57 calico-ipam -rwxr-xr-x. 1 root root 2342446 Mar 19 14:03 flannel -rwxr-xr-x. 1 root root 3263146 Mar 19 11:57 host-local -rwsr-xr-x. 1 root root 58163972 Mar 19 11:57 install -rwxr-xr-x. 1 root root 3319375 Mar 19 11:57 loopback -rwxr-xr-x. 1 root root 3700953 Mar 19 11:57 portmap -rwxr-xr-x. 1 root root 3477510 Mar 19 11:57 tuning [root@fedora bin]# ll /usr/libexec/cni/ total 52380 -rwxr-xr-x. 1 root root 2965048 Mar 8 16:31 bandwidth -rwxr-xr-x. 1 root root 3309544 Mar 8 16:31 bridge -rwxr-xr-x. 1 root root 8115296 Mar 8 16:31 dhcp -rwxr-xr-x. 1 root root 3402048 Mar 8 16:31 firewall -rwxr-xr-x. 1 root root 2970016 Mar 8 16:31 host-device -rwxr-xr-x. 1 root root 2477896 Mar 8 16:31 host-local -rwxr-xr-x. 1 root root 3056040 Mar 8 16:31 ipvlan -rwxr-xr-x. 1 root root 2578752 Mar 8 16:31 loopback -rwxr-xr-x. 1 root root 3084936 Mar 8 16:31 macvlan -rwxr-xr-x. 1 root root 2898840 Mar 8 16:31 portmap -rwxr-xr-x. 1 root root 3193672 Mar 8 16:31 ptp -rwxr-xr-x. 1 root root 2167872 Mar 8 16:31 sample -rwxr-xr-x. 1 root root 2731104 Mar 8 16:31 sbr -rwxr-xr-x. 1 root root 2209360 Mar 8 16:31 static -rwxr-xr-x. 1 root root 2644784 Mar 8 16:31 tuning -rwxr-xr-x. 1 root root 3056016 Mar 8 16:31 vlan -rwxr-xr-x. 1 root root 2743296 Mar 8 16:31 vrf [root@fedora bin]#
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days