WEBVTT 00:02.610 --> 00:04.940 Hello and welcome to this lecture in this lecture 00:04.950 --> 00:12.440 We will discuss about one solution based on CNI in particular WeaveWorks. The WeaveWorks 00:12.470 --> 00:15.790 WeaveWorks weave CNI plugin. In the previous practice test, 00:15.840 --> 00:17.630 We saw how it is configured. 00:17.820 --> 00:20.640 Now we will see more details about how it works. 00:20.640 --> 00:26.910 We will start where we left off in the POD Networking Concepts section. We had our own custom CNI script 00:27.000 --> 00:33.270 that we built and integrated into kubelet through CNI. In the previous lecture we saw how, instead 00:33.270 --> 00:39.750 of our custom script, we can integrate the weave plugin. Let us now see how the weave solution works, 00:39.870 --> 00:42.900 as it is important to understand at least one solution 00:42.900 --> 00:47.010 well. You should then be able to relate this to other solutions as well. 00:47.010 --> 00:52.860 So the networking solution we set up manually had a routing table which mapped what networks are on 00:52.860 --> 00:53.630 what hosts. 00:53.670 --> 00:59.490 So when a packet is sent from one pod to the other, it goes out to the network, to the router and finds 00:59.490 --> 01:01.950 its way to the node that hosts that pod. 01:01.950 --> 01:07.440 Now that works for a small environment and in a simple network. But in larger environments with 100s 01:07.440 --> 01:10.710 of nodes in a cluster and 100s of PODs on each node, 01:10.710 --> 01:12.320 This is not practical. 01:12.330 --> 01:17.490 The routing table may not support so many entries and that is where you need to get creative and look 01:17.490 --> 01:19.200 for other solutions. 01:19.200 --> 01:25.950 Think of the kubernetes cluster as our company. And the nodes as different office sites. With each site, 01:25.950 --> 01:30.280 We have different departments and within each department we have different offices. 01:30.300 --> 01:37.410 Someone is office-1 wants to send a packet to office-3 and hands it over to the office boy. All he 01:37.410 --> 01:43.290 knows is it needs to go to office 3 and he doesn’t care who or how it is transported. The office 01:43.290 --> 01:50.370 boy takes the package, gets in his car, looks up address of the target office in GPS, uses directions 01:50.370 --> 01:55.590 on the street and finds his way to the destination site. Delivers the package to Payroll department 01:55.650 --> 02:01.710 who in turn forwards the package to office 3. This works just fine for now. We soon expand 02:01.710 --> 02:07.860 regions and countries and this process no longer works it's hard for the office boy to keep track of 02:07.890 --> 02:13.890 so many routes to these large number of offices across different countries and of course he can’t drive 02:13.920 --> 02:20.460 to these offices by himself. That’s where we decide to outsource all mailing and shipping activities 02:20.460 --> 02:23.070 to a company who does it best. 02:23.070 --> 02:25.230 Once the shipping company is engaged. 02:25.230 --> 02:30.680 The first thing that they do is place their agents in each of our company's sites. 02:30.690 --> 02:35.910 These agents are responsible for managing all shipping activities between sites. 02:35.910 --> 02:41.760 They also keep talking to each other and are well connected so they all know about each other's sites. 02:41.760 --> 02:44.670 The departments in them and the offices in them. 02:44.760 --> 02:52.560 And so when a package is sent from say office 10 to office 3 the shipping agent in that site intercepts 02:52.560 --> 02:55.460 the package, and looks at the target office name, 02:55.470 --> 03:01.200 He knows exactly in which site and department that office is in through his little internal network 03:01.200 --> 03:03.060 with his peers on the other sites. 03:03.060 --> 03:08.880 He then places this package into his own new package with the destination address said to the target 03:08.880 --> 03:11.810 sites location and then sends the package through. 03:11.820 --> 03:17.660 Once the package arrives at the destination it is again intercepted by the agent on that site. 03:17.670 --> 03:24.180 He opens the packet retrieves the original packet and delivers it to the right department. Back to a 03:24.180 --> 03:28.170 world, when the weave CNI plugin is deployed on a cluster, 03:28.200 --> 03:34.470 it deploys an agent or service on each node. They communicate with each other to exchange information 03:34.470 --> 03:37.310 regarding the nodes and networks and PODs within them. 03:37.320 --> 03:41.960 Each agent or peer stores a topology of the entire setup, 03:42.030 --> 03:45.730 that way they know the pods and their IPs on the other nodes. 03:45.830 --> 03:49.490 Weave creates its own bridge on the nodes and names it 03:49.500 --> 03:56.670 weave. Then assigns IP address to each network. The Ips shown here are examples only. In the upcoming 03:56.670 --> 03:57.500 practice test. 03:57.510 --> 04:02.390 test you will figure out the exact range of IP addresses weave assigns on each node. 04:02.400 --> 04:07.740 We will talk about IPAM and how IP addresses are handed out to PODs and containers 04:07.860 --> 04:09.390 in the next lecture. 04:09.390 --> 04:13.500 Remember that a single POD may be attached to multiple bridge networks. 04:13.500 --> 04:18.480 For example you could have a pod attached to the weave bridge as well as the docker bridge created by 04:18.480 --> 04:18.890 Docker. 04:18.900 --> 04:24.900 What path a packet takes to reach destination depends on the route configured on the container. Weave 04:24.900 --> 04:30.840 makes sure that PODs get the correct route configured to reach the agent. And the agent then takes care 04:30.840 --> 04:32.350 of other PODs. 04:32.500 --> 04:39.420 now when a packet is sent from one pod to another on another node, weave intercepts the packet and identifies 04:39.420 --> 04:40.890 that it's on a separate network. 04:40.890 --> 04:46.440 It then encapsulates this packet into a new one with new source and destination and sends it across 04:46.470 --> 04:47.050 the network. 04:47.070 --> 04:53.310 Once on the other side, the other weave agent retrieves the packet, decapsulates and routes the packet 04:53.310 --> 04:55.090 to the right POD. 04:55.110 --> 04:58.470 So how do we deploy weave on a kubernetes cluster? 04:58.580 --> 05:05.450 Weave and weave peers can be deployed as services or daemons on each node in the cluster manually or 05:05.450 --> 05:07.210 if kubernetes is setup already 05:07.220 --> 05:11.700 Then an easier way to do that is to deploy it as pods in the cluster. 05:11.750 --> 05:16.880 Once the base kubernetes system is ready with nodes and networking configured correctly between the 05:16.880 --> 05:22.460 nodes and the basic control plan components are deployed, weave can be deployed in the cluster with a single 05:22.730 --> 05:24.470 kubectl apply command. 05:24.470 --> 05:28.730 This deploys all the necessary components required for weave in the cluster. 05:28.730 --> 05:35.090 Most importantly the weave peers are deployed as a daemonset. A daemonset ensures that one pod of 05:35.090 --> 05:38.420 the given kind is deployed on all nodes in the cluster. 05:38.420 --> 05:41.010 This works perfectly for the weave peers. 05:41.120 --> 05:47.210 If you deployed your cluster with the kubeadm tool and weave plugin, you can see the weave peers as pods 05:47.270 --> 05:50.530 deployed on each node. For troubleshooting purpose 05:50.690 --> 05:53.360 view the logs using the kubectl logs 05:53.360 --> 05:57.570 Command. Well that's it for this lecture. 05:57.570 --> 05:58.790 I will see you in the next.