Hello and welcome to this lecture on Kubernetes overview.
My name is Mumshad Mannambeth
and we are learning Kubernetes for beginners. In this lecture,
We will go through an overview of Kubernetes. Kubernetes, also known as K8s was built by Google based
on their experience running containers in production.
It is now an open source project and is arguably one of the best and most popular container orchestration
technologies out there.
In this lecture, we will try to understand Kubernetes at a high level. To understand Kubernetes, we
must first understand two things.
Container and orchestration.
Once we get familiarized with both of these terms, we would be in a position to understand what Kubernetes
is capable of.
We will start by looking at each of these next.
We're now going to look at what containers are. Specifically,
We will look at the most popular container technology out there that is Docker.
If you're familiar with Docker already, feel free to skip this lecture and move over to the next
Hello and welcome to this lecture on Docker overview.
My name is Mumshad Mannambeth and we are learning Docker fundamentals. In this lecture,
We're going to look at a high level overview on why you need docker and what it can do for you.
Let me start by sharing how I got introduced to Docker. In one of my previous projects,
I had this requirement to set up an end to end stack including various different technologies like a
web server using node JS and database such as mongoDB and messaging system like Redis and an orchestration
tool like ansible.
We had a lot of issues developing this application with all these different components.
First, their compatibility with the underlying operating system. We had to ensure that all these different
services were compatible with the version of the operating system we were planning to use.
There have been times when certain version of these services were not compatible with the OS and we
had to go back and look for another OS there was compatible with all these different services.
Secondly, we had to check the compatibility between the services and the libraries and dependencies on
the OS.
We've had issues where one service requires one version of a dependent library whereas another service
required another version. The architecture of our application changed over time.
We've had to upgrade to newer version of these components or change the database etc.
And every time something changed we had to go through the same process of checking compatibility between
these various components and the underlying infrastructure.
This compatibility matrix issue is usually referred to as The Matrix from Hell. Next, every time we had
a new developer on board we found it really difficult to set up a new environment.
The new developers had to follow a large set of instructions and run hundreds of commands to finally
set up their environments.
They had to make sure they were using the right operating system, the right versions of each of these
components and each developer had to set all that up by himself each time.
We also had different development, test and production environments.
One developer may be comfortable using one OS and the others maybe using another one.
And so we couldn't guarantee that the application that we were building would run the same way in different
environments.
And so all of this
made our life in developing, building and shipping the application really difficult.
So I needed something that could help us with the compatibility issue. Something that would allow us
to modify or change these components without affecting the other components and even modify the underlying
operating system as required.
And that search landed me on Docker. With Docker, I was able to run each component in a separate
container with its own libraries and its own dependencies all on the same VM and the OS but within separate
environments or containers.
We just had to build the docker configuration once and all our developers could now get started with
a simple docker run command.
Irrespective of what the underlying operating system they run,
all they needed to do was to make sure they had docker installed on their systems.
So what are containers? Containers are completely isolated environments. As in they can have their own
processes or services, their own networking interfaces, their own mounts just like virtual machines.
Except they all share the same operating system Kernel.
We will look at what that means in a bit.
What is also important to note that containers are not new with Docker. Containers have existed for
about 10 years now and some of the different types of containers are LXC, LXD,
LXCFS etc..
Docker utilises LXC containers. Setting up these container environments is hard as they are very low level
and that is where a docker offers a high level tool with several powerful functions making it really
easy for end users like us. To understand how docker works,
Let us revisit some basic concepts of operating systems first.
If you look at operating systems like Ubuntu, fedora, suse or centOS,
they all consist of two things. An OS Kernel and a set of software.
The operating system kernel is responsible for interacting with the underlying hardware while the OS
kernel remains the same which is Linux
in this case, its the software above it that makes these operating systems different.
This software may consist of a different user interface,
drivers, compilers, file managers, developer tools etc..
So you have a common Linux kernel shared across all operating systems and some custom software that
differentiates operating systems from each other.
We said earlier that Docker containers share the underlying kernel.
What does that actually mean?
Sharing the kernel. Lets say we have a system with Ubuntu OS with Docker installed on it.
Docker can run any flavor of OS on top of it as long as they are all based on the same kernel.
In this case, Linux.If the underlying operating system is Ubuntu, docker can run a container based on
another distribution like Debian, Fedora, suse or centOS.
Each docker container only has the additional software that we just talked about in the previous slide
that makes these operating systems different and docker utilizes the underlying kernel of docker host
which works with all the operating systems above.
So what is an OS that did not share the same kernel as these? Windows.
And so you won't be able to run a Windows based container on a docker host with Linux OS on it.
For that you would require docker on a Windows server.
You might ask isn't that a disadvantage then. Not being able to run another kernel on the OS.
The answer is No, because unlike hypervisors docker is not meant to virtualize and run different operating
systems and kernels on the same hardware.
The main purpose of docker is to containerize applications and to ship them and run them.
So that brings us to the differences between virtual machines and containers.
Something that we tend to do especially those from a virtualization background.
As you can see on the right,
In case of docker we have the underlying hardware infrastructure, then the operating system and Docker
installed on the OS. Docker can then manage the containers that run with libraries and dependencies
alone. In case of a virtual machine,
we have the OS on the underlying hardware, then the hypervisor like ESX or virtualization of some kind
and then the virtual machines. As you can see, each virtual machine has its own operating system inside
it.
Then the dependencies and then the application.
This overhead causes higher utilization of underlying resources as there are multiple virtual operating
systems and kernels running. The virtual machines also consume higher disk space as each VM is heavy
and is usually in gigabytes in size whereas Docker containers are lightweight and are usually in megabytes
in size.
This allows docker containers to boot up faster usually in a matter of seconds whereas virtual machines
as we know takes minutes to boot up as it needs to boot up the entire operating system.
It is also important to note that docker has less isolation as more resources are shared in containers
like the kernel, whereas VMs have complete isolation from each other. Since mediums don't rely on the
underlying operating system or Kernel, you can have different types of operating systems such as Linux
based or Windows based on the same hypervisor whereas it is not possible on a single docker host.
So these are some differences between the two. So how is it done?
There are a lot of containerized versions of applications readily available as of today.
So most organizations have their products containerized and available in a public docker registry called
docker hub or docker store already.
For example, you can find images of most common operating systems, databases and other services and tools.
Once you identify the images, you need and you install Docker on your host. Bringing up an application
stack is as easy as running a docker run command with the name of the image.
In this case, running a docker run ansible command will run an instance of ansible on the docker host.
Similarly, run an instance of mongoDB, Redis and nodeJS using the docker run command. When you run
nodejs
Just point to the location of the code repository on the host. If you need to run multiple instances
of the web service, simply add as many instances as you need and configure a load balancer of some kind
in the front. In case one of the instances was to fail, simply destroy that instance and launch a new
instance.
There are other solutions available for handling such cases that we will look at later during this course.
We've been talking about images and containers.
Let's understand the difference between the two.
An image is a package or a template just like a VM template that you might have worked with in the
virtualization world.
It is used to create one or more containers.
Containers are running instances of images that are isolated and have their own environments and set
of processes.
As we have seen before, a lot of products have been dockerized already. In case you cannot find what
you're looking for,
you could create an image yourself and push it to the docker hub repository making it available for
the public.
If you look at it traditionally, developers developed applications. Then they handed over to upstream
to deploy and manage it in production environments.
They do that by providing a set of instructions such as information about how the hosts must be set
up, what prerequisites are to be installed on the host and how the dependencies are to be configured
etc..
The ops team uses this guide to set up the application. Since the ops team did not develop the application
on their own,
They struggle with setting it up. When they hit an issue,
they work with the developers to resolve it. With docker, a major portion of work involved in setting
up the infrastructure
is now in the hands of the developers in the form of a docker file. The guide that the developers built
previously to set up the infrastructure can now easily be put together into a docker file to create
an image for the applications.
This image can now run on any container platform and is guaranteed to run the same way everywhere.
So the ops team now can simply use the image to deploy the application. Since the image was already
working when the developer built it and operations are not modifying it,
It continues to work the same way when deployed in production. To learn more about containers,
check out my other courses "Docker for the Absolute Beginners" and "Dockers Swarm" where you can learn and
practice Docker commands and create Docker files.
That's the end of this lecture on containers and docker.
See you in the next lecture :)