Relation between Kubernetes and CNI
dilyanpalauzov opened this issue · comments
https://www.cni.dev/docs/#who-is-using-cni says that both Kubernetes and CRI-O use CNI.
https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#installation says that Kubernetes loads a Container Runtime, like cri-o, and the latter utilizes CNI.
For me the second citation means that Kubernetes is not using CNI, as the container runtime can choose any (non-CNI) mechanism to utilize the network connectivity. Moreover, when the CNI configuration is loaded, the loader searches for networks with particular "name": under /etc/cni/net.d/. This name cannot be passed to kubelet or kube-proxy.
On the other side, https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#loopback-cni requires utilizig a loopback CNI plugin, and the only plugin without "name": at https://github.com/cri-o/cri-o/tree/main/contrib/cni is 99-loopback.conf.
That said, it is unclear if and how Kubernetes uses CNI.
Yeah I agree the relationship is kind of weird. Both containerd and CRI-O use CNI under the hood, and it's become the defacto stanard for kubernetes. but it is really the CRI implementation that uses it. Theoretically, either cri implementation could setup networking without CNI and kubernetes should work fine.
I suggest either to remove Kubernetes from https://www.cni.dev/docs/#who-is-using-cni, or write (indirectly via the Container Runner) after it.