-This is the solution video for the Service Networking lab.
In the first question, we have to identify the network range of the nodes,
which are part of this cluster.
In the Terminal, let's run kubectl get nodes -o wide.
This will give us the IP address of both the nodes.
We have two nodes master and node01.
The internal IP address starts with 172.17.0.24 and 27.
Let us look at the CIDR range for this network,
which makes use of ens3 as we saw in one of the labs earlier,
for a node to node communication.
Here we can see that it's using /16.
It begins with 172.17.0.
Most appropriate answer here is 172.17.0.0,
which is the exact network,
and /16 is the CIDR.
What is the range of IP address configured for PODs on this cluster?
This is specifically for the pods, not the nodes itself.
To check this, we can see the configuration
of the weave plugin pod.
I'm going to run kubectl logs
for the weave-net pod
and inside we have a container called weave.
If we open up the logs for this,
we should see the IP allocation range somewhere here.
If you scroll to the very top, you see that ipalloc range
is set to 10.32.0.0/12.
That's one way of doing it.
We can also look up at the configuration for weave,
but in this case, this is the most appropriate answer.
We'll go with that.
What is the IP range configured for the services within the cluster?
In this case, we are looking at services.
We have already checked node and pods.
Let's look at services for this.
Another easy way to do it is to check the address range,
which is configured in the kube-apiserver.
I'm going to open up the static pod definition file
for kube-apiserver using vi editor.
If we scroll all the way to the bottom,
in the command section
we should see the service address range.
Here the service cluster IP range is 10.96.0.0/12.
Let's select that.
How many kube-proxy pods are deployed in this cluster?
Kube-proxy is typically run as a DaemonSet as well.
We can see that we have two pods running.
What type of proxy is kube-proxy configured to use?
We know that by default it makes use of Iptables chains,
but we can validate that.
Again, let's look at the logs of kube-proxy.
Let's select one of the pods here.
We'll make use of the command kubectl -n kube-system logs
and the kube-proxy pod.
If you see the first line, it is assuming Iptables proxy.
That's our answer.
For the last question,
we have to answer this,
how does this Kubernetes cluster ensure
that a kube-proxy pod runs on all nodes in the cluster?
We already discussed that kube-proxy runs as a DaemonSet,
but we can validate that on the Terminal by running kubectl,
get DaemonSets in the cube system namespace.
Here we can see that kube-proxy is in the list
and it requires two desired pods out of which two are current
and two are ready.
The answer is using a DaemonSet.
That was the last question.
Thank you for joining me in this video.
I'll see you in the next one.