1 00:00:00,180 --> 00:00:03,080 Hello and welcome to this lecture in this lecture 2 00:00:03,090 --> 00:00:06,980 We look at Container networking interface. 3 00:00:06,990 --> 00:00:13,770 So far, we saw how network namespace work as in how to create an isolated network namespace environment 4 00:00:13,860 --> 00:00:15,570 within our system. 5 00:00:15,570 --> 00:00:20,190 we saw how to connect multiple such namespaces through a bridge network, 6 00:00:20,190 --> 00:00:26,310 how to create Virtual cables, or pipes with virtual interfaces on either end, and then how to attach each 7 00:00:26,400 --> 00:00:27,680 end to a namespace 8 00:00:27,690 --> 00:00:28,930 and the bridge. 9 00:00:28,940 --> 00:00:34,770 We then saw how to assign ip and bring them up. And finally enable NAT or IP Masquerade for external 10 00:00:34,770 --> 00:00:36,680 communication etc. 11 00:00:36,870 --> 00:00:40,810 We then saw how Docker did it for its bridge networking option. 12 00:00:40,830 --> 00:00:45,830 It was pretty much the same way except that it uses different naming patterns. 13 00:00:45,930 --> 00:00:53,550 Well other container solutions solve the networking challenges in kind of the same way like rocket or 14 00:00:53,640 --> 00:01:00,780 Mesos Containerizer or any other solutions that work with containers and requires to configure networking 15 00:01:00,780 --> 00:01:02,560 between them like Kubernetes. 16 00:01:02,850 --> 00:01:09,990 If we are all solving the same networking challenges, by researching and finally identifying a 17 00:01:09,990 --> 00:01:16,350 similar approach with our own little minor differences why code and develop the same solution multiple 18 00:01:16,350 --> 00:01:17,370 times? 19 00:01:17,370 --> 00:01:22,330 Why not just create a single standard approach that everyone can follow? 20 00:01:22,410 --> 00:01:28,020 So we take all of these ideas from the different solutions and move all the networking portions of it 21 00:01:28,170 --> 00:01:30,510 into a single program or code 22 00:01:31,290 --> 00:01:35,440 And since this is for the bridge network we call it bridge. 23 00:01:35,460 --> 00:01:41,280 So we created a program or a script that performs all the required tasks to get the container attached 24 00:01:41,310 --> 00:01:42,840 to a bridge network. 25 00:01:42,840 --> 00:01:49,410 For example you could run this program using its name bridge and specify that you want to add this container 26 00:01:49,620 --> 00:01:51,730 to a particular network namespace. 27 00:01:51,790 --> 00:01:57,060 The bridge program takes care of the rest so that the container runtime environments are relieved of 28 00:01:57,060 --> 00:01:58,160 those tasks. 29 00:01:58,170 --> 00:02:03,870 For example, whenever rkt or kubernetes creates a new container, they call the bridge plugin and pass the 30 00:02:03,870 --> 00:02:08,690 container id and namespace to get networking configured for that container. 31 00:02:08,700 --> 00: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 32 00:02:15,090 --> 00:02:16,080 doing so. 33 00:02:16,080 --> 00:02:18,810 What arguments and commands should it support. 34 00:02:19,320 --> 00:02:24,060 How do you make sure the program you create will work correctly with these run times. 35 00:02:24,060 --> 00:02:31,220 How do you know container run times like kubernetes or rkt will invoke your program correctly. 36 00:02:31,290 --> 00:02:38,040 That’s where we need some standards defined. A standard that defines , how a programe should look, how container 37 00:02:38,040 --> 00:02:44,220 runtime will invoke them so that everyone can adhere to a single set of standards and develop solutions 38 00:02:44,340 --> 00:02:46,880 that work across runtime. 39 00:02:47,280 --> 00:02:54,570 That’s where container network interface comes in. The CNI is a set of standards that define how programs 40 00:02:54,690 --> 00:03:00,330 should be developed to solve networking challenges in a container runtime environment. 41 00:03:00,330 --> 00:03:03,230 The programs are referred to as plugins. 42 00:03:03,300 --> 00:03:11,010 In this case bridge program that we have been referring to is a plugin for CNI. CNI defines how the 43 00:03:11,150 --> 00:03:18,750 plugin should be developed and how container run times should invoke them. CNI defines a set of responsibilities 44 00:03:18,780 --> 00:03:22,820 for container run times and plugin. For container runtimes 45 00:03:23,070 --> 00:03:28,950 CNI specifies that it is responsible for creating a network namespace for each container. 46 00:03:29,160 --> 00:03:34,950 It should then identify the networks the container must attach to container runtime must then invoke 47 00:03:34,950 --> 00:03:35,790 the plugin. 48 00:03:35,850 --> 00:03:41,970 When a container is created using the ADD command and also invoke the plugin when the container is deleted 49 00:03:42,090 --> 00:03:49,220 using the Del command. It also specifies how to configure in network plugin on the container runtime environment. 50 00:03:49,290 --> 00:03:56,340 using a JSON file. On the plugin side, it defines that the plugin should support Add, Del and check command 51 00:03:56,340 --> 00:04:02,150 line arguments and that these should accept parameters like container and network namespace. 52 00:04:02,270 --> 00:04:08,640 The plugin should take care of assigning IP addresses to the PODs and any associated routes required 53 00:04:08,640 --> 00:04:11,950 for the containers to reach other containers in the network. 54 00:04:12,270 --> 00:04:17,100 At the end the results should be specified in a particular format. 55 00:04:17,100 --> 00:04:23,250 As long as the container runtime and plugins adhere to these standards they can all live together 56 00:04:23,430 --> 00:04:24,590 in harmony. 57 00:04:24,840 --> 00:04:27,840 Any runtime should be able to work with any plugin. 58 00:04:28,960 --> 00:04:37,570 CNI comes with a set of supported plugins already. Such as bridge, VLAN, IPVLAN, MACVLAN, one for windows. 59 00:04:38,380 --> 00:04:42,850 As well as IPAM plugins like host-local and dhcp. 60 00:04:43,060 --> 00:04:47,080 There are other plugins available from third party organizations as well. 61 00:04:47,080 --> 00:04:57,640 Some examples are weave, flannel, cilium, Vmware NSX, Calico, Infoblox etc. All of these container runtimes 62 00:04:57,760 --> 00:05:04,360 implement CNI standards. So any of them can work with any of these plugins. But there is one that is not 63 00:05:04,360 --> 00:05:13,940 in this list. Docker does not implement CNI. Docker has its own set of standards known as CNM which 64 00:05:13,940 --> 00:05:19,930 stands for Container Network Model which is another standard that aims at solving container networking 65 00:05:19,940 --> 00:05:22,040 challenges similar to CNI 66 00:05:22,040 --> 00:05:28,040 but with some differences. Due to the differences these plugins don’t natively integrate with Docker. 67 00:05:28,400 --> 00:05:34,850 meaning you can’t run a docker container and specify the network plugin to use is CNI and specify one 68 00:05:34,850 --> 00:05:39,670 of these plugins but that doesn't mean you can't use Docker with CNI at all. 69 00:05:39,830 --> 00:05:41,900 You just have to work around it yourself. 70 00:05:41,900 --> 00:05:48,320 For example create a docker container without any network configuration and then manually invoke the 71 00:05:48,320 --> 00:05:54,890 the bridge plugin yourself. That is pretty much how kubernetes does it. 72 00:05:54,970 --> 00:06:00,260 When kubernetes creates docker containers it creates them on the none network. 73 00:06:00,400 --> 00:06:06,030 It then invokes the configured CNI plugins who takes care of the rest of the configuration. 74 00:06:06,130 --> 00:06:09,930 We talk about CNI in Kubernetes in the upcoming lectures.