What’s the Difference Between Docker and Kubernetes?
Docker and Kubernetes are two of the most talked about technologies out there right now. A common question from new Revelry customers, particularly ones who are excited to get to use the latest cutting-edge DevOps technology, is “Should we choose Docker or Kubernetes?” The answer is: we’re going to use both.
Why are we going to use both Docker and Kubernetes?
To explain why, we need to talk about what Kubernetes and Docker each are. Kubernetes and Docker are not direct competitors. In fact, most teams using Kubernetes are also using Docker, though some are using alternatives (more below).
What is Docker?
Docker is an engine for running “containers.” Containers are an approach for bundling up an application and all of the things it needs to work. This enables the application to run without problems. This is a form of “dependency management,” which means declaring what your application needs to run in advance, and automatically making sure those things are there before you run the app.
Containers also provide some isolation between different applications which are running on the same machine. This prevents multiple applications running on the same computer from conflicting with each other and causing problems.
Docker isn’t the only container engine out there. Alternatives to Docker include rkt and containerd. The folks behind Docker, rkt, and containerd are working on the Open Container Initiative. This will produce a set of common specifications so that Docker, rkt, containerd, and others can all work interchangeably.
OCI spec support varies from engine to engine now, but these teams are working to finish v1.0 of the spec and support it in their engines.
What is Kubernetes?
Kubernetes is a system for automating the deployment and scaling of containerized applications. It handles concerns like scheduling, networking, storage, and replication of apps which run in containers. Kubernetes does not run those containerized apps directly. That’s where a container engine like Docker comes in. Kubernetes uses Docker (or rkt, or containerd) to run the containers for these applications.
What about Docker Swarm?
Docker Swarm is an orchestration and clustering tool made by the Docker team. Since it is a clustering and orchestration tool, Docker Swarm has more similarities with Kubernetes than the Docker Container Engine itself does. For example, it can handle networking, replicas, and load balancing. I would place Docker Swarm as a solution somewhat between Docker and Kubernetes. It does more than Docker alone to coordinate between multiple running containers. But, it does not have all of the flexibility and feature set that Kubernetes has. It manages fewer kinds of resources.
In other words, Kubernetes and Docker are different layers.
Docker provides a basic engine for running one app in isolation from others. If your problem is that you want to isolate one application from other applications running on the same machine, Docker is one way to manage that.
If you want to ensure that an application is always run along with its dependencies, Docker is a way to manage that. Kubernetes handles running many containerized apps side-by-side in an organized and reliable fashion.
If you want a way to host many containerized apps, or many copies of the same containerized app and to provide networking and storage for those apps, Kubernetes will help you. First, you need to figure out how to get that application into a container. Kubernetes is “bigger picture” than Docker.
One tech stack can contain both.
At Revelry, we use both Docker and Kubernetes for this reason. We host our applications in Kubernetes and we use Kubernetes to manage various resources needed to support those apps. We also use Docker as the container execution engine in Kubernetes. So when we build a new application, we first have to make it runnable in Docker. And then, we can deploy it into Kubernetes.
I hope that this demystifies the difference between Kubernetes and Docker for you.
At Revelry, we make Platform technology easy to use.