Both Docker and Kubernetes are ubiquitous tools nowadays. They’re two of the most popular existing open-source projects. Whether your workloads run in the cloud or on-premise, it’s exceedingly likely that you’ll be using these two technologies together to put your code into production. In this post, I will compare Kubernetes vs. Docker by introducing you to their similarities and differences.
Docker’s documentation describes it as:
Docker is an open platform for developing, shipping, and running applications.
Docker allows you to package and run an application in an isolated environment called a container. It’s a similar concept to a Virtual Machine, although a container is less isolated than a VM. As a result, it’s more lightweight and faster to boot.
You describe the application and its dependencies in a Dockerfile and then create an image out of it. This image runs almost everywhere without change, thus decreasing the effort of running it in heterogeneous environments. It’s fast and portable. People sometimes call this immutable infrastructure.
Docker isn’t just a way of putting applications into containers, though. Docker includes dockerd, a daemon that allows you to run containers inside a host machine. Developers often run it in their development machines to get an environment that’s closer to production.
Orchestration With Kubernetes
Even though people often mention Docker and Kubernetes in the same sentence, they fulfill different purposes. Kubernetes is an orchestration platform. It’s a way of managing and running containerized workloads, born from the Borg project at Google.
Kubernetes abstracts running applications at scale for you. It runs as a cluster with a combination of control plane nodes and worker nodes. You define your applications declaratively and schedule them. Kubernetes starts those applications, keeps them running, scales them as needed, and restarts them if necessary.
Source: Kubernetes Components
Kubernetes is a complex piece of software. It provides networking, load balancing, storage, access control, and many other capabilities. Through custom resources, it’s gotten even more extensible. There’s a gigantic community around it. All the major cloud providers have managed offerings to take some of this complexity away from you.
If you want to learn about Kubernetes, I’d recommend getting familiar with Docker first. After that, you can check out this course.
A Productive Synergy
Docker and Kubernetes work well together. With Docker, you package your applications so that they’re easy to share and run in any environment. Meanwhile, Kubernetes takes these images and runs them for you, hiding the grisly details.
Here’s a typical workflow for an application that you want to deploy:
- Package the application as a container as part of a CI/CD
- Publish the image to a Docker registry.
- Deploy the image to a testing environment using a tool like ArgoCD.
- When you confirm that everything works, deploy that same image to production.
Neither Docker nor Kubernetes does something that wasn’t possible before. Nonetheless, their convenience and speed cause many organizations to adopt them.
It’s Not So Clear-Cut
Thus far, this looks neatly delimited. Reality is a bit messier, though. For starters, Kubernetes used to run dockerd as a container runtime in the individual nodes of the cluster. The runtime has switched, but the idea behind it is the same.
In addition to that, Docker has an offering in the orchestration space, called Docker Swarm. It’s fair to say that Kubernetes has won the orchestration wars, as its popularity has completely eclipsed Swarm’s.
Toward Cloud-Native Applications
Unless you’re going for a serverless architecture, using both Docker and Kubernetes is a solid bet to bring your applications to production. Building containers simplifies the process of packaging and running them in different environments, and Kubernetes is a way of orchestrating those applications.
Both topics (especially Kubernetes) are vast, so be sure to dive deeper into them if you want to understand them in more depth!