Hello and welcome. In the previous episode, we discussed container networking interface or CNI and pod networking. We also discussed flannel CNI in the context of Kubernetes in some details. We'll continue that trend and today we'll discuss another popular CNI provider called Calico. We'll gain detailed level understanding of how Calico works.
and how operationally it differs from flannel. In case you missed my previous presentation on CNI, I'm going to discuss this in some overview in the next couple of screens. So basically CNI is really an open source software that provides network plumbing for containers.
As containers become popular, then it becomes evident that every software has to do the same thing to set up networking, assign IP addresses, and so on. And that becomes really tedious and repetitive. And this project basically creates, provides a service to containers. So any software that deals with containers, such as Kubernetes, Cloud Foundry, Podman, and so on, can take advantage of...
The CNI interface that they provide so let's see quickly and graphically how CNI works So what I'm showing here is we have a server This is a node, an incorporated node and the entire thing is one server and we have API Kubernetes services installed and we also have a network namespace so the network namespace really anytime anytime yet you create a Linux host it actually is also in start what is called a default network namespace. Network space is basically a container and that anything or everything just had anything to do with the network such as the IP address, the interface, the internet interface, the firewall rules, the routes, everything. are really containing what is called a network namespace.
So once we want to create, we want to deploy a Kubernetes pod, so the API server calls into kubelet service. Kubelet service then calls into CNI plugin and that's where it creates a pod network namespace like the one that we have here. Now the pod has its own namespace.
Then it installs a virtual Ethernet interface that comes in pairs. So one pair would be, one side of the pair would be inside the namespace, and the other part is actually created and attached to the host. And that is a pipeline that provides communication between the host and the pod.
It all then assigns an IP address. to that pod. It also sets the default route and that is how the communication with the outside world needs to go, what routes it will need to take. It also does the same thing on the host and it adds the routes to container.
So now we have established a communication between the host and the container. Now that we have some understanding of how CNI plugins work, let's talk about Calico, which is a very popular CNI plugin provider. In the previous episode, we discussed Flannel. So to install Calico, once you set up your initial Kubernetes cluster, then you can run this command, kubectl apply minus f, and this is the URL to where the installation package is. If you haven't done any Kubernetes deployment, no worries, I have a full course on installing Kubernetes on CentOS.
I provide great detail information including the scripts so you can set your cluster up quickly if you follow that course. Calico uses a dynamic subnet allocation scheme, which basically uses the Kubernetes API server etcd or set up its own etcd if you want to do that that way. So that basically provides, has the reference of what APIs will need to assign to each node. And once Calico is installed, then it assigns a block of those IPs to each node and each node is become the responsible for assigning the IPs to the deposit it creates inside it.
The default encapsulation for Calico is IP in IP protocol which basically involves wrapping a layer 3 IP packet inside an extra IP header. Let's see how that kind of really works. So this is an Ethernet frame.
which consists of the the MAC information, the MAC header, and the data, and the CRC checksum. So this is our kind of routine. It has the MAC address of the server, the originating server, and this is the MAC address of the destination server.
And then inside that it creates a kind of other shell, an other layer of IP header, which really doesn't have anything in it. except if we wrap the actual data, which is again is an IP data. It has an IP, source IP, destination IP. So these are the source and IP.
address of the pod. So we're talking about pods here and that's how it knows how to So basically the kind of this information piggybacks on the other layer IP Which has the IP address of the destination server pod. The destination node that has the pod that we are reaching to.
So again, you're talking about calling one pod from one server to another pod on a different server. If you are if you pause our communicating in on the same server, we don't need that This is really only is used by default again is this game is used when you're communicating across nodes So once this packet then is sent it knows how to send that it has a everything that needs the MAC addresses the IP addresses of the servers and then once this frame gets to the destination server it unpacks it and then it knows where this to which ip pod it needs to be sending it so kind of hide this information piggybacks it inside another ip header and finally calico uses a border protocol gateway or bgp to share and exchange ross info between nodes and that's how it facilitates part network communication. To demo and explore how Calico works on a Kubernetes environment, I'll set up two servers.
So I have a Kubernetes cluster. It has two nodes, the master node and node one, and I have pre-installed A very simple hello world application. It's got four pods.
As you can see there are two on each node. And as you can see when CNI actually installs or configures the pod network, it also creates the VET part. So it comes in pair. One pair is installed, one part of the pair is installed on the Kubernetes itself.
on the pod itself and then the other part the other part of the VET is actually installed on the server. So on the host so as you can see all of this four pods have four interfaces IP addresses and each one of those you can see the IP addresses and also Each VET has its counterpart on the server. So next we'll go to the command line and kind of explore what, this is not a full story of course, Calico has done a lot more and we are going to explore other features of Calico.
So I'll be using Visual Studio Code and so we are inside Visual Studio Code and I've already SSH into node one so as you saw in the previous diagram we have two nodes one is master and the other one node one so I'm running everything from node one. So let's run the first command ip addr or give me all the interfaces on this basically that what it says give me all the interfaces on this machine. So as you can see quite a number of them it's got a loopback at zero so that is the default interface for the server itself. and then we see a number of other ones such as Webro and Docker that are not being used by Calico but Calico has a number of entries here one is Calico and this GUID and the other one is so that is one of the virtual Ethernet that we saw in the first diagram that connects the server to the uh pod and this is the other one so that on this on node one we have two pods each one of the those has an interface that connects it to the pod there's also tunnel zero and it's got an ip address oh by the way these are these don't have any ip addresses because those are just basically these are the pipeline that connect to servers to connect the server to the pod. However, we also have what is called a tunnel.
And as you can see is something to do with IP IP. We'll discuss that later. But keep in mind that this calc also creates this interface called tunnel zero, and it has an IP address.
Okay, so that's as far as interfaces concerned though. The next command ip link show type vet. So I'm just going to verify again to see how many virtual ethernet interfaces created. And again no surprise we have two of them. These are the ones that we show up here.
So they're kind of verifying that we have the same one showing up when we run that command. Okay. We can also do IP link show type IP IP.
So we want to verify this guy. You can also do that independently. So if you run that, we'll see that it shows as a tunnel zero and then IP IP.
So this is as far as the tunnel that we'll discuss a little bit later and the VET for our pods. Now let's do a kubectl get pods minus o y. I'm just going to display all the pods that we have. And again, this is very similar to what I'll show you in that diagram before, page before. So there are four pods that I installed as part of one Hello World application.
As you can see, two of them are running on node one and the other two are running on master. Okay, so far so good. Now let's see how to get to one of those.
So IP route, get, and the IP address. So basically I'm saying I want to go to this pod 172.16.4.94.5. That is this guy. So if I want to go from node one where I am I want to go to that hit that pod what are the routes that I need to go through and this is the results which tells me in order to go hit that pod from the server itself on the node itself you have to go through that interface Again, this is the interface of the VET that connects the server to the pod.
So again, that's what we show up here. This guy here. So in order for any communication that hits that pod, we need to go through that interface.
If we do the same thing for The next pod, 06, this guy here, run that. Again, very similarly, in order to go from pod 1, I'm sorry, from node 1, hit that pod, we need to go to this interface, again, that we saw earlier. So there are no bridges here.
Every time that you install a pod and install a pod is installed on a server, Calico creates a route for it. Now let's say we want to hit a different pod, this one or six is actually on a different servers on master. So how do we get there?
So we run that. We'll see that in order to hit 206, we need to go through the IP of 192.168.40 that is master so it's on the other server. However, we need to go through the tunnel zero and with the IP address and that was the tunnel that we saw up here.
So we need to go through that. So that tunnel does the magic. So that tunnel basically facilitates the communication between pause on one server and pause on the other server. Now let's, next we'll kind of show you graphically what we discovered from this demo right now.
So here's a view of our environment again, Kubernetes environment. We have two servers and then the four pods that we saw earlier. And as we saw, any communication that on the same server goes to any of these pods, it has to go through the VET piece on the server side. So again, these are connected together.
The interface on the pod is really kind of one side of the same pair. So you have a pair here and pair here and that's how you connect it. So all communication on from the same server going to the pod goes through these interfaces. It doesn't matter where they are.
However, if this one pod wants to communicate to with another pod on a different server then as we saw it has to go through the tunnel and the tunnel this is where the IP in IP transformation occurs. That is it sticks it creates an IP header and then encapsulates everything and the IP part of this communication inside that IP and then it uses its IP address as a source so it kind of masquerades as IP address and then sends it through this interface of the node and then it goes to the other node and then over here it disassembles this that that IP information and unpacks everything and then sends the information directly to that pod and so this is kind of overview next we're going to kind of explore what happens as information it sends between do and how IP and p in IP and the whole encapsulation works. We'll do that next. In this part of the demo, we are going to capture some network traffic and see how IP in IP works in action.
So first thing, let's just run this command, kubectl get services to see what services we have available for use. And I have this hello world that we are going to use for this demo. It's a very simple application. As you can see the type is node port.
That is we can actually get to that service from outside the cluster. That is the cluster IP and this is the node port number. So if we do curl http and using the IP address of one of the services and the node port IP then we will be able to call that service and we can see the result.
Hello World version number and host name. So very simple application indeed. So let's again take a look at the pods that we have and as we recall we have four pods, two on each node and these are pod names. The IP addresses are here and those are the nodes.
So we have four different pods, two on each node. So let's then we're going to um sh into one of the nodes so sorry pods so we're going to as we show this guy let's do that and then from here we're going to call a service on the other node so one part on one node is going to make a service call to a different Pod on a different server. So we're going across the server and to see what's happening. So before running that curr command, let's go ahead and start our capture.
So I'm using Tshark. This is the command line version of Wireshark. So Tshark minus i, that is what interface we're going to listen on. At zero that is the interface. the default interface on node one.
So we're running from node one. Minus V means make it verbose. Print all information.
Minus Y HTTP. We are telling Wireshark we are interested in HTTP. So please listen for HTTP traffic.
So the next thing about Tshark is we understand HTTP. So let's run that. So that is ready for us.
So over here we're going to run that command. and that curl and again you can see the results coming back exactly the same way and over here we'll see that it captures a lot of stuff so let's scroll up here and see what's going on so The capture started from here. The first part is the frame.
So as you can recall, the frame, the Ethernet frame contains everything. So that's the kind of exterior, that kind of outer part of the whole traffic. Then inside that, we'll see that we have Internet Protocol IP.
And then we'll see the source. our server, which is we are going from node 1, which is and the destination is So this is the exterior, this is the IP header that it creates and then puts everything inside. So that's the kind of other shell IP.
And within that we'll see there is another and as you can see here it says protocol ipip. So the first ip header is of the type ipip protocol and inside that is actually the again the ip header but this is the ip header of actual communication that one pod is trying to send to the other. The source for this is if you recall.
That is the IP address of the tunnel. So the tunnel on node 1 is actually masquerading the IP address of the pod itself. So, and then the destination is 206. So, this is the service that we are calling on 182.168.60. So, again, that's the IP address, the destination IP address. And within that, we'll see that, let's just scroll down.
This is the TCP part as you know HTTP is TCP basically and then the destination port is 8080 that's exactly what we are calling and then there are some handshake going on here and then a little bit later it starts packing and kind of getting everything together and it starts creating the the ethernet so this is going reverse now we'll be going from The master, that's what the service was on. The service starts responding and starts creating the Ethernet. So that's the Ethernet frame. And then inside that, again, it creates another Ethernet.
frame of header. Again, the destination is reversed. The source would be 4D. We're going from the second server back to our server where we started everything else. And then as you can see, it's exactly the same.
It's kind of reversed. Fast packets everything, all the information, and sends it back to the server, to the caller, to the pod that was calling it. And this is the the package information that is sending it back again is exactly a hello world version. So this is how IP in IP happens.
It's kind of like magic. It's very simple and very powerful, especially if servers are on different, they are not maybe a different subnet. So that makes things very easy to manage. So that is the demo for the default when we install Calico and we use its default IP in IP encapsulation. So hopefully by now you have some understanding of how CNI providers work.
and also you have some understanding of how Calico using the default settings work. But there is a lot more into Calico and we don't have to discuss everything in this session, but I'm going to talk about a couple of things here. First, we will just explore how Calico shares raw information amongst its nodes.
You're going to talk about a protocol called border gateway protocol or BGP and that is something that Calico leverages in order for it to share routing information between nodes. And then following that we will discuss non-IP in IP routing. So IP in IP is the default mode and that is something that we kind of all examples up to this point we've been using IP in IP.
So if you don't make any changes into calico settings when you install it by default it uses IP in IP. It has some overview overhead but it's not much but still there is an overhead. So if there are situations that you don't really need IP in IP, and we go through some of those situations, it's better to actually not use any encapsulation. That makes it actually faster.
We call it direct. There's also another option for VXLAN. If there is a situation in which you can't use direct communication or you can't use IP in IP routing, then VXLAN is another option. It's kind of similar to... flannel that we've discussed in the previous presentation.
BGP is a standardized exterior gateway protocol which is designed to exchange routing and reachability information among autonomous systems on the internet. So internet is really is run by BGP. BGP has really two functions, kind of overview. One is who on the internet I can send packet to. I in this case means a router.
So rather than we'll know who on the internet I can send the packet to, and the second is make a decision which route should the packet take. So let's kind of, this is very general overview of what BGP is, obviously in depth, this is very complicated system, but just for our understanding in the context of Kubernetes and Calico. So let's say we have, there are four networks. that they are not connected together yet through BGP, and each network only knows about its own route.
So A only knows about A, C only knows about C, and so on. And let's say administrators in these two networks configure their systems to then communicate with each other as far as through BGP. And as you can see then, B updates is routing information because now by just connecting to the A it knows that how to get to network A and there's only one route between itself and A.
Same thing A knows about B now that they can handshake, they have a handshake here and so then let's say A and C are connected, set up to communicate each other through BGP. The same thing here, C knows about A and the number of hops is one. And again, same thing between C and D.
And now again and so on. So now we have these four networks that know a little bit about each other, but periodically they also exchange information. For instance, network A can share information with network B.
and tells me these are the routes that I know about. So when it does that, then network B take a look and say, hey interesting, well of course I know about myself and I already connected with you so I know about you, but I did not know how to get to C. Now I know, so it updates its routing table here and now it has, it knows how to get C, to C.
So in order to get to C it has to go through A, and the number of hops is two. So B to C goes to A and then C. And B also shares the same information with D, and then D also now updates its information.
Now D knows how to get to A, it knows, it needs to go through B and the number of hops is two. And finally, after all this handshake is done, then every kind of network knows about at least how to get to other networks. So this is the essence of how BGP works. And Calico takes advantage of this protocol in order to share routes among its nodes. Now let's see how Calico actually leverages BGP.
When we install Calico, by default it creates a full mesh of internal BGP connections. And that way it does it every, it peers every node with every other node and that's how we have a full mesh. So any route changes happening on one node, that is reflected immediately in every other node.
So they will be aware of that. If we have a L2 network, that is if we have all our network on the same subnet, we have all our servers, Kubernetes endpoints, nodes on the same subnet, then Calico can leverage Otherwise, if we have maybe some of our servers on a different node, on a different subnet, then we can configure it to use IP in IP instead. As long as IP in IP traffic is not blocked, then full mesh can be established using layer 3 network.
Note that if we choose to use VXLAN instead, that is not, VHP is not supported in that scenario. So let's say we have a Kubernetes cluster, we have four nodes as you can see here. The next step for us would be to install Calico and that is how we install Calico. When we run that, Calico starts installing some software and kind of in can think of it as installing a virtual router on each of the node and then that becomes really, each node becomes an independent network and then establishes full mesh that is every node is paired directly with every other node and that is how the full mesh is realized.
And this really works great and it is really fast if we have maybe not too many combinated nodes but if we start having you know our networks become bigger and you know demand for network or Kubernetes cluster becomes bigger, maybe we add a lot more nodes. And as you can see in the long run, this kind of full mesh is not gonna work out. So fortunately, Calico supports route reflectors. Basically what it means is we can select a few number of nodes and then establish full mesh among those nodes and then have other nodes peer with those nodes.
And that, if there are any changes that happen in a sub-BGP, let's say this node has a number of nodes that are connected to it, then any changes in any of those nodes, any ROPS information, it sends to this node A, and then that's node A, and then it also reflects the changes, sends the changes to the nodes that are directly Appeared with it inside that group and then start doing the same thing with other leaders of the nodes and then over time those changes are reflected and then every Any changes that happens in one node as far as routes concerned are reflected in other nodes And that really works great in watching great in larger Kubernetes cluster if we Set up Kubernetes on our premise, on our cloud, maybe internal cloud, we have full control. We can configure Calico to peer directly with our physical network infrastructure. What it means really, typically, we disable Calico's full mesh, default full mesh behavior, and instead we peer Calico with our L3 top of the rack.
router. So we have a number of options. If we have a small network then we can use full mesh as is. As it grows we can then choose to have route reflectors and the best option is if you have full control over our environment and we have a hardware that supports top of the rack then we can actually configure our network to use top of the rack and set up mesh full BGP in that way. So in the previous two slides we saw BGP works in general and we saw how Calico implements BGP as a full mesh by default.
Now let's dig a little bit deeper into what happens actually when we set up Calico and what processes are involved and what services are involved. Let's say we have our cluster again, we have two servers and consisting of our cluster and we are using I would say IP in IP as a default encapsulation method and as you can see each node has its own network namespace has a default network adapter with an IP address on each side there's also because using IP and IP there's a tunnel that is set up on each node I haven't shown this over here I'm just showing it over here so but there'll be a tunnel over here as well so any communication that happens across the service between services and pods and go across the nodes it goes through a tunnel. Let's see what happens when we install a service which has used install deploy a single pod.
So as we saw earlier what happens is the API server calls into Kubelet. Kubelet calls into CNI plugin. The plugin creates the pod network namespace and then it creates the VETS, that is a virtual ethernet on both sides. So we have one side which has an IP address, the other side is not.
It's just basically a pipe that connects these two and also sets the default route for the new pod. Next thing that it does, it calls into a daemon called Felix that is installed. by calico when we saw calico its primary role is to manage the routes so now that we have a new route it actually programs the route table and it adds the ip address the destination of this pod and how do we get to that in order to get to that pod because it's on the same server we just simply go through this calico interface here so that's that's what it does and the next thing that it does it calls another a service called bird this is basically a BGP agent and that BGP agent passes that information the route that just we created is passed through The BGP agent from one node, it talks to the BGP agent or bird on the other node.
It also then talks to its own Felix, passes the information about the new route. And then the Felix on the second node also programs its route table. The destination again is the same.
However, because this is going through a cross, The nodes, you'll see that it goes through the tunnel 0. So any communication that is destined for this IP address, for this pod, will need to go through tunnel 0. So in summary, when you install Calico, it installs two important daemons. One is called Felix that manages and programs the raw table. and then the bird which is the BGP agent and that's how the different nodes talk to each other, the BGP agents talk to each other and that's how when a new rod is added on one node is reflected on every other node. So the last thing I wanted to talk about was calico networking options.
So, so far in our sample cluster we had two nodes and we have been using IP in IP, overlay network. And that may not be the best option in our prem is actually not the good the best option at all. So we'll talk about some other options that provide better performance.
First one is non overlay network and this is the most performant option as there is no encapsulation and decapsulation because that will take CPU time in order to do that. We have a couple of options. If we have control over our hardware and our hardware supports top of rack, then we can simply use BGP to peer with top of rack routers. And the benefit of this, first of all, there's no encapsulation. And the second benefit that we get is that our IP, pod IPs will be routable from outside the cluster.
So that's very nice. If that's not possible, but we have all our nodes on the same subnet, L2 subnet, then we can simply use Calico for BGP peering, you know, among nodes and then basically use it that way in that in that case we will not we will not be using any encapsulation although we are not those pod ips will not be reliable from outside the cluster that's only disadvantage of that but other that other than that it gives you the performance of the first option if you are in a situation where we have our nodes on multiple subnets Then there's another option called cross subnets overlay. And basically the way it works, it among the, it configures in a way that for the nodes that are on the same subnets, it won't use any encapsulation. However, if you are crossing going, you know, one, you're calling one pod is calling a service on a different node, which is on a different subnet.
then you can configure Calico to either use IP in IP or VXLAN as we cross the boundary. So that's another that's really good option to get the best of both worlds. One is you get the benefit of no overlay if you're on the same L2 network and also it provides overlay if for the situations where we are crossing the subnet.
And the last one of course is using a full overlay network and that's what we've been using up to this point and this is a situation where none of this is possible. So we can use either IP in IP which I've used for this demo or you can use the XLAN so that's kind of up to you. So these are the options as far as the on-prem is concerned.
These are very similar if you're running, you want to decide, if you decide to run your cluster on either Azure or Google or Amazon, mostly the same things apply, although there are some differences. For instance, it's going to be aware of. If you're running in Azure, for instance, Azure does not support IP in IP.
So if you are in a situation in which you can't use non-overlay within Azure, and you have to use overlay, then you have to use VXLAN. Also, there are some differences between them. So if you are...
running in the cloud, then I encourage you to read the documentation, Calico documentation. I'll provide the link in the description. Next, I'll show you how to make these configuration changes.
Obviously, ideally, you want to make the decision before you set up your cluster because you don't want to, you know, make these fundamental changes as you have, you know, clients and your workloads running on it. So, on that, I'll show you next. So in order to change the network settings Calico network setting after is installed we need to install a command line cli called calicoctl. I'll put a link in the description so you can go you guys can go ahead and install it yourself if you want to interact with calico and learn more about how it works.
So the first command we're going to look at the calico node status, so let's run that. I'll put in my password. And this shows us the BGPS status of our cluster.
So right now this is the peer address so I'm looking at this is I'm running these commands on the master node and I have only one more node so you'll see that this is the other node so we are looking at what server we're peering with and that's the other node that is node one and peer type is node to node and is mesh so this is the default behavior and status is up which is a good thing and uh already established. So this is how you get the status of your BGP once you install Calico. If you want to see if everything is running correctly and the peers are interacting with each other and it's up, then just run the command sudo calico node status. So in order to make changes to our network setting, first we need to look at what's called IP port So let's run that command.
And so in Calico, you can set multiple IP pools. By default, there's only one. So this is the pool that all the pods on all nodes get their IP addresses from. So this is the complete IP. So it's 172.16.000-16.
So this is where, obviously, each... node gets its own block so it kind of sub uh creates stop nets within this full range of ips and so everything starts with 172.16 and then on one node is i believe uh 16 on the other dot 94. so but everything starts with 172.16 and that's how the uh the the pods get their ip addresses from now we need to actually uh download this uh file so calico CTL get IP pool and this is the name of the file that we need to get IP default dash IPv4 pool and then I'm just downloading it inside a YAML file so we can modify that so let's go ahead and run that And that's done. But we can open that in nano and take a look at the file and modify that.
So this is the setting. So let's just go through that quickly. Again the kind is IP pool. IP and then The create time and so this is a come a metadata information And this is the name of the file.
I've just opened so and then some information So this is a block size is 26 and the side there as we looked at is Again same information that we saw and this is an important part. So it says IP mode always so this is by default this is if we just download the YAML file from calico and install calico it by default it says to always and then at the at the bottom you'll see that vxlan mode is never because we are not using vxlan so let's go ahead and make a change here and let's in order to make calico not to use IP in IP. All we need to do is just make a change here and changes to never.
Oops, I should be looking where I'm typing. So I'll make a change here. Never.
So that's all the change that we need to make. And if we remember that if we have, if you're in a situation where we have some nodes on, you know, on one subnet and others on the other, then we need to use cross mode. But right now, we just want to say we don't want to use IP mode, IP and IP mode. So that's why the only change that we need to make here is just set that to never. OK, let's go ahead and.
Save that. Okay, and then all we need to do is then run calico apply, next line, number 9, apply minus F, and the YAML file we just created. So before doing that, let's go ahead and take a look at the route. So I'm going to run watch route minus N. So this shows the current route.
And pay attention here on this line. where we are going across, we're going across from one node to the other, like we have a A pod that's making a service call from one node to the other. If you remember, we're going through the tunnel because that's using IP in IP mode. So if we now go ahead and run this, just make sure and then we see how the route changes here for this line.
So let's go ahead and run that. And then you'll see the change. Now it changed from the tunnel into at zero.
So it's actually everything now is going through the regular interface. So you're not going through the tunnel. And that's the change that we just made. So we made that from IP and IP to regular because the reason for this because both these servers are on the same subnet. So there is no reason for us to be using the IP and IP.
So make this a lot faster. So we are in a situation where we have all your servers running on the same subnet. Then just you can go ahead and change that from IP and IP into direct basically.
So you're saying you're not going through IP and IP mode. So now let's verify that we don't see IP in IP at all in the packet. So we're going to do another packet capturing and then we'll see verify that we don't see IP in IP.
So I'm here in the Visual Studio command line. So let's go ahead and run take a look at the pods again and see. So we have four pods if you recall.
We have two of them running on master. This guy and this guy. and these two in between they're running on node one so I'm going to go inside a search inside one of these pods on the masternodes I'm going to search in here and then I'm going to call a service which is on the other node. So and then we can then capture the the packets and see how it's going. Let's go ahead and let's sh into that.
Okay and before running calling the service of this go ahead and do the run the capture command. And let's go ahead and now call this service. And as you can see, the packets have been captured. Let's go ahead and let me exit all of that and then maximize this. Let's go ahead up and verify the package from the beginning and do a kind of...
comparison like we had before. So again, the packets always include the internet packet which includes everything is IP and other information inside that. So this is the ethernet frame. So nothing in shares there as before.
However in here we will see that now the source is this The server itself calling into so going from the server because you're going through the regular interface so this service called directly into the IP address of the of the pot previously this first the other packet, IP packet Had the source as one server calling the other server and then inside that we Recall this saw and there was an IP in IP, but that doesn't exist anymore. So this is actually there of this only one Ethernet packet and everything else and there's no IP in IP anymore. And then the next step is basically the TCP so there is no IP and IP packet that we saw previously in the previous capture we'll see it doesn't exist anymore because we are not using IP and IP anymore.
So basically this is regular IP and then this is a destination of the pod that you're calling, the service that you're calling. So that's that's it. So I hope you enjoyed this presentation.
I'm going to summarize next and then we go from there. So in this video we cover the following topics. We started with taking a look, we took a look at container and network interface. I covered this in extensively in my first and second series of this course.
If you want more information go ahead and check those. We also introduced Project Calico, which is a CNI. It's one of the choices that you can make as far as selecting a CNI provider for your project.
We looked at IP and IP protocol, what it is and how Calico uses it. We learned about border gated protocol, which is an important topic when you use Calico and how it's been leveraging Calico. We also discussed various network choices and when to use which. We also learned how to make a network change after Calico is installed.
And the last thing, thank you so much for your time. If you like it, please give it a like and consider subscribing. I have the other courses that you might be interested, especially in networking.
I have two more courses. I'll include these courses' names and link in the description below. So again, thank you so much and please take care.