A few words on Docker and Kubernetes
We all know Docker Engine; it’s a container runtime. We can run “docker run” on a host whether it’s a server or a VM, and it’ll start a container for us. Docker makes development and deployment much easier.
In general, if we talk about the Docker container image, it’s a means of packaging a software application with its dependencies, which can be binaries and libraries, that can then be running by a system that supports the Docker container format, most commonly that would be a Docker Engine.
But what if we’re in need to deploy 50 servers? Should we start one at a time? What if we bump into a scenario where more are needed to be started due to increasing number of clients?
Pretty soon after you get used to invoking “docker run” on a single host, you realize that to run many containers across multiple host requires (1) wiring them together, (2) organizing storage, (3) and most importantly a lot of “docker run” commands to make everything work. Docker itself doesn't prove itself at running at scale.
That’s when you wish you had something like Kubernetes running for you.
A few words about Kubernetes:
Kubernetes is not a container itself. Kubernetes is a Container Orchestration Environment that integrates against Dockers. It’s an open source system for running fleets of containers across multiple hosts. It has a higher level of constructs to make it easier to run collections of containers. Kubernetes makes sure that your application is running continuously. It makes sure, if a given container instance fails to recognize this and to spin up another container, or rather a POD. Kubernetes can also be configured to scale the application up or down in response to changes in demand.
Kubernetes creates a single daemon, kubelet, which runs on an individual machine. It’s important to understand that the kubelet by itself does not have much value on the table. It is this group of kubelets together with the Kubernetes controllers that control the Dockers, that make decisions about your whole cluster.
So, Kubernetes is about managing the work of a cluster of machines. And Docker is about running you application.
Docker itself also has an open source product named Swarm that allows us to build higher level constructs from individual containers. Swarm is a lot easier to understand than Kubernetes, but it’s not as powerful as Kubernetes.
Docker Swarm serves and integrates against the standard Docker API directly, that allows any tool that is already communicating with a Docker daemon to use Swarm to scale up into multiple hosts.
To wrap things up, Docker and Kubernetes are two different pieces of software, yet they’re related. They are related to each other in a way that they complete one another to make your life easier.
A good one. Makes things clear
CTO and co-founder at liminalhealth.ai
6 年Thank you for very concise explanation. Only sentence "..., rather POD" confused me a bit. I thought pod is group of dockers running the same service.