Hello, and welcome to this lecture.
In this lecture,
we discuss about pod networking in Kubernetes.
So far, we have set up several Kubernetes master and worker nodes
and configured networking between them,
so they're 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 Kubernetes control plane
components to reach each other.
Assume that we have also set up
all the Kubernetes control plane components, such as the QB API server
the [?] servers, kubelets, et cetera,
and we're finally ready to deploy our applications.
Before we can do that,
there's 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 cluster's functioning.
That is the networking at the pod layer.
Our Kubernetes cluster is soon
going to have a large number of pods 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 pods internally from within the cluster,
as well as externally from outside the cluster?
These are challenges that Kubernetes expects you to solve.
As of today, Kubernetes does not come with a built-in solution for this.
It expects you to implement a networking solution
that solves these challenges.
However, Kubernetes have laid out
clearly the requirements for pod networking.
Let's take a look at what they are.
Kubernetes expects every pod to get
its own unique IP address, and that every pod should be able
to read every other pod within the same node
using that IP address.
Every pod should be able to reach
every other pod on other nodes as well,
using the same IP address.
It doesn't care what IP address
that is and what range or sub-net it belongs to.
As long as you can implement a solution that takes care
of automatically assigning IP addresses and establish
connectivity between the pods in a node, as well as pods
on different nodes, you're good,
without having to configure any naturals.
How do you implement a model that solves these requirements?
Now, there are many networking
solutions available out there that does these,
but we've already learned about networking concepts
brought in IP address management namespaces in CNI.
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 plain network
namespaces on Linux all the way to Kubernetes.
We have a three-node cluster,
it doesn't matter which one is master or worker.
They all run pods either for management
or workload purposes.
As far as networking is concerned,
we're going to consider all of them as the same.
First, let's plan what we're going to do.
The nodes are part of an external network
and has IP addresses in the 192.160.1. series.
Node 1 is assigned 11.
Node 2 is 12.
Node 3 is 13.
Next step,
when containers are created,
Kubernetes creates network namespaces for them.
To enable communication between them,
we attach these namespaces to a network.
What network?
We've learned about bridge networks
that can be created within nodes to attach namespaces.
We create a bridge network on each node and then bring them up.
It's time to assign an IP address to the bridge interfaces or networks.
What IP address?
We decide that each bridge network
will be on its own sub-net, choose any private address range,
say 10.244.1, 10.244.2, and 10.244.3.
Next, we set the IP address for the bridge interface.
We have built our base.
The remaining steps are to be performed
for each container,
and every time a new container is created.
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.
We can run this multiple times for each container going forward.
To attach a container to the network,
we need a pipe or a virtual network cable.
Recreate 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 vary depending on the inputs.
We then attach one end
to the container and another end to the bridge
using the "IP link set" command.
With an assign IP address, using the "IP addr" command
and add a route to the default gateway.
What IP do we add?
We either manage that ourselves or store that information
in some kind of database.
For now, we will assume
it is 10.244.1.2, which is a free IP in the sub-net.
We discuss about IP address management in detail
in one of the upcoming lectures.
Finally we bring up the interface.
We then run the same script, this time for 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.
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 nodes.
The next part is to enable them to reach other pods on other nodes.
Say, for example, the pod at 10.244.1.2 on Node 1
wants to ping pod 10.244.2.2 on Node 2.
As of now, the first has no idea where the address 10.244.2.2 is
because it is on a different network than its own.
It routes to Node 1's IP, as it is said
to be the default gateway.
Node 1 doesn't know either since 10.244.2.2
is a private network or Node 2.
Add a route to Node 1's routing table to route traffic to 10.244.2.2
where the second node's IP at 192.168.1.12.
Once the route is added, the blue pod is able to ping across.
Similarly, we configure route
on all hosts 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 routes 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 routes
to all networks in the routing table on the router.
With that,
the individual virtual networks we created
with the address 10.244.1.0/24 on each node now form
a single large network with the address 10.244.0.0/16.
It's time to tie everything together.
We performed a number of manual steps
to get the environment ready with the bridge 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.
We executed the script manually.
Of course, we don't want to do that as in large environments
where thousands of pods are created every minute.
How do we run
this script automatically when a pod is created on Kubernetes?
That's where CNI comes in acting as the middleman.
CNI tells Kubernetes that this is how you should call
a script as soon as you create a container, and CNI tells us,
"This is how your script should look like."
We need to modify the script a little bit to meet CNI standards,
it should have an add 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, et cetera.
Our script is ready.
The kubelet on each node
is responsible for creating containers.
Whenever a container is created,
the kubelet looks at the CNI configuration
passed as a command-line argument when it was run,
and identifies our script's name.
It then looks
in the CNI's bin directory to find our script and then executes
the script with the "Add" command and the name and namespace
of the container, and then our script takes care of the rest.
We will look at how and where the CNI is configured in Kubernetes
in the next lecture along with practice tests.
For now, that's it from the pod networking
concepts lecture.
Hopefully, that should give you enough knowledge on inspecting
networking within pods in a Kubernetes cluster.
We will see how other solutions do the same thing that we did
in the upcoming lectures.