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