Understanding CNI (Container Network Interface) - laying out the essential bits

Is CNI, a piece of software or just a set of standard rules?

It's both. But to some, it may not be very straight forward from the way that is put in the readme here.

So if CNI is also a piece of software, how does the Container Runtime Engine use it to communicate with a CNI Plugin?

That's where the library called libcni comes into picture. This is the library that allows the container runtime engine to interact with the CNI plugin through a set standard set of verbs namely ADD, DEL, CHECK and VERSION.

While it has been abundantly mentioned that both the container engine and the CNI plugin communicate through a JSON specification file (as illustrated above), we've never had the convenience of directly being told that:

it (libcni) is typically bundled into runtime providers (i.e. containerd or cri-o would use this before calling runc or hcsshim).?It is also bundled into CNI providers (CNI plugins) as well, for example, to add an IP to a container, to parse the configuration of the CNI and so on.

unless, of course, one had the fortitude to go all the way into repository files and unlock the wisdom preserved within the comments.

Yet, none of the above information can explain one thing - How does the containe engine know where to access the CNI plugin?

Going through some documentations, eventually, I could figure that there are generally two main paths where the Container Engine finds its plugins by default, namely:

/opt/cni/bin and /etc/cni/net.d        

Take the case of the EKS Cluster which uses containerd (as the container engine) and vpc-cni (as the CNI plugin). In the readme for vpc-cni, it's instructed to ensure the above mentioned default paths are set against certain kubelet parameters concerning CNI.

Similarly, going through the amazon-eks-ami files, it does look like containerd is directed to look into the same paths for operations concerning the CNI plugin.

Here're some screenshots, for a quick peak or incase, the links are broken:

So, I believe it's possibly accurate to assume that the container engine simply makes calls to the plugin executables present in directories within the set path (/opt/cni/bin) without concerning itself with the exact choice of the plugin.

And similarly, the CNI plugins perform the various network operations based on the specified configurations within the configured path (/etc/cni/net.d) regardless of the runtime engine.

Thanks for reading so far any corrections anywhere in this article if needed are welcome.