00:04

hello and welcome to this lecture on

00:07

kubernetes overview my name is moon

00:10

shot' monomyth and we are learning

00:11

kubernetes for beginners in this lecture

00:14

we will go through an overview of

00:16

kubernetes kubernetes also known as k-8

00:21

was built by Google based on their

00:24

experience running containers in

00:26

production it is now an open source

00:29

project and is arguably one of the best

00:31

and most popular container orchestration

00:34

technologies out there in this lecture

00:37

we will try to understand kubernetes at

00:40

a high level to understand kubernetes we

00:44

must first understand two things

00:46
container and orchestration once we get

00:50

familiarized with both of these terms we

00:53

would be in a position to understand

00:55

what kubernetes is capable of we will

00:58

start by looking at each of these next

01:04

we're now going to look at what

01:06

containers are specifically we will look

01:09

at the most popular container technology

01:12

out there that is docker if you are

01:15

familiar with docker already feel free

01:18

to skip this lecture and move over to

01:21

the next

01:24

hello and welcome to this lecture on

01:26

docker overview my name is moonshot

01:28

monomyth and we are learning docker

01:30

fundamentals in this lecture we're going

to look at a high-level overview on why

01:36

you need docker and what it can do for

01:38

you let me start by sharing how I got

01:42

introduced to docker in one of my

01:44

previous projects I had this requirement

01:46

to set up an end-to-end stack including

01:48

various different technologies like a

01:51

web server using node.js a database such

01:54

as MongoDB a messaging system like Redis

01:57

and an orchestration tool like ansible

01:59

we had a lot of issues developing this

02:02

application with all these different

02:04

components first there compatibility

02:06

with the underlying operating system we

02:09

had to ensure that all these different

02:11
services were compatible with the

02:12

version of the operating system we were

02:14

planning to use there have been times

02:16

when certain version of these services

02:19

were not compatible with the OS and

02:21

we've had to go back and look for

02:23

another OS that was compatible with all

02:26

these different services secondly we had

02:29

to check the compatibility between these

02:31

services and the libraries and

02:32

dependencies on the OS we've had issues

02:35

where one service requires one version

02:38

of a dependent library whereas another

02:40

service required another version the

02:42

architecture of our application changed

02:45

over time we've had to upgrade to newer

versions of these components or change

02:50

the database etc and every time

02:53

something changed we had to go through

02:55

the same process of checking

02:57

compatibility between these various

02:59

components and the underlying

03:01

infrastructure this compatibility matrix

03:05

issue is usually referred to as the

03:08

matrix from hell

03:11

next every time we had a new developer

03:14

on board we found it really difficult to

03:16

set up a new environment the new

03:18

developers had to follow a large set of

03:21

instructions and run hundreds of

03:23

commands to finally set up their

03:25
environments they had to make sure they

03:27

were using the right operating system

03:29

the right versions of each of these

03:31

components and each developer had to set

03:34

all that up by himself each time we also

03:37

had different development tests and

03:39

production environments one developer

03:42

may be comfortable using one OS and the

03:45

others may be using another one and so

03:47

we couldn't guarantee that the

03:49

application that we were building would

03:51

run the same way in different

03:53

environments and so all of this made our

03:56

life in developing building and shipping

03:59

the application really difficult

04:04

so I needed something that could help us

with the compatibility issue something

04:09

that will allow us to modify or change

04:11

these components without affecting the

04:14

other components and even modify the

04:16

underlying operating system as required

04:18

and that search landed me on docker with

04:22

docker I was able to run each component

04:25

in a separate container with its own

04:27

libraries and its own dependencies all

04:30

on the same VM and the OS but within

04:33

separate environments or containers we

04:36

just had to build the docker

04:37

configuration once and all our

04:40

developers could now get started with a

04:42

simple docker run command irrespective

04:46
of what the underlying operating system

04:47

they run all they needed to do was to

04:50

make sure they had darker installed on

04:52

their systems

04:57

so what are containers containers are

05:01

completely isolated environments as in

05:04

they can have their own processes or

05:06

services their own networking interfaces

05:09

their own mounts just like virtual

05:11

machines except they're all shared the

05:14

same operating system kernel we will

05:16

look at what that means

05:17

in a bit but it's also important to note

05:20

that containers are not new with docker

05:22

containers have existed for about 10

05:25

years now and some of the different

types of containers are alexei LX d LX

05:30

EFS etc docker utilizes lxc containers

05:35

setting up these container environments

05:37

is hard as they're very low-level and

05:39

that is where docker offers a high level

05:42

tool with several powerful functions

05:44

making it really easy for end-users like

05:47

us to understand how docker works let us

05:52

revisit some basic concepts of operating

05:55

systems first if you look at operating

05:58

systems like Ubuntu Fedora SUSE or st.

06:01

OS they all consist of two things an OS

06:05

kernel and a set of software the

06:08

operating system kernel is responsible

06:10

for interacting with the underlying

06:12
hardware while the OS kernel remains the

06:15

same which is Linux in this case it's

06:17

the software above it that makes these

06:19

operating systems different this

06:22

software may consist of a different user

06:24

interface drivers compilers file

06:27

managers developer tools etc so you have

06:30

a common Linux kernel shared across all

06:33

operating systems and some custom

06:36

software that differentiates operating

06:38

systems from each other

06:42

we said earlier that docker containers

06:46

shared the underlying kernel what does

06:48

that actually mean

06:50

sharing the kernel let's say we have a

06:52

system with an Ubuntu OS with docker

installed on it docker can run any

06:57

flavor of OS on top of it as long as

07:00

they are all based on the same kernel in

07:03

this case Linux if the underlying

07:05

operating system is Ubuntu docker can

07:07

run a container based on another

07:09

distribution like debian fedora SUSE or

07:13

st. OS each docker container only has

07:17

the additional software that we just

07:19

talked about in the previous slide that

07:21

makes these operating systems different

07:23

and docker utilizes the underlying

07:26

kernel of docker host which works with

07:29

all the operating systems above so what

07:32

is an OS that do not share the same

07:34
kernel as this Windows and so you won't

07:37

be able to run a windows-based container

07:40

on a docker host with Linux OS on it for

07:44

that you would require a docker on a

07:46

Windows server you might ask

07:49

isn't that a disadvantage then not being

07:52

able to run another kernel on the OS the

07:55

answer is no because unlike hypervisors

07:58

docker is not meant to virtualize and

08:02

run different operating systems and

08:04

kernels on the same hardware the main

08:07

purpose of docker is to containerize

08:09

applications and to ship them and run

08:12

them

08:15

so that brings us to the differences

08:18

between virtual machines and containers

something that we tend to do especially

08:22

those from a virtualization background

08:25

as you can see on the right in case of

08:28

docker we have the underlying hardware

08:31

infrastructure than the operating system

08:34

and docker installed on the OS docker

08:37

can then manage the containers that run

08:40

with libraries and dependencies alone in

08:43

case of a virtual machine we have the OS

08:45

on the underlying hardware then the

08:48

hypervisor like ESX or virtualization of

08:51

some kind and then the virtual machines

08:53

as you can see each virtual machine has

08:56

its own operating system inside it then

08:59

the dependencies and then the

09:01
application this overhead causes higher

09:04

utilization of underlying resources as

09:07

there are multiple virtual operating

09:09

systems and kernels running the virtual

09:11

machines also consume higher disk space

09:14

as each VM is heavy and is usually in

09:17

gigabytes in size whereas docker

09:19

containers are lightweight and are

09:22

usually in megabytes in size this allows

09:25

docker containers to put up faster

09:27

usually in a matter of seconds whereas

09:30

virtual machines as we know takes

09:32

minutes to boot up as it needs to put up

09:34

the entire operating system it is also

09:38

important to note that docker has less

09:40

isolation as more resources are shared

between containers like the kernel

09:45

whereas we amps have complete isolation

09:47

from each other since millions don't

09:50

rely on the underlying operating system

09:52

or kernel you can have different types

09:55

of operating systems such as Linux based

09:57

or Windows based on the same hypervisor

09:59

whereas it is not possible on a single

10:02

docker host so these are some

10:04

differences between the two so how is it

10:09

done there are a lot of containerized

10:12

versions of applications readily

10:14

available as of today so most

10:16

organizations have their products

10:18

containerized and available in a public

10:21
docker registry called docker hub or

10:24

docker store already for example you can

10:28

find images of more

10:29

common operating systems databases and

10:32

other services and tools once you

10:35

identify the images you need and you

10:37

install docker on your host bringing up

10:40

an application stack is as easy as

10:43

running a docker run command with the

10:46

name of the image in this case running a

10:49

docker run ansible command will run an

10:51

instance of ansible on the docker host

10:54

similarly run an instance of MongoDB

10:57

Redis and node.js using the docker run

11:00

command when you run nodejs

11:03

just point to the location of the code

repository on the host if you need to

11:07

run multiple instances of the web

11:09

service simply add as many instances as

11:12

you need and configure a load balancer

11:14

of some kind in the front in case one of

11:17

the instances was to fail simply destroy

11:20

that instance and launch a new instance

11:23

there are other solutions available for

11:25

handling such cases that we will look at

11:27

later during this course we've been

11:31

talking about images and containers

11:33

let's understand the difference between

11:35

the two an image is a package or a

11:39

template just like a VM template that

11:41

you might have worked with in the

11:43
virtualization world it is used to

11:46

create one or more containers containers

11:49

are running instances of images that are

11:52

isolated and have their own environments

11:54

and set of processes as we have seen

11:57

before a lot of products have been

11:59

docker eyes already in case you cannot

12:02

find what you're looking for you could

12:04

create an image yourself and push it to

12:06

the docker hub repository making it

12:09

available for the public

12:13

if you look at it traditionally

12:17

developers developed applications then

12:22

they hand it over to ops team to deploy

12:24

and manage it in production environments

12:27

they do that by providing a set of

instructions such as information about

12:33

how the house must be set up

12:35

what prerequisites are to be installed

12:37

on the host and how the dependencies are

12:39

to be configured etc the ops team uses

12:42

this guide to set up the application

12:45

since the ops team did not develop the

12:48

application on their own the struggle

12:51

with setting it up when they hit an

12:53

issue they work with the developers to

12:56

resolve it with docker a major portion

12:59

of work involved in setting up the

13:01

infrastructure is now in the hands of

13:03

the developers in the form of a docker

13:06

file the guide that the developers built

13:08
previously to set up the infrastructure

13:10

can now easily be put together into a

13:13

docker file to create an image for the

13:16

applications this image can now run on

13:20

any container platform and is guaranteed

13:22

to run the same way everywhere so the

13:25

ops team now can simply use the image to

13:28

deploy the application since the image

13:31

was already working when the developer

13:33

built it and operations are not

13:36

modifying it it continues to work the

13:38

same way when deployed in production to

13:43

learn more about containers check out my

13:45

other courses docker for the absolute

13:48

beginners and docker swarm where you can

13:50

learn and practice docker commands and

create docker files that's the end of

13:55

this lecture on containers and docker

13:58

see you in the next lecture