WEBVTT 00:00.180 --> 00:03.080 Hello and welcome to this lecture in this lecture 00:03.090 --> 00:06.980 We look at Container networking interface. 00:06.990 --> 00:13.770 So far, we saw how network namespace work as in how to create an isolated network namespace environment 00:13.860 --> 00:15.570 within our system. 00:15.570 --> 00:20.190 we saw how to connect multiple such namespaces through a bridge network, 00:20.190 --> 00:26.310 how to create Virtual cables, or pipes with virtual interfaces on either end, and then how to attach each 00:26.400 --> 00:27.680 end to a namespace 00:27.690 --> 00:28.930 and the bridge. 00:28.940 --> 00:34.770 We then saw how to assign ip and bring them up. And finally enable NAT or IP Masquerade for external 00:34.770 --> 00:36.680 communication etc. 00:36.870 --> 00:40.810 We then saw how Docker did it for its bridge networking option. 00:40.830 --> 00:45.830 It was pretty much the same way except that it uses different naming patterns. 00:45.930 --> 00:53.550 Well other container solutions solve the networking challenges in kind of the same way like rocket or 00:53.640 --> 01:00.780 Mesos Containerizer or any other solutions that work with containers and requires to configure networking 01:00.780 --> 01:02.560 between them like Kubernetes. 01:02.850 --> 01:09.990 If we are all solving the same networking challenges, by researching and finally identifying a 01:09.990 --> 01:16.350 similar approach with our own little minor differences why code and develop the same solution multiple 01:16.350 --> 01:17.370 times? 01:17.370 --> 01:22.330 Why not just create a single standard approach that everyone can follow? 01:22.410 --> 01:28.020 So we take all of these ideas from the different solutions and move all the networking portions of it 01:28.170 --> 01:30.510 into a single program or code 01:31.290 --> 01:35.440 And since this is for the bridge network we call it bridge. 01:35.460 --> 01:41.280 So we created a program or a script that performs all the required tasks to get the container attached 01:41.310 --> 01:42.840 to a bridge network. 01:42.840 --> 01:49.410 For example you could run this program using its name bridge and specify that you want to add this container 01:49.620 --> 01:51.730 to a particular network namespace. 01:51.790 --> 01:57.060 The bridge program takes care of the rest so that the container runtime environments are relieved of 01:57.060 --> 01:58.160 those tasks. 01:58.170 --> 02:03.870 For example, whenever rkt or kubernetes creates a new container, they call the bridge plugin and pass the 02:03.870 --> 02:08.690 container id and namespace to get networking configured for that container. 02:08.700 --> 02:15.090 So what if you wanted to create such a program for yourself? May be for a new networking type. If you where 02:15.090 --> 02:16.080 doing so. 02:16.080 --> 02:18.810 What arguments and commands should it support. 02:19.320 --> 02:24.060 How do you make sure the program you create will work correctly with these run times. 02:24.060 --> 02:31.220 How do you know container run times like kubernetes or rkt will invoke your program correctly. 02:31.290 --> 02:38.040 That’s where we need some standards defined. A standard that defines , how a programe should look, how container 02:38.040 --> 02:44.220 runtime will invoke them so that everyone can adhere to a single set of standards and develop solutions 02:44.340 --> 02:46.880 that work across runtime. 02:47.280 --> 02:54.570 That’s where container network interface comes in. The CNI is a set of standards that define how programs 02:54.690 --> 03:00.330 should be developed to solve networking challenges in a container runtime environment. 03:00.330 --> 03:03.230 The programs are referred to as plugins. 03:03.300 --> 03:11.010 In this case bridge program that we have been referring to is a plugin for CNI. CNI defines how the 03:11.150 --> 03:18.750 plugin should be developed and how container run times should invoke them. CNI defines a set of responsibilities 03:18.780 --> 03:22.820 for container run times and plugin. For container runtimes 03:23.070 --> 03:28.950 CNI specifies that it is responsible for creating a network namespace for each container. 03:29.160 --> 03:34.950 It should then identify the networks the container must attach to container runtime must then invoke 03:34.950 --> 03:35.790 the plugin. 03:35.850 --> 03:41.970 When a container is created using the ADD command and also invoke the plugin when the container is deleted 03:42.090 --> 03:49.220 using the Del command. It also specifies how to configure in network plugin on the container runtime environment. 03:49.290 --> 03:56.340 using a JSON file. On the plugin side, it defines that the plugin should support Add, Del and check command 03:56.340 --> 04:02.150 line arguments and that these should accept parameters like container and network namespace. 04:02.270 --> 04:08.640 The plugin should take care of assigning IP addresses to the PODs and any associated routes required 04:08.640 --> 04:11.950 for the containers to reach other containers in the network. 04:12.270 --> 04:17.100 At the end the results should be specified in a particular format. 04:17.100 --> 04:23.250 As long as the container runtime and plugins adhere to these standards they can all live together 04:23.430 --> 04:24.590 in harmony. 04:24.840 --> 04:27.840 Any runtime should be able to work with any plugin. 04:28.960 --> 04:37.570 CNI comes with a set of supported plugins already. Such as bridge, VLAN, IPVLAN, MACVLAN, one for windows. 04:38.380 --> 04:42.850 As well as IPAM plugins like host-local and dhcp. 04:43.060 --> 04:47.080 There are other plugins available from third party organizations as well. 04:47.080 --> 04:57.640 Some examples are weave, flannel, cilium, Vmware NSX, Calico, Infoblox etc. All of these container runtimes 04:57.760 --> 05:04.360 implement CNI standards. So any of them can work with any of these plugins. But there is one that is not 05:04.360 --> 05:13.940 in this list. Docker does not implement CNI. Docker has its own set of standards known as CNM which 05:13.940 --> 05:19.930 stands for Container Network Model which is another standard that aims at solving container networking 05:19.940 --> 05:22.040 challenges similar to CNI 05:22.040 --> 05:28.040 but with some differences. Due to the differences these plugins don’t natively integrate with Docker. 05:28.400 --> 05:34.850 meaning you can’t run a docker container and specify the network plugin to use is CNI and specify one 05:34.850 --> 05:39.670 of these plugins but that doesn't mean you can't use Docker with CNI at all. 05:39.830 --> 05:41.900 You just have to work around it yourself. 05:41.900 --> 05:48.320 For example create a docker container without any network configuration and then manually invoke the 05:48.320 --> 05:54.890 the bridge plugin yourself. That is pretty much how kubernetes does it. 05:54.970 --> 06:00.260 When kubernetes creates docker containers it creates them on the none network. 06:00.400 --> 06:06.030 It then invokes the configured CNI plugins who takes care of the rest of the configuration. 06:06.130 --> 06:09.930 We talk about CNI in Kubernetes in the upcoming lectures.