WEBVTT

00:00.120 --> 00:01.700
Hello and welcome to this lecture.

00:01.730 --> 00:06.930
In this lecture will discuss about CNI in Kubernetes in the prerequisite lectures

00:06.930 --> 00:11.190
We started all the way from the absolute basics of network namespaces.

00:11.220 --> 00:16.410
then we saw how it is done in Docker, we then discussed why you need standards for networking containers

00:16.530 --> 00:19.290
and how the container network interface came to be

00:19.290 --> 00:22.650
and then we saw a list of supported plugins available with CNI.

00:22.680 --> 00:28.560
In this lecture we will see how kubernetes is configured to use these network plugins. As we discussed in the

00:28.560 --> 00:35.350
pre-requisite lecture CNI defines the responsibilities of container runtime.  As per CNI, container runtimes,

00:35.370 --> 00:41.310
in our case Kubernetes, is responsible for creating container network namespaces, identifying and

00:41.310 --> 00:45.620
attaching those namespaces to the right network by calling the right network plugin.

00:45.630 --> 00:52.380
So where do we specify the CNI plugins for Kubernetes to use? The CNI plugin must be invoked by the

00:52.410 --> 00:58.050
component within Kubernetes that is responsible for creating containers. Because that component

00:58.200 --> 01:03.020
must then invoke the appropriate network plugin after the container is created.

01:03.060 --> 01:07.820
The CNI plugin is configured in the kubelet service on each node in the cluster.

01:07.830 --> 01:14.110
If you look at the kubelet service file, you will see an option called network-plugin set to CNI.

01:14.130 --> 01:18.060
You can see the same information on viewing the running kubelet service.

01:18.060 --> 01:24.270
You can see the network plugins set to CNI and a few other options related to CNI such as the CNI bin

01:24.330 --> 01:26.890
directory and CNI Config directory.

01:26.890 --> 01:34.380
The CNI bin directory has all the supported CNI plugins as executables. Such as the bridge, dhcp, flannel

01:34.440 --> 01:39.030
etc. The CNI conflict directory has a set of configuration files.

01:39.030 --> 01:43.980
This is where kubelet looks to find out which plugin needs to be used.  In this case

01:43.980 --> 01:47.780
it finds the bridge configuration file. If there are multiple files here,

01:47.790 --> 01:50.430
It will choose the one in alphabetical order.

01:50.490 --> 01:53.670
If you look at the bridge conf file, it looks like this.

01:53.700 --> 01:58.660
This is a format defined by the CNI standard for a plugin configuration file.

01:58.710 --> 02:01.460
. It’s name is mynet, type is bridge.

02:01.560 --> 02:07.620
It also has a set of other configurations which can be related to the concepts we discussed in the prerequisite

02:07.620 --> 02:13.410
lectures on bridging, routing and Masquerading in NAT. The isGateway defines whether the bridge network

02:13.410 --> 02:18.990
interface should get an IP address assigned so it can act as a gateway. The ipMasquerade defines

02:19.010 --> 02:24.780
if a NAT rule should be added for IP masquerading. The IPAM section defines IPAM configuration.

02:24.780 --> 02:30.630
This is where you specify the subnet or the range of IP addresses that will be assigned to pods and

02:30.690 --> 02:37.050
any necessary routes. The type host-local indicates that the IP addresses are managed locally on this

02:37.050 --> 02:37.370
host.

02:37.470 --> 02:44.540
Unlike a DHCP server maintaining it remotely. The type can also be set to DHCP to configure an external DHCP

02:44.540 --> 02:44.990
server.

02:45.030 --> 02:46.540
Well the set for this lecture.

02:46.560 --> 02:51.600
Head over to the practice exercises and practice working with CNI in Kubernetes.