Technologies come and go at a very rapid pace and it is very easy to lose track. So many people confuse Docker, Kubernetes and cloud offerings that I can’t stop looking away anymore. So here we go, discussing what docker is, what Kubernetes does, how they all play together and a very short straightforward summary in the end to send your colleges!
But let’s dive into it by starting with containerization and how this entire thing started.
Consistent environments from development to production are a huge part of why operators spend deployment nights being stressed out and unsure if things work as expected. My question here is: why?
If we look into the problems most try to solve with docker, here are some common answers:
- Easy deployment
- Packaging format
Whereas I can relate to rpm and deb as packaging formats not being the simplest ones, they in fact work very well. That’s how we update our servers and distribute applications for years and probably years to come. Yet we still have this one administrator that is the only one knowing why things work when everyone else is just guessing.
The secret sauce in why containers make sense and are innovative is the filesystem. Modern applications are not stand alone binaries that function without proper libraries around them. Shared libraries more specifically. Tools we install on the server to get it compatible to our applications. Sadly: Different applications require different libraries. And a simple maintenance update of the OS could by this break our entire production environment.
Containers to the rescue! Isolation between applications has been a measure we took in recent years to fight this issue.
But virtual servers have a few downsides and requirements
- virtual hardware / hypervisor technology thats potentially expensive and hard to operate
- lots of storage consumption for the OS itself
- Bootup time of the kernel
To fight these things Google utilized kernel namespaces from linux and extended them by what is called cgroups (control groups). Kernel namespaces allow isolation of processes in what they can see, cgroups define what hardware resources are available to the isolated processes.
Think of it as a prison cell:
Linux is the prison building.
Docker is the warden.
The namespaces define who is in the cell.
Cgroups define how big the cell is and what amenities you get.
Docker is now setting these cells up in the kernel. Thus docker is simply telling linux what to do, augmenting this with a dedicated filesystem per container and networking capabilities.
Why the filesystem? By packing all shared libraries the application requires right into the cell, you isolate the application in its entirety and remove any dependencies to the host. The only thing required is it running a more or less current linux kernel.
Now that you know what containers are, that docker is not the only option and how they function, you probably already got your hands dirty and started playing with them. And this is great! At some point and after successfully deploying them your infrastructure starts to grow. One server turns many, one container turns thousands of them. Time to rethink operations as `docker run` times a thousand plus monitoring all of them will take quite a long time.
The first thing that comes to mind is automation. And that’s exactly what kubernetes is doing. Instead of you manually typing `docker run` you delegate this to software.
And here we come to what Kubernetes actually is. Whereas docker is a remote control for the kernel, Kubernetes is a remote control for docker.
Looking into the architecture of Kubernetes you can see, that an engine like docker is always installed. In fact, let’s put this stronger: it is required to have an engine installed, that complies with the container runtime interface (CRI).
That container runtime interface is then utilized by an application called `kubelet` installed on all of your servers. Kubelet now constantly monitors the server and all containers running on the machine, storing all the gathered knowledge in the database of kubernetes. Taking this gathered intelligence into account, kubernetes can now develop elaborate strategies on container distribution and keeping them running as well as traffic distribution.
When to use what / The summary
The entire point of this article should be: this is not a binary decision. Containerization technologies are purpose built to isolate processes whereas Kubernetes is an orchestrator.
So technically, in order to use Kubernetes you have to use one or the other containerization technology like Docker, CRI-o or others. Kubernetes thus extends dockers capabilities to run clustered, plugging into container technologies and networking technologies all controlled by a unified and central api.
Here is another illustration of it:
I am always happy to answer questions, so feel free to reach out or check our Kubernetes Administrator Masterclass to get yourself trained!