WEBVTT

0
00:05.710 --> 00:09.170
Hello and welcome to this lecture on Kubernetes overview.

1
00:09.190 --> 00:10.960
My name is Mumshad Mannambeth

2
00:11.050 --> 00:15.180
and we are learning Kubernetes for beginners. In this lecture,

3
00:15.190 --> 00:24.010
We will go through an overview of Kubernetes. Kubernetes, also known as K8s was built by Google based

4
00:24.010 --> 00:27.190
on their experience running containers in production.

5
00:28.010 --> 00:34.760
It is now an open source project and is arguably one of the best and most popular container orchestration

6
00:34.760 --> 00:36.420
technologies out there.

7
00:37.240 --> 00:44.110
In this lecture, we will try to understand Kubernetes at a high level. To understand Kubernetes, we

8
00:44.110 --> 00:47.290
must first understand two things.

9
00:47.290 --> 00:49.860
Container and orchestration.

10
00:50.020 --> 00:56.050
Once we get familiarized with both of these terms, we would be in a position to understand what Kubernetes

11
00:56.110 --> 00:58.130
is capable of.

12
00:58.720 --> 01:05.010
We will start by looking at each of these next.

13
01:05.080 --> 01:09.660
We're now going to look at what containers are. Specifically,

14
01:09.690 --> 01:15.240
We will look at the most popular container technology out there that is Docker.

15
01:15.570 --> 01:21.680
If you're familiar with Docker already, feel free to skip this lecture and move over to the next

16
01:24.860 --> 01:27.830
Hello and welcome to this lecture on Docker overview.

17
01:27.830 --> 01:33.490
My name is Mumshad Mannambeth and we are learning Docker fundamentals. In this lecture,

18
01:33.500 --> 01:39.760
We're going to look at a high level overview on why you need docker and what it can do for you.

19
01:40.490 --> 01:45.480
Let me start by sharing how I got introduced to Docker. In one of my previous projects,

20
01:45.500 --> 01:51.290
I had this requirement to set up an end to end stack including various different technologies like a

21
01:51.290 --> 01:58.430
web server using node JS and database such as mongoDB and messaging system like Redis and an orchestration

22
01:58.430 --> 02:00.440
tool like ansible.

23
02:00.500 --> 02:05.390
We had a lot of issues developing this application with all these different components.

24
02:05.420 --> 02:11.270
First, their compatibility with the underlying operating system. We had to ensure that all these different

25
02:11.270 --> 02:16.250
services were compatible with the version of the operating system we were planning to use.

26
02:16.250 --> 02:22.040
There have been times when certain version of these services were not compatible with the OS and we

27
02:22.130 --> 02:27.980
had to go back and look for another OS there was compatible with all these different services.

28
02:27.980 --> 02:33.950
Secondly, we had to check the compatibility between the services and the libraries and dependencies on

29
02:33.950 --> 02:35.100
the OS.

30
02:35.120 --> 02:40.870
We've had issues where one service requires one version of a dependent library whereas another service

31
02:40.880 --> 02:46.610
required another version. The architecture of our application changed over time.

32
02:46.610 --> 02:52.040
We've had to upgrade to newer version of these components or change the database etc.

33
02:52.250 --> 02:59.030
And every time something changed we had to go through the same process of checking compatibility between

34
02:59.030 --> 03:02.970
these various components and the underlying infrastructure.

35
03:03.410 --> 03:13.260
This compatibility matrix issue is usually referred to as The Matrix from Hell. Next, every time we had

36
03:13.260 --> 03:18.720
a new developer on board we found it really difficult to set up a new environment.

37
03:18.720 --> 03:24.690
The new developers had to follow a large set of instructions and run hundreds of commands to finally

38
03:24.690 --> 03:26.350
set up their environments.

39
03:26.430 --> 03:31.650
They had to make sure they were using the right operating system, the right versions of each of these

40
03:31.700 --> 03:37.300
components and each developer had to set all that up by himself each time.

41
03:37.500 --> 03:41.530
We also had different development, test and production environments.

42
03:41.730 --> 03:47.510
One developer may be comfortable using one OS and the others maybe using another one.

43
03:47.610 --> 03:53.700
And so we couldn't guarantee that the application that we were building would run the same way in different

44
03:53.760 --> 03:55.020
environments.

45
03:55.140 --> 03:56.270
And so all of this

46
03:56.300 --> 04:04.810
made our life in developing, building and shipping the application really difficult.

47
04:04.970 --> 04:10.520
So I needed something that could help us with the compatibility issue. Something that would allow us

48
04:10.520 --> 04:17.180
to modify or change these components without affecting the other components and even modify the underlying

49
04:17.210 --> 04:19.520
operating system as required.

50
04:19.700 --> 04:26.480
And that search landed me on Docker. With Docker, I was able to run each component in a separate

51
04:26.480 --> 04:34.100
container with its own libraries and its own dependencies all on the same VM and the OS but within separate

52
04:34.190 --> 04:36.410
environments or containers.

53
04:36.410 --> 04:42.590
We just had to build the docker configuration once and all our developers could now get started with

54
04:42.590 --> 04:45.180
a simple docker run command.

55
04:45.410 --> 04:49.140
Irrespective of what the underlying operating system they run,

56
04:49.190 --> 04:58.260
all they needed to do was to make sure they had docker installed on their systems.

57
04:58.620 --> 05:05.670
So what are containers? Containers are completely isolated environments. As in they can have their own

58
05:05.700 --> 05:12.370
processes or services, their own networking interfaces, their own mounts just like virtual machines.

59
05:12.480 --> 05:16.460
Except they all share the same operating system Kernel.

60
05:16.560 --> 05:19.010
We will look at what that means in a bit.

61
05:19.080 --> 05:24.900
What is also important to note that containers are not new with Docker. Containers have existed for

62
05:24.900 --> 05:30.020
about 10 years now and some of the different types of containers are LXC, LXD,

63
05:30.070 --> 05:32.510
LXCFS etc..

64
05:32.640 --> 05:39.530
Docker utilises LXC containers. Setting up these container environments is hard as they are very low level

65
05:39.840 --> 05:46.170
and that is where a docker offers a high level tool with several powerful functions making it really

66
05:46.230 --> 05:52.170
easy for end users like us. To understand how docker works,

67
05:52.290 --> 05:55.860
Let us revisit some basic concepts of operating systems first.

68
05:55.860 --> 06:01.970
If you look at operating systems like Ubuntu, fedora, suse or centOS,

69
06:02.040 --> 06:07.770
they all consist of two things. An OS Kernel and a set of software.

70
06:08.040 --> 06:14.250
The operating system kernel is responsible for interacting with the underlying hardware while the OS

71
06:14.250 --> 06:16.560
kernel remains the same which is Linux

72
06:16.560 --> 06:22.090
in this case, its the software above it that makes these operating systems different.

73
06:22.090 --> 06:25.780
This software may consist of a different user interface,

74
06:25.780 --> 06:30.110
drivers, compilers, file managers, developer tools etc..

75
06:30.510 --> 06:37.140
So you have a common Linux kernel shared across all operating systems and some custom software that

76
06:37.140 --> 06:43.680
differentiates operating systems from each other.

77
06:43.780 --> 06:48.600
We said earlier that Docker containers share the underlying kernel.

78
06:48.640 --> 06:50.100
What does that actually mean?

79
06:50.110 --> 06:56.670
Sharing the kernel. Lets say we have a system with Ubuntu OS with Docker installed on it.

80
06:56.800 --> 07:03.080
Docker can run any flavor of OS on top of it as long as they are all based on the same kernel.

81
07:03.100 --> 07:09.580
In this case, Linux.If the underlying operating system is Ubuntu, docker can run a container based on

82
07:09.640 --> 07:15.150
another distribution like Debian, Fedora, suse or centOS.

83
07:15.190 --> 07:21.130
Each docker container only has the additional software that we just talked about in the previous slide

84
07:21.490 --> 07:28.070
that makes these operating systems different and docker utilizes the underlying kernel of docker host

85
07:28.390 --> 07:31.750
which works with all the operating systems above.

86
07:31.750 --> 07:36.900
So what is an OS that did not share the same kernel as these? Windows.

87
07:37.150 --> 07:44.090
And so you won't be able to run a Windows based container on a docker host with Linux OS on it.

88
07:44.140 --> 07:48.560
For that you would require docker on a Windows server.

89
07:48.730 --> 07:55.870
You might ask isn't that a disadvantage then. Not being able to run another kernel on the OS.

90
07:55.870 --> 08:03.640
The answer is No, because unlike hypervisors docker is not meant to virtualize and run different operating

91
08:03.640 --> 08:06.510
systems and kernels on the same hardware.

92
08:06.760 --> 08:13.320
The main purpose of docker is to containerize applications and to ship them and run them.

93
08:16.700 --> 08:21.260
So that brings us to the differences between virtual machines and containers.

94
08:21.260 --> 08:26.480
Something that we tend to do especially those from a virtualization background.

95
08:26.480 --> 08:28.290
As you can see on the right,

96
08:28.340 --> 08:35.260
In case of docker we have the underlying hardware infrastructure, then the operating system and Docker

97
08:35.270 --> 08:42.170
installed on the OS. Docker can then manage the containers that run with libraries and dependencies

98
08:42.170 --> 08:44.840
alone. In case of a virtual machine,

99
08:44.840 --> 08:51.830
we have the OS on the underlying hardware, then the hypervisor like ESX or virtualization of some kind

100
08:52.160 --> 08:58.870
and then the virtual machines. As you can see, each virtual machine has its own operating system inside

101
08:59.080 --> 08:59.550
it.

102
08:59.690 --> 09:02.800
Then the dependencies and then the application.

103
09:02.800 --> 09:09.320
This overhead causes higher utilization of underlying resources as there are multiple virtual operating

104
09:09.320 --> 09:16.490
systems and kernels running. The virtual machines also consume higher disk space as each VM is heavy

105
09:16.880 --> 09:23.480
and is usually in gigabytes in size whereas Docker containers are lightweight and are usually in megabytes

106
09:23.510 --> 09:24.930
in size.

107
09:24.950 --> 09:31.370
This allows docker containers to boot up faster usually in a matter of seconds whereas virtual machines

108
09:31.460 --> 09:36.930
as we know takes minutes to boot up as it needs to boot up the entire operating system.

109
09:37.880 --> 09:44.520
It is also important to note that docker has less isolation as more resources are shared in containers

110
09:44.580 --> 09:51.240
like the kernel, whereas VMs have complete isolation from each other. Since mediums don't rely on the

111
09:51.240 --> 09:57.540
underlying operating system or Kernel, you can have different types of operating systems such as Linux

112
09:57.540 --> 10:03.830
based or Windows based on the same hypervisor whereas it is not possible on a single docker host.

113
10:03.960 --> 10:10.670
So these are some differences between the two. So how is it done?

114
10:10.680 --> 10:16.120
There are a lot of containerized versions of applications readily available as of today.

115
10:16.170 --> 10:23.280
So most organizations have their products containerized and available in a public docker registry called

116
10:23.310 --> 10:26.650
docker hub or docker store already.

117
10:26.880 --> 10:34.830
For example, you can find images of most common operating systems, databases and other services and tools.

118
10:34.830 --> 10:41.640
Once you identify the images, you need and you install Docker on your host. Bringing up an application

119
10:41.640 --> 10:47.830
stack is as easy as running a docker run command with the name of the image.

120
10:47.880 --> 10:54.460
In this case, running a docker run ansible command will run an instance of ansible on the docker host.

121
10:54.690 --> 11:02.390
Similarly, run an instance of mongoDB, Redis and nodeJS using the docker run command. When you run

122
11:02.400 --> 11:03.170
nodejs

123
11:03.170 --> 11:09.090
Just point to the location of the code repository on the host. If you need to run multiple instances

124
11:09.120 --> 11:15.510
of the web service, simply add as many instances as you need and configure a load balancer of some kind

125
11:15.510 --> 11:22.350
in the front. In case one of the instances was to fail, simply destroy that instance and launch a new

126
11:22.350 --> 11:23.830
instance.

127
11:24.060 --> 11:29.710
There are other solutions available for handling such cases that we will look at later during this course.

128
11:31.160 --> 11:34.250
We've been talking about images and containers.

129
11:34.250 --> 11:37.040
Let's understand the difference between the two.

130
11:37.220 --> 11:43.520
An image is a package or a template just like a VM template that you might have worked with in the 

131
11:43.520 --> 11:45.080
virtualization world.

132
11:45.200 --> 11:48.650
It is used to create one or more containers.

133
11:48.920 --> 11:55.490
Containers are running instances of images that are isolated and have their own environments and set

134
11:55.580 --> 11:56.960
of processes.

135
11:57.320 --> 12:02.960
As we have seen before, a lot of products have been dockerized already. In case you cannot find what

136
12:02.960 --> 12:04.220
you're looking for,

137
12:04.220 --> 12:10.130
you could create an image yourself and push it to the docker hub repository making it available for

138
12:10.130 --> 12:15.490
the public.

139
12:15.550 --> 12:24.260
If you look at it traditionally, developers developed applications. Then they handed over to upstream

140
12:24.410 --> 12:28.700
to deploy and manage it in production environments.

141
12:28.830 --> 12:35.140
They do that by providing a set of instructions such as information about how the hosts must be set

142
12:35.140 --> 12:40.710
up, what prerequisites are to be installed on the host and how the dependencies are to be configured

143
12:40.800 --> 12:41.690
etc..

144
12:41.760 --> 12:49.530
The ops team uses this guide to set up the application. Since the ops team did not develop the application

145
12:49.560 --> 12:50.690
on their own,

146
12:50.700 --> 12:54.330
They struggle with setting it up. When they hit an issue,

147
12:54.360 --> 13:01.470
they work with the developers to resolve it. With docker, a major portion of work involved in setting

148
13:01.470 --> 13:02.640
up the infrastructure

149
13:02.670 --> 13:09.050
is now in the hands of the developers in the form of a docker file. The guide that the developers built

150
13:09.060 --> 13:15.840
previously to set up the infrastructure can now easily be put together into a docker file to create

151
13:15.900 --> 13:18.490
an image for the applications.

152
13:18.540 --> 13:25.380
This image can now run on any container platform and is guaranteed to run the same way everywhere.

153
13:25.380 --> 13:32.440
So the ops team now can simply use the image to deploy the application. Since the image was already

154
13:32.460 --> 13:37.420
working when the developer built it and operations are not modifying it,

155
13:37.470 --> 13:45.310
It continues to work the same way when deployed in production. To learn more about containers,

156
13:45.350 --> 13:51.440
check out my other courses "Docker for the Absolute Beginners" and "Dockers Swarm" where you can learn and

157
13:51.440 --> 13:54.840
practice Docker commands and create Docker files.

158
13:55.250 --> 13:58.790
That's the end of this lecture on containers and docker.

159
13:58.880 --> 14:00.660
See you in the next lecture :)