1 00:00:01,730 --> 00:00:07,160 Hello and welcome to this lecture and this lecture we discuss about pot networking in Britain, it is 2 00:00:08,060 --> 00:00:13,970 so far we have set up several communities, master and worker nodes and configured networking between 3 00:00:13,970 --> 00:00:14,240 them. 4 00:00:14,240 --> 00:00:17,040 So they are all on a network that can reach each other. 5 00:00:17,450 --> 00:00:22,190 We also made sure the firewall and network security groups are configured correctly to allow for the 6 00:00:22,220 --> 00:00:25,100 Commonwealth control plane components to reach each other. 7 00:00:25,850 --> 00:00:31,580 Assume that we have also set up all the competitors control plane components such as the Cube API server, 8 00:00:31,880 --> 00:00:37,240 the SCD servers, Kubla, etc. and we are finally ready to deploy our applications. 9 00:00:38,000 --> 00:00:41,300 But before we can do that, there is something that we must address. 10 00:00:41,700 --> 00:00:47,960 We talked about the network that connects the nodes together, but there's also another layer of networking 11 00:00:47,960 --> 00:00:52,450 that is crucial to the clusters functioning, and that is the networking at the pod layer. 12 00:00:53,060 --> 00:00:58,220 Our communities cluster is soon going to have a large number of parts and services running on it. 13 00:00:58,610 --> 00:01:00,200 How are the pods addressed? 14 00:01:00,230 --> 00:01:02,020 How do they communicate with each other? 15 00:01:02,030 --> 00:01:07,580 How do you access the services running on these parts internally from within the cluster as well as 16 00:01:07,580 --> 00:01:09,640 externally from outside the cluster? 17 00:01:10,190 --> 00:01:13,430 These are challenges that coordinators expects you to solve. 18 00:01:14,000 --> 00:01:17,900 As of today, that is does not come with a built in solution for this. 19 00:01:18,050 --> 00:01:23,240 It expects you to implement a networking solution that solves these challenges. 20 00:01:23,510 --> 00:01:28,400 However, communities have laid out clearly the requirements for part networking. 21 00:01:28,650 --> 00:01:30,080 Let's take a look at what they are. 22 00:01:30,830 --> 00:01:37,910 Coordinators expects every pod to get its own unique IP address and that every part should be able to 23 00:01:37,910 --> 00:01:42,140 reach every other part within the same node using that IP address. 24 00:01:42,560 --> 00:01:49,430 And every part should be able to reach every other part on other nodes as well using the same IP address. 25 00:01:49,460 --> 00:01:54,740 It doesn't care what IP address that is and what range or subnet it belongs to. 26 00:01:55,130 --> 00:02:01,040 As long as you can implement a solution that takes care of automatically assigning IP addresses and 27 00:02:01,040 --> 00:02:06,290 establish connectivity between the parts in a node as well as pods on different nodes, you're good 28 00:02:06,920 --> 00:02:09,110 without having to configure any natural's. 29 00:02:09,830 --> 00:02:14,600 So how do you implement a model that solves these requirements now? 30 00:02:14,600 --> 00:02:20,120 There are many networking solutions available out there that does this, but we have already learned 31 00:02:20,120 --> 00:02:25,130 about networking concepts, routing IP, address, management namespace and unite. 32 00:02:25,520 --> 00:02:29,390 So let's try to use that knowledge to solve this problem by ourselves. 33 00:02:29,390 --> 00:02:32,750 First, this will help in understanding how other solutions work. 34 00:02:33,050 --> 00:02:38,210 I know there is a bit of repetition, but I'm trying to relate the same concept and approach all the 35 00:02:38,210 --> 00:02:42,650 way from plane network namespace on Linux all the way to coroneted. 36 00:02:43,850 --> 00:02:45,470 So we have a three node cluster. 37 00:02:45,590 --> 00:02:50,750 It doesn't matter which one is master or worker, they all run ports either for management or workload 38 00:02:50,750 --> 00:02:51,350 purposes. 39 00:02:51,860 --> 00:02:56,260 As far as networking is concerned, we're going to consider all of them as the same. 40 00:02:56,510 --> 00:02:58,910 So first, let's plan what we are going to do. 41 00:02:59,510 --> 00:03:05,900 The nodes are part of an external network and has IP addresses in the 192 DOT 168 one dot series. 42 00:03:06,440 --> 00:03:10,210 Node one is assigned 11, node two is twelve and No. 43 00:03:10,220 --> 00:03:11,300 Three is thirteen. 44 00:03:11,900 --> 00:03:17,570 Next step, when containers are created, cornetist creates network namespace spaces for them to enable 45 00:03:17,570 --> 00:03:18,980 communication between them. 46 00:03:18,980 --> 00:03:23,060 We attach these names to a network, but what network? 47 00:03:23,660 --> 00:03:28,360 We have learned about bridge networks that can be created within nodes to attach names spaces. 48 00:03:28,520 --> 00:03:30,980 So we create a network on each node. 49 00:03:32,010 --> 00:03:37,330 And then bring them up, it's time to assign an IP address to the British interfaces or networks. 50 00:03:37,710 --> 00:03:38,970 But what IP address? 51 00:03:39,660 --> 00:03:45,570 We decide that each person network work will be on its own subnet, choose any private address range, 52 00:03:45,660 --> 00:03:50,880 say, ten to forty four point one, 10 to forty four or two and ten to forty for the three. 53 00:03:51,690 --> 00:03:54,420 Next we said the IP address for the bridge interface. 54 00:03:55,110 --> 00:03:56,460 So we have built our base. 55 00:03:56,760 --> 00:04:01,860 The remaining steps are to be performed for each container and every time a new container is created. 56 00:04:02,160 --> 00:04:03,400 So we write a script for it. 57 00:04:03,960 --> 00:04:07,020 Now, you don't have to know any kind of complicated scripting. 58 00:04:07,020 --> 00:04:12,780 It's just a file that has all commands we will be using and we can run this multiple times for each 59 00:04:12,780 --> 00:04:16,400 container going forward to attach a container to the network. 60 00:04:16,410 --> 00:04:19,200 We need a pipe or virtual network cable. 61 00:04:19,440 --> 00:04:24,840 We create that using the IP link, add command, don't focus on the options as they are similar to what 62 00:04:24,840 --> 00:04:26,850 we saw in our previous lectures. 63 00:04:27,360 --> 00:04:29,880 Assume that they are very depending on the inputs. 64 00:04:30,210 --> 00:04:36,210 We then attach one end to the container and another end to the bridge using the IP links that command. 65 00:04:36,750 --> 00:04:42,680 We then assign IP address using the IP ADR command and add a route to the default gateway. 66 00:04:43,410 --> 00:04:45,000 But what IP do we add? 67 00:04:45,120 --> 00:04:49,280 We either manage that ourselves or stored that information in some kind of database. 68 00:04:49,800 --> 00:04:55,650 For now, we will assume it is tendered to forty four point one or two, which is a free IP in the subnet. 69 00:04:56,310 --> 00:05:00,890 We discuss about IP address management in detail in one of the upcoming letters. 70 00:05:01,770 --> 00:05:03,420 Finally, we bring up the interface. 71 00:05:04,870 --> 00:05:10,570 We don't run the same script this time from the second container with its information and gets the container 72 00:05:10,570 --> 00:05:14,800 connected to the network, the two containers can now communicate with each other. 73 00:05:15,310 --> 00:05:20,710 We copy the script to the other nodes and run the script on them to assign IP address and connect those 74 00:05:20,710 --> 00:05:22,920 containers to their own internal networks. 75 00:05:23,830 --> 00:05:26,120 So we have solved the first part of the challenge. 76 00:05:26,650 --> 00:05:32,110 The pods all get their own unique IP address and are able to communicate with each other on their own. 77 00:05:32,110 --> 00:05:37,090 Not the next part is to enable them to reach other parts on other nodes. 78 00:05:37,990 --> 00:05:44,170 So, for example, the pod at 10 to 40 for one or two on node one wants to ping pong, tend to prefer 79 00:05:44,170 --> 00:05:46,310 door to talk to one or two. 80 00:05:46,990 --> 00:05:53,890 As of now, the first has no idea where the addresses tend to 44 to two is because it is on a different 81 00:05:53,890 --> 00:05:55,180 network than its own. 82 00:05:55,660 --> 00:06:00,000 So it routes to Node One's IP as it is said to be the default gateway. 83 00:06:00,280 --> 00:06:04,700 Not one doesn't know either, since ten to forty four to two is a private network. 84 00:06:04,750 --> 00:06:11,770 One not to add a road to node one routing table to road traffic to attend to forty four, door to door 85 00:06:11,770 --> 00:06:17,470 to wire the second nodes IP at 190 to 168, one by 12. 86 00:06:18,340 --> 00:06:22,270 Once the route is added, the blue pod is able to ping across. 87 00:06:22,870 --> 00:06:29,080 Similarly, we configure route on all host to all the other hosts with information regarding the respective 88 00:06:29,080 --> 00:06:30,130 networks within them. 89 00:06:31,210 --> 00:06:37,270 Now this works fine in this simple setup, but this will require a lot more configuration, as in when 90 00:06:37,270 --> 00:06:43,870 your underlying network architecture gets complicated instead of having to configure a route on each 91 00:06:43,870 --> 00:06:44,400 server. 92 00:06:44,810 --> 00:06:51,220 A better solution is to do that on a router if you have one in your network and point all hosts to use 93 00:06:51,220 --> 00:06:52,800 that as the default gateway. 94 00:06:53,080 --> 00:06:58,000 That way you can easily manage wrote to all networks in the routing table on the router. 95 00:06:58,240 --> 00:07:04,430 With that, the individual virtual networks we created with the address tendo 244 1.0. 96 00:07:04,750 --> 00:07:12,950 Twenty four on each node now form a single large network with the address tendo to 44 dot 020 slash 97 00:07:12,980 --> 00:07:13,570 16. 98 00:07:14,470 --> 00:07:16,230 It's time to tie everything together. 99 00:07:16,540 --> 00:07:21,940 We performed a number of manual steps to get the environment ready with the networks and routing tables. 100 00:07:21,940 --> 00:07:27,430 We then wrote a script that can be run for each container that performs the necessary steps required 101 00:07:27,430 --> 00:07:29,530 to connect each container to the network. 102 00:07:29,920 --> 00:07:32,270 And we executed the script manually. 103 00:07:32,590 --> 00:07:37,210 Of course, we don't want to do that, as in large environments where thousands of parts are created 104 00:07:37,210 --> 00:07:37,910 every minute. 105 00:07:38,380 --> 00:07:42,540 So how do we run the script automatically when a part is created on clarinettist? 106 00:07:42,820 --> 00:07:44,260 That's where Cianni comes in. 107 00:07:44,350 --> 00:07:50,530 Acting as the middleman, CNI tells Clarinettist that this is how you should call a script as soon as 108 00:07:50,530 --> 00:07:51,520 you create a container. 109 00:07:51,820 --> 00:07:55,540 And CNN tells us this is how your script should look like. 110 00:07:56,230 --> 00:07:59,980 So we need to modify the script a little bit to meet CNI standards. 111 00:08:00,280 --> 00:08:06,160 It should have an ad section that will take care of adding a container to the network and a delete section 112 00:08:06,160 --> 00:08:11,770 that will take care of deleting container interfaces from the network and freeing the IP address, etc.. 113 00:08:12,310 --> 00:08:13,750 So our script is ready. 114 00:08:14,290 --> 00:08:20,020 The Kubelik on each node is responsible for creating containers whenever the container is created. 115 00:08:20,320 --> 00:08:27,310 The cube that looks at the CNI configuration passed as a command line argument when it was run and identifies 116 00:08:27,310 --> 00:08:28,330 our scripts name. 117 00:08:28,750 --> 00:08:34,450 It then looks in the country's been directory, defined our script and then executes the script with 118 00:08:34,450 --> 00:08:38,020 the ADD command and the name and namespace ID of the container. 119 00:08:38,170 --> 00:08:40,450 And then our script takes care of the rest. 120 00:08:40,780 --> 00:08:46,390 We will look at how and where the CNI is configured and cabinet in the next lecture, along with practice 121 00:08:46,390 --> 00:08:46,750 tests. 122 00:08:47,470 --> 00:08:50,830 For now, the set from the part networking concepts lecture. 123 00:08:51,160 --> 00:08:56,400 Hopefully that should give you enough knowledge on inspecting networking within parts in a cabinet is 124 00:08:56,410 --> 00:08:56,920 cluster. 125 00:08:57,310 --> 00:09:02,530 We will see how other solutions do the same thing that we did in the upcoming lectures.