What is Container Network Interface (CNI)?
Chronicles of Containers - Part 7
Hey there! 👋
Previous article gave an intro to Container Networking and now I’d like to focus on CNI (Container Network Interface) specifically. If you were ever to deal with a non-Docker runtime, chances are high you’ve heard of it. So, what is it? As usual, first the image and then the details!
(click on image to enlarge)
📵 𝐂𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫𝐬 𝐡𝐚𝐯𝐞 𝐧𝐨 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐯𝐢𝐭𝐲 𝐛𝐲 𝐝𝐞𝐟𝐚𝐮𝐥𝐭 - and this is really interesting! Try starting a container using "containerd" and then try pinging anything outside of it. It doesn't work! And that's because, out of the box, containers come with very few things set up. That's where Container Networking solutions come into game.
🕸 𝐓𝐡𝐞𝐫𝐞 𝐚𝐫𝐞 𝐦𝐚𝐧𝐲 𝐬𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐬 𝐨𝐮𝐭 𝐭𝐡𝐞𝐫𝐞 - Docker uses it's own logic to set up the networking, containerd relies on CNI, whereas Kubernetes allows you to specify your own CRI (Container Runtime Interface) compliant solution.
⚡ 𝐂𝐍𝐈 𝐢𝐬 𝐚 𝐬𝐢𝐦𝐩𝐥𝐞 𝐚𝐧𝐝 𝐲𝐞𝐭 𝐩𝐨𝐰𝐞𝐫𝐟𝐮𝐥 𝐟𝐫𝐚𝐦𝐞𝐰𝐨𝐫𝐤 - although not the ONLY one out there (as can be seen on screenshot above) it appears to be the most popular framework for solving the network configuration problem. And the beauty of it is that it's REALLY SIMPLE. It’s simple because it boils down to specifying a config file and using existing (or writing new) plugins to do the actual work for you.
✏ 𝐃𝐞𝐬𝐜𝐫𝐢𝐛𝐞 𝐲𝐨𝐮𝐫 𝐧𝐞𝐭𝐰𝐨𝐫𝐤 - first step is to create a manifest file (fancy word for a simple JSON config file, really) that describes which interfaces you need, which subnets to use, which ports to open, etc. And this is usually done by your network admin. Here’s the default one I used for testing purposes:
👑 𝐃𝐢𝐯𝐢𝐝𝐞 & 𝐜𝐨𝐧𝐪𝐮𝐞𝐫 - instead of wasting time implementing billion different solutions by itself, CNI went the other route - YOU are supposed to write a program that takes YOUR manifest and does something useful with it. And that program is called "plugin". Luckily for us, there's tons of prebuilt plugins for common scenarios, but if you need something specific you are more than free to write it! Here’s an example of how it looks like now:
Do note two things, though: 1) I specified “—cni” parameter, which tells containerd to use CNI plugin, and 2) it loads manifest file from “/etc/cni/net.d” (and yes, this maps to D:\etc\cni\net.d on Windows :)).
👮♀ 𝐂𝐍𝐈 𝐞𝐧𝐬𝐮𝐫𝐞𝐬 𝐩𝐫𝐨𝐜𝐞𝐬𝐬 𝐢𝐬 𝐜𝐚𝐫𝐫𝐢𝐞𝐝 𝐭𝐡𝐫𝐨𝐮𝐠𝐡 - if you check official CNI website, you will notice that they call it a FRAMEWORK which specifies the format of MANIFEST and how plugins communicate with Runtime. It doesn't say HOW you configure stuff, but it rather ensures there's a common language between Runtime, Containers & Plugins.
And that's pretty much all about it :) CNI works pretty well on Windows and, as such, makes for a great candidate for your container journey ;)
Next article will likely deal a bit more with Container Runtimes, but until then, if you haven’t subscribed already, now’s the time to do so!
P.S. If you missed some of the previous articles, here are the last three that were published:
