Hello and welcome to this lecture and this lecture we discuss about pot networking in Britain, it is
so far we have set up several communities, master and worker nodes and configured networking between
them.
So they are all on a network that can reach each other.
We also made sure the firewall and network security groups are configured correctly to allow for the
Commonwealth control plane components to reach each other.
Assume that we have also set up all the competitors control plane components such as the Cube API server,
the SCD servers, Kubla, etc. and we are finally ready to deploy our applications.
But before we can do that, there is something that we must address.
We talked about the network that connects the nodes together, but there's also another layer of networking
that is crucial to the clusters functioning, and that is the networking at the pod layer.
Our communities cluster is soon going to have a large number of parts and services running on it.
How are the pods addressed?
How do they communicate with each other?
How do you access the services running on these parts internally from within the cluster as well as
externally from outside the cluster?
These are challenges that coordinators expects you to solve.
As of today, that is does not come with a built in solution for this.
It expects you to implement a networking solution that solves these challenges.
However, communities have laid out clearly the requirements for part networking.
Let's take a look at what they are.
Coordinators expects every pod to get its own unique IP address and that every part should be able to
reach every other part within the same node using that IP address.
And every part should be able to reach every other part on other nodes as well using the same IP address.
It doesn't care what IP address that is and what range or subnet it belongs to.
As long as you can implement a solution that takes care of automatically assigning IP addresses and
establish connectivity between the parts in a node as well as pods on different nodes, you're good
without having to configure any natural's.
So how do you implement a model that solves these requirements now?
There are many networking solutions available out there that does this, but we have already learned
about networking concepts, routing IP, address, management namespace and unite.
So let's try to use that knowledge to solve this problem by ourselves.
First, this will help in understanding how other solutions work.
I know there is a bit of repetition, but I'm trying to relate the same concept and approach all the
way from plane network namespace on Linux all the way to coroneted.
So we have a three node cluster.
It doesn't matter which one is master or worker, they all run ports either for management or workload
purposes.
As far as networking is concerned, we're going to consider all of them as the same.
So first, let's plan what we are going to do.
The nodes are part of an external network and has IP addresses in the 192 DOT 168 one dot series.
Node one is assigned 11, node two is twelve and No.
Three is thirteen.
Next step, when containers are created, cornetist creates network namespace spaces for them to enable
communication between them.
We attach these names to a network, but what network?
We have learned about bridge networks that can be created within nodes to attach names spaces.
So we create a network on each node.
And then bring them up, it's time to assign an IP address to the British interfaces or networks.
But what IP address?
We decide that each person network work will be on its own subnet, choose any private address range,
say, ten to forty four point one, 10 to forty four or two and ten to forty for the three.
Next we said the IP address for the bridge interface.
So we have built our base.
The remaining steps are to be performed for each container and every time a new container is created.
So we write a script for it.
Now, you don't have to know any kind of complicated scripting.
It's just a file that has all commands we will be using and we can run this multiple times for each
container going forward to attach a container to the network.
We need a pipe or virtual network cable.
We create that using the IP link, add command, don't focus on the options as they are similar to what
we saw in our previous lectures.
Assume that they are very depending on the inputs.
We then attach one end to the container and another end to the bridge using the IP links that command.
We then assign IP address using the IP ADR command and add a route to the default gateway.
But what IP do we add?
We either manage that ourselves or stored that information in some kind of database.
For now, we will assume it is tendered to forty four point one or two, which is a free IP in the subnet.
We discuss about IP address management in detail in one of the upcoming letters.
Finally, we bring up the interface.
We don't run the same script this time from the second container with its information and gets the container
connected to the network, the two containers can now communicate with each other.
We copy the script to the other nodes and run the script on them to assign IP address and connect those
containers to their own internal networks.
So we have solved the first part of the challenge.
The pods all get their own unique IP address and are able to communicate with each other on their own.
Not the next part is to enable them to reach other parts on other nodes.
So, for example, the pod at 10 to 40 for one or two on node one wants to ping pong, tend to prefer
door to talk to one or two.
As of now, the first has no idea where the addresses tend to 44 to two is because it is on a different
network than its own.
So it routes to Node One's IP as it is said to be the default gateway.
Not one doesn't know either, since ten to forty four to two is a private network.
One not to add a road to node one routing table to road traffic to attend to forty four, door to door
to wire the second nodes IP at 190 to 168, one by 12.
Once the route is added, the blue pod is able to ping across.
Similarly, we configure route on all host to all the other hosts with information regarding the respective
networks within them.
Now this works fine in this simple setup, but this will require a lot more configuration, as in when
your underlying network architecture gets complicated instead of having to configure a route on each
server.
A better solution is to do that on a router if you have one in your network and point all hosts to use
that as the default gateway.
That way you can easily manage wrote to all networks in the routing table on the router.
With that, the individual virtual networks we created with the address tendo 244 1.0.
Twenty four on each node now form a single large network with the address tendo to 44 dot 020 slash
16.
It's time to tie everything together.
We performed a number of manual steps to get the environment ready with the networks and routing tables.
We then wrote a script that can be run for each container that performs the necessary steps required
to connect each container to the network.
And we executed the script manually.
Of course, we don't want to do that, as in large environments where thousands of parts are created
every minute.
So how do we run the script automatically when a part is created on clarinettist?
That's where Cianni comes in.
Acting as the middleman, CNI tells Clarinettist that this is how you should call a script as soon as
you create a container.
And CNN tells us this is how your script should look like.
So we need to modify the script a little bit to meet CNI standards.
It should have an ad section that will take care of adding a container to the network and a delete section
that will take care of deleting container interfaces from the network and freeing the IP address, etc..
So our script is ready.
The Kubelik on each node is responsible for creating containers whenever the container is created.
The cube that looks at the CNI configuration passed as a command line argument when it was run and identifies
our scripts name.
It then looks in the country's been directory, defined our script and then executes the script with
the ADD command and the name and namespace ID of the container.
And then our script takes care of the rest.
We will look at how and where the CNI is configured and cabinet in the next lecture, along with practice
tests.
For now, the set from the part networking concepts lecture.
Hopefully that should give you enough knowledge on inspecting networking within parts in a cabinet is
cluster.
We will see how other solutions do the same thing that we did in the upcoming lectures.