Container Network Interface (CNI) Explained in 7 Minutes

In this lecture, we look at Container Networking interfaces.
Access the full course here: kodekloud.com/courses/certifi...
🆓Join our Slack Community for FREE: kode.wiki/JoinOurSlackCommunity
So far, we saw how network namespaces work.
We then saw how docker did it for its bridge networking option.
If we are ALL solving the same networking challenges, by researching and finally identifying a similar approach with our own little minor differences, why code and develop the same thing multiple times? Why not just create a single standard approach that everyone can follow?
Container Networking Interface takes ideas from all of these different solutions and moves all the networking portion of it, into a single program or code.
So what if you wanted to create such a program for yourself? Maybe for a new networking type. If you were doing so, what arguments and commands should it support? How do you make sure the program you create will work correctly with these runtimes? How do you know container run times like Kubernetes or it will invoke your program correctly?
That’s where the container network interface comes in. The CNI is a set of standards that define how programmes should be developed to solve networking challenges in container runtime environments. The programmes are referred to as Plugins. In this case, bridge programe that we have been referring to is a plugin for CNI. CNI defines how the plugin should be developed, and how container runtimes should invoke them.
CNI defines a set of responsibilities for container run times and plugins. For container runtimes, CNI specifies that it is responsible for creating a network namespace for each container. It should then identify the networks the container must attach to. Container runtime must then invoke the plugin when a container is created using the ADD command, and also invoke the plugin when the container is deleted using the Del command. It also specifies how to configure a network plugin on the container runtime environment using a JSON file.
On the plugin side, it defines that the plugin should support Add, Del and check command-line arguments and that these should accept parameters like container and network ns. The plugin should take care of assigning IP addresses to the PODs and any associated routes required for the containers to reach other containers in the network. In the end, the results should be specified in a particular format.
CNI comes with a set of supported plugins already. Such as bridge, VLAN, IPVLAN, MACVLAN, one for windows. As well as IPAM plugins like host-local and dhcp. There are other plugins available from 3rd party organizations as well. Some examples are weave, flannel, cilium, Vmware NSX, Calico, Infoblox, etc.
#ContainerNetworkInterface #KodeKloud

[@KodeKloud]

Learn, practice, and get certified on Kubernetes: kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests/

[@user-jz1li2th4s]

clears up so much in such a short time, thank you

[@markjenkins1217]

Extremely interesting, look forth to visiting again.

[@cloudnativeeverything622]

Great explanation, thanks!

[@iammrchetan]

Always learn something by watching Mumshad's videos. Good job!

[@nadirzdf]

Great work, buddy!

[@VijayBhaskarChintalapati]

Quite impressed, thanks for the putting up this video!

[@KodeKloud]

Greetings! Thank you for your kind words. Spread the word by liking, sharing and subscribing to our channel! Cheers :).

[@Fitnessdealnews]

Well done

[@akash3662]

How does VMware NSX support Container networking?

[@saivenkataratnamemmani1936]

could you please explain the CNI in layman's terms.

[@MagnumCarta]

Container wants to talk to other processes. Container doesn't get networking permission automatically. CNI provides the contract for containers to have supported networking services. The particular CNI (e.g. Calico, Cilium, Flannel, etc) handles the responsibility of IP addressing management for the container. You would pick between different CNIs because they have different problem sets they are trying to solve but require networking services. Cilium was sort of the first on the scene to support eBPF, flannel is to set up an easy "network fabric" (basically a large subnet of IP addresses), Calico is for network policy for role based auth, etc.

[@diegonayalazo]

Thanks

[@KodeKloud]

Welcome!