ADR-022, from docs/DECISIONS.md in the QuantyKube repository.
Status In force
Every Kubernetes network, Flannel, Calico, Cilium and the rest, is
installed as a CNI configuration in /etc/cni/net.d and plugin binaries
in /opt/cni/bin, and every runtime runs them the same way: the pod's
network namespace and the command in the environment, the configuration
on stdin, the result on stdout. This runtime does the same with the
first configuration by name, adds a pod after creating its namespaces
and deletes it when the pod stops, in reverse plugin order, with the
result of the add. A pod whose network cannot be set up is not created.
Each pod's loopback is brought up by the runtime itself when the
namespace is made, so containers of a pod reach each other on
127.0.0.1 with or without a CNI network.
Status reports NetworkReady only once a configuration exists, which is how the kubelet learns that the network add-on has been installed.
The configuration is looked for until one is found, so a network add-on installed after the runtime started, as they usually are, is picked up.
The cost: once found, the configuration is kept, where containerd
watches the directory; a changed network needs a restart of the
runtime. CNI's CHECK and GC commands are not run, and of the plugin
capabilities only port mappings are passed, to plugins such as
portmap that declare them, which is how a pod's hostPort works.