WEBVTT 00:05.450 --> 00:08.480 Hello and welcome to this lecture in this lecture. 00:08.570 --> 00:11.870 We will discuss about networking in Cuba, Narus. 00:14.420 --> 00:18.050 Let us look at the very basics of networking in Cuba, Natus. 00:18.890 --> 00:21.800 We will start with a single node, Cuban and its cluster. 00:22.130 --> 00:27.600 The node has an IP address, say it is 192 dot, 168 dot one or two. 00:27.620 --> 00:31.710 In this case, this is the IP address we use to access the Cuban. 00:31.710 --> 00:34.140 It is node SFH into it, et cetera. 00:35.000 --> 00:40.520 On a side note, remember, if you're using a mini cube setup that I'm talking about, the IP address 00:40.550 --> 00:47.660 of the mini cube virtual machine inside your hypervisor, your laptop may be having a different IP like 00:47.670 --> 00:50.230 one eighty two the 168 or one dot 10. 00:50.570 --> 00:53.910 So it's important to understand how your volumes are setup. 00:55.030 --> 00:57.190 So on the single node, Coburn, it is cluster. 00:57.340 --> 01:04.480 We have created a single pod, as you know, a pod hosts a container, unlike in the Docker world, 01:04.570 --> 01:10.060 where an IP address is always assigned to a stock or container in the cabinet is world. 01:10.150 --> 01:12.570 The IP address is assigned to a pod. 01:13.390 --> 01:17.470 Each part in the carbonates gets its own internal IP address. 01:18.190 --> 01:21.910 In this case, it's in the range TANDOOR to 44 series. 01:21.970 --> 01:26.830 And the IP assigned to the pod is ten or 240, 4.0 or two. 01:27.760 --> 01:33.100 So how is it getting this IP address when Khubani this is initially configured? 01:33.520 --> 01:40.570 We create an internal private network with the address tendered to 40 forward or zeroed out zero and 01:40.600 --> 01:42.280 all the parts are attached to it. 01:43.060 --> 01:48.820 When you deploy multiple parts, they all get a separate IP assigned from this network. 01:49.570 --> 01:56.470 The parts can communicate to each other through this IP, but accessing the other parts using this internal 01:56.470 --> 02:02.680 IP address may not be a good idea as it's subject to change when parts are recreated. 02:03.400 --> 02:07.750 We will see better ways to establish communication between parts in a while. 02:08.200 --> 02:13.810 For now, it's important to understand how the internal networking works in Cupertino as. 02:15.630 --> 02:21.340 So it's all easy and simple to understand when it comes to networking on a single note. 02:21.420 --> 02:25.500 But how does it work when you have multiple nodes in your cluster? 02:26.220 --> 02:32.240 In this case, we have two nodes running Cuban natives and they have IP addresses, 192, 168. 02:32.640 --> 02:35.280 One or two and one dot three assigned to them. 02:35.910 --> 02:38.790 Note that they are not part of the cluster yet. 02:39.030 --> 02:43.890 Each of them has a single pod deployed, has discussed in the previous slide. 02:44.400 --> 02:50.190 These parts are attached to an internal network and they have their own IP addresses assigned. 02:51.030 --> 02:57.450 However, if you look at the internal network addresses, you can see that they are the same. 02:57.780 --> 03:04.920 The two networks have an address 10 to 44 dot zero or zero, and the paths deployed have the same address 03:04.920 --> 03:05.370 to. 03:06.540 --> 03:10.830 This is not going to work well when the nodes are part of the same cluster. 03:11.040 --> 03:17.070 The parts have the same IP addresses assigned to them, and that will lead to IP conflicts in the network. 03:18.050 --> 03:22.240 Now, that's one problem when a it is cluster a setup. 03:22.650 --> 03:23.040 Cuban. 03:23.040 --> 03:28.890 And this does not automatically set up any kind of networking to handle these issues. 03:29.580 --> 03:37.170 As a matter of fact, Cuban, it is, expects us to set up networking to meet certain fundamental requirements. 03:37.920 --> 03:45.360 Some of these are that all the containers or pods in a Cuban Natus cluster must be able to communicate 03:45.390 --> 03:48.750 with one another without having to configure net. 03:49.820 --> 03:56.390 All nodes must be able to communicate with containers and all containers must be able to communicate 03:56.420 --> 03:58.040 with the nodes in the cluster. 03:58.710 --> 04:04.890 Cuban Notis expects us to set up a networking solution that meets these criteria. 04:06.360 --> 04:13.740 Fortunately, we don't have to set it up all on our own as there are multiple pre-built solutions available. 04:14.220 --> 04:23.760 Some of them are the Cisco FCI Networks, Psyllium, big cloud fabric, flannel Vilmer, NSX, T and 04:23.770 --> 04:24.380 Kalikow. 04:25.290 --> 04:29.190 Depending on the platform you're deploying your Kuban, it is Kluster on. 04:29.340 --> 04:31.200 You may use one of these solutions. 04:31.800 --> 04:38.220 For example, if you were setting up a carbonated cluster from scratch on your own systems, you may 04:38.220 --> 04:42.810 use any of the solutions like Kalikow or flannel, etc.. 04:43.530 --> 04:48.060 If you were deploying on a V ember environment, NSX t may be a good option. 04:48.690 --> 04:54.750 If you look at the play with Kades Labs, they use weave net as their networking solution. 04:55.790 --> 05:01.720 So back to our cluster with the custom networking, either flannel or calico setup. 05:02.180 --> 05:09.290 It now manages the networks and eyepiece in my notes and assigns a different network address for each 05:09.320 --> 05:10.490 network in the node. 05:11.300 --> 05:18.110 This creates a virtual network of all pods and nodes where they are all assigned a unique IP address. 05:18.640 --> 05:25.430 And by using simple routing techniques, the cluster networking enables communication between the different 05:25.430 --> 05:29.000 paths or nodes to meet the networking requirements of Cuban. 05:29.160 --> 05:31.330 This does all the paths. 05:31.370 --> 05:35.970 Now can communicate to each other using the assigned IP address.