WEBVTT

00:00.520 --> 00:04.170
[MUSIC]

00:04.170 --> 00:08.000
Hello, and welcome
to this lecture on Kubernetes Pods.

00:09.620 --> 00:12.080
Before we head into understanding Pods,

00:12.080 --> 00:16.640
we would like to assume
that the following have been set up already.

00:16.640 --> 00:21.170
At this point, we assume
that the application is already developed

00:21.170 --> 00:23.610
and built into Docker images

00:23.610 --> 00:26.450
and it is available on a Docker repository

00:26.450 --> 00:30.170
like Docker Hub
so Kubernetes can pull it down.

00:30.170 --> 00:37.010
We also assume that the Kubernetes Cluster
has already been set up and is working.

00:37.280 --> 00:42.410
This could be a single node setup
or a multi-node setup, it doesn't matter.

00:42.410 --> 00:45.960
All the services
need to be in a running state.

00:46.580 --> 00:48.560
As we discussed before,

00:48.560 --> 00:53.060
with Kubernetes, our ultimate aim
is to deploy our application

00:53.060 --> 00:56.020
in the form of containers on a set of machines

00:56.020 --> 00:59.410
that are configured
as worker nodes in a cluster.

00:59.410 --> 01:05.730
However, Kubernetes does not deploy
containers directly on the worker nodes.

01:05.900 --> 01:12.580
The containers are encapsulated
into a Kubernetes object known as Pods.

01:12.780 --> 01:16.850
A Pod is a single instance of an application.

01:16.850 --> 01:22.780
A Pod is the smallest object
that you can create in Kubernetes.

01:24.460 --> 01:27.730
Here we see the simplest of simplest cases

01:27.730 --> 01:31.920
where you have
a single node Kubernetes cluster

01:31.920 --> 01:34.930
with a single instance of your application

01:34.930 --> 01:39.400
running in a single Docker container
encapsulated in a Pod.

01:39.770 --> 01:43.890
What if the number of users
accessing your application increase

01:43.890 --> 01:46.400
and you need to scale your application?

01:46.540 --> 01:52.010
You need to add additional instances
of your web application to share the load.

01:52.240 --> 01:55.760
Now, where would you spin up
additional instances?

01:55.760 --> 02:00.040
Do we bring up a new container instance
within the same Pod?

02:00.040 --> 02:03.840
No, we create new Pod altogether

02:03.840 --> 02:07.120
with a new instance of the same application.

02:07.120 --> 02:11.500
As you can see, we now have
two instances of our web application

02:11.500 --> 02:16.970
running on two separate Pods
on the same Kubernetes system or node.

02:16.970 --> 02:19.610
What if the user base further increases

02:19.610 --> 02:22.970
and your current node
has no sufficient capacity?

02:22.970 --> 02:28.650
Well, then you can always deploy
additional Pods on a new node in the cluster.

02:28.650 --> 02:31.170
You will have a new node added to the cluster

02:31.170 --> 02:34.240
to expand the cluster's physical capacity.

02:34.240 --> 02:37.050
What I'm trying to illustrate in this slide

02:37.050 --> 02:41.180
is that Pods usually have
a one-to-one relationship

02:41.180 --> 02:43.940
with containers running your application.

02:44.100 --> 02:50.420
To scale up, you create new Pods,
and to scale down, you delete existing Pods.

02:50.730 --> 02:56.650
You do not add additional containers
to an existing Pod to scale your application.

02:56.650 --> 03:00.090
Also, if you're wondering
how we implement all of this,

03:00.090 --> 03:03.900
and how we achieve load balancing
between the containers, et cetera,

03:03.900 --> 03:06.900
we will get into all of that
in a later lecture.

03:06.900 --> 03:11.800
For now, we're only trying
to understand the basic concepts.

03:12.690 --> 03:15.100
We just said that Pods usually have

03:15.100 --> 03:18.000
a one-to-one relationship
with the containers,

03:18.000 --> 03:22.740
but are we restricted to having
a single container in a single Pod?

03:22.740 --> 03:23.730
No.

03:23.730 --> 03:27.100
A single Pod can have multiple containers

03:27.100 --> 03:32.780
except for the fact that they're usually
not multiple containers of the same kind.

03:32.780 --> 03:35.340
As we discussed in the previous slide,

03:35.340 --> 03:38.800
if our intention
was to scale our application,

03:38.800 --> 03:41.920
then we would need to create additional Pods.

03:42.720 --> 03:46.660
Sometimes you might have a scenario
where you have a helper container

03:46.660 --> 03:51.420
that might be doing some kind
of supporting task for our web application,

03:51.420 --> 03:54.040
such as processing a user-entered data,

03:54.040 --> 03:57.170
processing a file uploaded by the user,
et cetera,

03:57.170 --> 03:59.450
and you want these helper containers

03:59.450 --> 04:02.570
to live alongside
your application container.

04:02.570 --> 04:08.200
In that case, you can have both
of these containers part of the same Pod,

04:08.200 --> 04:11.680
so that when
a new application container is created,

04:11.680 --> 04:13.620
the helper is also created

04:13.620 --> 04:18.700
and when it dies, the helper also dies
since they are part of the same Pod.

04:18.700 --> 04:22.890
The two containers can also communicate
with each other directly

04:22.890 --> 04:28.610
by referring to each other as localhost
since they share the same network space.

04:28.610 --> 04:32.930
Plus they can easily share
the same storage space as well.

04:33.770 --> 04:35.930
If you still have doubts in this topic,

04:35.930 --> 04:37.490
I would understand if you did

04:37.490 --> 04:40.520
because I did the first time
I learned these concepts.

04:40.520 --> 04:42.380
We could take another shot

04:42.380 --> 04:45.460
at understanding Pods
from a different angle.

04:46.130 --> 04:50.170
Let's, for a moment,
keep Kubernetes out of our discussion

04:50.170 --> 04:53.260
and talk about simple Docker containers.

04:53.260 --> 04:56.880
Let's assume
we were developing a process or a script

04:56.880 --> 05:00.120
to deploy our application on a Docker host.

05:00.500 --> 05:03.840
Then we would first
simply deploy our application

05:03.840 --> 05:06.970
using a simple docker run
python-app command,

05:06.970 --> 05:10.960
and the application runs fine
and our users are able to access it.

05:11.280 --> 05:12.740
When the load increases,

05:12.740 --> 05:15.920
we deploy more instances of our application

05:15.920 --> 05:19.250
by running the docker run commands
many more times.

05:19.500 --> 05:22.250
This works fine, and we're all happy.

05:22.560 --> 05:26.480
Now sometime in the future,
our application is further developed,

05:26.480 --> 05:31.170
undergoes architectural changes,
and grows and gets complex.

05:31.170 --> 05:35.500
We now have a new helper container
that helps our web application

05:35.500 --> 05:39.120
by processing or fetching data
from elsewhere.

05:39.120 --> 05:43.160
These helper containers
maintain a one-to-one relationship

05:43.160 --> 05:44.930
with our application container,

05:44.930 --> 05:49.490
and thus needs to communicate
with the application containers directly

05:49.490 --> 05:52.320
and access data from those containers.

05:52.920 --> 05:55.700
For this, we need to maintain a map

05:55.700 --> 06:00.160
of what app and helper containers
are connected to each other.

06:00.160 --> 06:03.040
We will need to establish
network connectivity

06:03.040 --> 06:07.980
between these containers ourselves
using links and custom networks.

06:07.980 --> 06:12.100
We would need to create shareable volumes
and share it among the containers.

06:12.360 --> 06:15.500
We would need to maintain
a map of that as well.

06:15.500 --> 06:20.650
Most importantly, we will need to monitor
the state of the application container

06:20.650 --> 06:24.040
and when it dies,
manually kill the helper container as well

06:24.040 --> 06:26.090
as it's no longer required.

06:26.090 --> 06:27.900
When a new container is deployed,

06:27.900 --> 06:31.050
we would need to deploy
the new helper container as well.

06:31.050 --> 06:35.880
With Pods, Kubernetes does all of this
for us automatically.

06:35.880 --> 06:40.050
We just need to define
what containers a Pod consists of

06:40.050 --> 06:44.820
and the containers in a Pod, by default,
will have access to the same storage,

06:44.820 --> 06:48.200
the same network namespace, and same fate.

06:48.200 --> 06:52.720
As in they will be created together
and destroyed together.

06:52.890 --> 06:56.130
Even if our application
didn't happen to be so complex,

06:56.130 --> 06:58.250
and we could live with a single container,

06:58.250 --> 07:01.980
Kubernetes still requires you
to create Pods,

07:02.370 --> 07:04.220
but this is good in the long run

07:04.220 --> 07:08.330
as your application is now equipped
for architectural changes

07:08.330 --> 07:10.460
and scale in the future.

07:10.800 --> 07:15.820
However, also note that
multi Pod containers are a rare use case,

07:15.820 --> 07:20.730
and we're going to stick
to single containers per Pod in this course.

07:21.210 --> 07:24.220
Let us now look at how to deploy Pods.

07:24.530 --> 07:28.620
Earlier,
we learned about the kubectl run command.

07:28.810 --> 07:34.980
What this command really does is it deploys
a Docker container by creating a Pod.

07:34.980 --> 07:37.740
It first creates a Pod automatically

07:37.740 --> 07:41.280
and deploys an instance
of the nginx Docker image,

07:41.600 --> 07:44.890
but where does it get
the application image from?

07:44.890 --> 07:50.290
For that, you need to specify the image name
using the image parameter.

07:50.620 --> 07:54.210
The application image,
in this case, the nginx image

07:54.210 --> 07:57.490
is downloaded
from the Docker Hub repository.

07:57.490 --> 08:00.530
Docker Hub,
as we discussed is a public repository

08:00.530 --> 08:04.180
where latest Docker images
of various applications are stored.

08:04.180 --> 08:08.560
You could configure Kubernetes
to pull the image from the public Docker Hub

08:08.560 --> 08:11.890
or a private repository
within the organization.

08:12.300 --> 08:17.810
Now that we have a Pod created,
how do we see the list of Pods available?

08:18.180 --> 08:24.900
The kubectl get pods command
helps us see the list of Pods in our cluster.

08:25.080 --> 08:29.040
In this case, we see
the Pod is in a container creating state 

08:29.040 --> 08:33.620
and soon changes to a running state
when it is actually running.

08:33.970 --> 08:37.330
Also, remember that
we haven't really talked about the concepts

08:37.330 --> 08:40.860
on how a user can access the nginx web server.

08:40.860 --> 08:42.560
In the current state,

08:42.560 --> 08:46.490
we haven't made the web server
accessible to external users.

08:46.490 --> 08:49.810
You can access it internally from the node,

08:49.810 --> 08:55.050
but for now,
we will just see how to deploy a Pod

08:55.050 --> 08:57.210
and later, in a later lecture,

08:57.210 --> 09:00.400
once we learn
about networking and services,

09:00.400 --> 09:05.060
we will get to know how to make the service
accessible to end-users.

09:06.820 --> 09:08.680
Well, that's it for this lecture,

09:08.680 --> 09:12.100
head over to our demo
and I will see you in the next one.