Kubernetes vs. Docker: What Does It Really Mean?

“Kubernetes vs. Docker” is a phrase that you hear more and more these days as Kubernetes becomes ever more popular as a container orchestration solution.

However, “Kubernetes vs. Docker” is also a somewhat misleading phrase. When you break it down, these words don’t mean what many people intend them to mean, because Docker and Kubernetes aren’t direct competitors. Docker is a containerization platform, and Kubernetes is a container orchestrator for container platforms like Docker. 

This post aims to clear up some common confusion surrounding Kubernetes and Docker, and explain what people really mean when they talk about “Docker vs. Kubernetes.”

Kubernetes vs Docker: The Rise of Containerization and Docker

It is impossible to talk about Docker without first exploring containers. Containers solve a critical issue in the life of application development. When developers are writing code they are working on their own local development environment. When they are ready to move that code to production this is where problems arise. The code that worked perfectly on their machine doesn’t work in production. The reasons for this are varied; different operating system, different dependencies, different libraries. 

Containers solved this critical issue of portability allowing you to separate code from the underlying infrastructure it is running on. Developers could package up their application, including all of the bins and libraries it needs to run correctly, into a small container image. In production that container can be run on any computer that has a containerization platform.

Kubernetes vs Docker: Advantages of Containers

In addition to solving the major challenge of portability, containers and container platforms provide many advantages over traditional virtualization. 

Containers have an extremely small footprint. The container just needs its application and a definition of all of the bins and libraries it requires to run. Unlike VMs which each have a complete copy of a guest operating system, container isolation is done on the kernel level without the need for a guest operating system. In addition, libraries can be across containers, so it eliminates the need to have 10 copies of the same library on a server, further saving space. If I have 3 apps all running node and express, I don't have to have 3 instances of node and express, those apps can share those bins and libraries.  Allowing for applications to become encapsulated in self-contained environments allows for quicker deployments, closer parity between development environments, and infinite scalability.

What is Docker?

Docker is currently the most popular container platform. Docker appeared on the market at the right time, and was open source from the beginning, which likely led to its current market domination. 30% of enterprises currently use Docker in their AWS environment and that number continues to grow. 

What is Docker used for?

When most people talk about Docker they are talking about Docker Engine, the runtime that allows you to build and run containers. But before you can run a Docker container they must be built, starting with a Docker File. The Docker File defines everything needed to run the image including the OS network specifications, and file locations. Now that you have a Docker file, you can build a Docker Image which is the portable, static component that gets run on the Docker Engine. And if you don’t want to start from scratch Docker even has a service called Docker Hub, where you can store and share images. 

Docker vs Kubernetes: The Need for Orchestration Systems

While Docker provided an open standard for packaging and distributing containerized applications, there arose a new problem. How would all of these containers be coordinated and scheduled? How do you seamlessly upgrade an application without any interruption of service? How do you monitor the health of an application, know when something goes wrong and seamlessly restart it? 

Solutions for orchestrating containers soon emerged. Kubernetes, Mesos, and Docker Swarm are some of the more popular options for providing an abstraction to make a cluster of machines behave like one big machine, which is vital in a large-scale environment.

The truth is that containers are not easy to manage at volume in a real-world production environment. Containers at volume need an orchestration system.

What does an orchestration system need to do? Among other things, it must:

• Handle a large volume of containers and users, simultaneously. An application may have thousands of containers and users interacting with each other at the same time; managing and keeping track of these interactions requires a comprehensive overall system designed specifically for that purpose.
  
• Manage service discovery and communication between containers and users. How does a user find a container and stay in contact with it? Providing each microservice with its own, built-in functions for service discovery would be repetitive and highly inefficient at best; in practice, it would be likely to lead to intolerable slowdowns (or gridlock), at scale.
  
• Balance loads efficiently. In an ad-hoc, un-orchestrated environment, loads at the container level are likely to be based largely on user requirements at the moment, resulting in highly imbalanced loads at the server level, along with logjams resulting from the inefficient allocation and resulting limited availability of containers and system resources. Load-balancing replaces this semi-chaos with order and efficient resource allocation.
  
• Authentication and security. An orchestration system such as Kubernetes makes it easy to handle authentication and security at the infrastructure (rather than the application) level, and to apply consistent policies across all platforms.
  
• Multi-platform deployment. Orchestration manages the otherwise very complex task of coordinating container operation, microservice availability, and synchronization in a multi-platform, multi-cloud environment.

An orchestration system serves as a dynamic, comprehensive infrastructure for a container-based application, allowing it to operate in a protected, highly organized environment, while managing its interactions with the external world.

Kubernetes is well-suited to the task and is one of the reasons it has become so popular.

Kubernetes vs Docker Swarm

When most people talk about “Kubernetes vs. Docker,” what they really mean is “Kubernetes vs. Docker Swarm.” The latter is Docker’s own native clustering solution for Docker containers, which has the advantage of being tightly integrated into the ecosystem of Docker, and uses its own API. Like most schedulers, Docker Swarm provides a way to administer a large number of containers spread across clusters of servers. Its filtering and scheduling system enables the selection of optimal nodes in a cluster to deploy containers.

What is Kubernetes used for?

Kubernetes is the container orchestrator that was developed at Google which has been donated to the CNCF and is now open source. It has the advantage of leveraging Google’s years of expertise in container management. It is a comprehensive system for automating deployment, scheduling and scaling of containerized applications, and supports many containerization tools such as Docker.

For now, Kubernetes is the market leader and the standardized means of orchestrating containers and deploying distributed applications. Kubernetes can be run on a public cloud service or on-premises, is highly modular, open source, and has a vibrant community. Companies of all sizes are investing into it, and many cloud providers offer Kubernetes as a service. Sumo Logic provides support for all orchestration technologies, including Kubernetes-powered applications.

How does Kubernetes work?

It is easy to get lost in the details of Kubernetes, but at the end of the day, what Kubernetes is doing is pretty simple. Cheryl Hung of the CNCF describes Kubernetes as a control loop. Declare how you want your system to look (3 copies of container image a and 2 copies of container image b) and Kubernetes makes that happen. Kubernetes compares the desired state to the actual state, and if they aren’t the same, it takes steps to correct it.

Kubernetes architecture and components

Kubernetes is made up many components that do not know are care about each other. The components all talk to each other through the API server. Each of these components operates its own function and then exposes metrics, that we can collect for monitoring later on. We can break down the components into three main parts.

1. The Control Plane - The Master.
2. Nodes - Where pods get scheduled.
3. Pods - Holds containers.

The Control Plane - The Master Node

The control plane is the orchestrator. Kubernetes is an orchestration platform, and the control plane facilitates that orchestration. There are multiple components in the control plane that help facilitate that orchestration. Etcd for storage, the API server for communication between components, the scheduler which decides which nodes pods should run on, and the controller manager, responsible for checking the current state against the desired state.

Nodes

Nodes make up the collective compute power of the Kubernetes cluster. This is where containers actually get deployed to run. Nodes are the physical infrastructure that your application runs on, the server of VMs in your environment.

Pods

Pods are the lowest level resource in the Kubernetes cluster. A pod is made up of one or more containers, but most commonly just a single container. When defining your cluster, limits are set for pods which define what resources, CPU and memory, they need to run. The scheduler uses this definition to decide on which nodes to place the pods. If there is more than one container in a pod, it is difficult to estimate the required resources and the scheduler will not be able to appropriately place pods.

The relationship between Docker and Kubernetes

Kubernetes and Docker are both comprehensive de-facto solutions to intelligently manage containerized applications and provide powerful capabilities, and from this some confusion has emerged. “Kubernetes” is now sometimes used as a shorthand for an entire container environment based on Kubernetes. In reality, they are not directly comparable, have different roots, and solve for different things.

Docker is a platform and tool for building, distributing, and running Docker containers. It offers its own native clustering tool that can be used to orchestrate and schedule containers on machine clusters. Kubernetes is a container orchestration system for Docker containers that is more extensive than Docker Swarm and is meant to coordinate clusters of nodes at scale in production in an efficient manner. It works around the concept of pods, which are scheduling units (and can contain one or more containers) in the Kubernetes ecosystem, and they are distributed among nodes to provide high availability. One can easily run a Docker build on a Kubernetes cluster, but Kubernetes itself is not a complete solution and is meant to include custom plugins.

Kubernetes and Docker are both fundamentally different technologies but they work very well together, and both facilitate the management and deployment of containers in a distributed architecture.

Difference between Docker and Kubernetes

It's pretty common to compare Kubernetes and Docker, however, a better comparison is Kubernetes vs Docker Swarm.

Docker Swarm is orchestration technology similar to Kubernetes. Docker Swarm is naturally tightly integrated within the Docker ecosystem and focuses on the clustering of Docker containers.

A major difference between Docker and Kubernetes is that Docker runs on a single node, whereas Kubernetes is designed to run across a cluster.

Another difference between Kubernetes and Docker is that Docker can be used without Kubernetes, whereas Kubernetes needs a container runtime in order to orchestrate.

Since its initial release in 2015, Kubernetes has been widely adopted, and at this point, has become the de facto standard for container management and orchestration. Kubernetes provides an infrastructure-level framework for orchestrating containers at scale, and for managing user interaction with them.

In much the same way, Docker has become the standard for container development and deployment. Docker provides a platform for developing, deploying, and running containers at a much more basic, nuts-and-bolts level. It is the ground on which the Kubernetes framework sits.

Can you use Docker without Kubernetes?

Docker is commonly used without Kubernetes, in fact this is the norm. While Kubernetes offers many benefits, it is notoriously complex and there are many scenarios where the overhead of spinning up Kubernetes is unnecessary or unwanted.

In development environments it is common to use Docker without a container orchestrator like Kubernetes. In production environments often the benefits of using a container orchestrator do not outweigh the cost of added complexity. Additionally, many public cloud services like AWS, GCP, and Azure provide some orchestration capabilities making the tradeoff of the added complexity unnecessary.

Can you use Kubernetes without Docker?

As Kubernetes is a container orchestrator, it needs a container runtime in order to orchestrate. Kubernetes is most commonly used with Docker, but it can also be used with any container runtime. RunC, cri-o, containerd are other container runtimes that you can deploy with Kubernetes. The Cloud Native Computing Foundation (CNCF) maintains a listing of endorsed container runtimes on their ecosystem landscape page and Kubernetes documentation provides specific instructions for getting set up using ContainerD and CRI-O.

Kubernetes or Docker: Which Should You Adopt?

You've probably run into discussions of Kubernetes and Docker that position them as rivals offering the same basic functionality, with the implication that you would normally choose one or the other. By now, however, it should be clear that they are not rivals in any real way, and that their core technologies are, for the most part, complementary.

What then are your choices when it comes to Kubernetes and Docker? What happens if you do choose to use only one and not the other?

Docker Without Kubernetes

Docker by itself will allow you to build container images, manage them in a registry, run containers and communicate with them, and put them together in a multi-container application using Docker Compose. So, is Docker all you need?

When it comes to producing and managing container images and putting containers into operation at the runtime level, the answer, for the most part, is "Yes." It has become the industry standard for creating containers and getting them off the ground.

Under Docker's current, developer-centric definition of its mission, however, it has moved away from earlier attempts to go beyond its core functions. It is no longer attempting to compete with Kubernetes and other companies at the infrastructure/orchestration level.

Kubernetes Without Docker

Kubernetes does not include functionality for creating or managing container images, and it does not, by itself, run containers; it needs to work with an external container source and runtime. It is, however, capable of using containers from a variety of sources, and it is compatible with runtimes other than dockerd, so it is not inherently dependent on Docker and Docker alone.

What Kubernetes does provide is a rich, flexible, and powerful framework for defining applications and orchestrating containers, at scale. It is well-designed for key enterprise-level tasks such as automated scaling, maintaining high availability, and operating in a multi-platform environment. It also has a large community of users and developers, with a corresponding large number of add-ons and support tools.

Kubernetes With Docker

What's the best choice, then? That's not a trick question. The answer is the obvious one: both.

The truth is that although Kubernetes can use other container sources and runtimes, it is designed to work well with Docker, and much of Kubernetes' documentation was written with Docker in mind. The most basic Kubernetes use case is Kubernetes + Docker, and Kubernetes includes Docker-centric tools such as Kompose, which converts Docker Compose commands and settings so they can be used by Kubernetes.

For its part, Docker has embraced Kubernetes, and has, in fact, offered its own integrated Kubernetes distribution. The sale of Docker Enterprise to Mirantis in late 2019 (along with Docker's own renewed focus on developer-oriented tools) even more sharply emphasized Docker's reliance on Kubernetes and other container infrastructure providers. This is underscored by Mirantis' stated intention to phase out Docker Swarm and establish Kubernetes as the default orchestration tool for Docker Enterprise.

The bottom line is that Kubernetes and Docker are both industry standards in their respective core areas of expertise, and together they provide a well-integrated platform for container management, deployment, and orchestration at scale. It was never really a question of Kubernetes vs Docker; it was always Kubernetes and Docker, and today this is even more true.

Additional Resources

• What is Kubernetes?
• Monitoring k8s-powered Apps
• Get Started with Kubernetes
• OpenShift vs Kubernetes
• Kubernetes Load Balancer
• Kubernetes Security