Get the report
More[EBOOK] Kubernetes Observability
Learn how how to monitor, troubleshoot, and secure your Kubernetes environment with Sumo Logic.
September 3, 2020
Kubernetes and Docker are considered to be best-in-class tools, and two of the most popular container orchestration solutions.
While Kubernetes and Docker are often compared as alternative solutions to one another, they are not direct competitors.
Docker is a container technology platform, and Kubernetes is a container orchestrator for platforms like Docker.
This post aims to clear up some common confusion surrounding Kubernetes and Docker, and explain what people really mean when they pit Docker vs. Kubernetes up against each other.
Learn how how to monitor, troubleshoot, and secure your Kubernetes environment with Sumo Logic.
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.
Multiple 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.
In addition to solving the major challenge of portability, managing 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 virtual machines (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.
Docker is currently the most popular container platform and widely used by site reliability engineers (SREs), DevOps and DevSecOps teams, developers, testers, and system admins .
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.
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.
A Docker image is a set of instructions (or a template) to build Docker containers.
While Docker provided an open standard for packaging and distributing containerized applications, there arose a new problem.
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.
An orchestration system like Kubernetes and Docker Swarm must:
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.
Docker Compose and Kubernetes are both container orchestration frameworks. The key difference between Docker Compose vs Kubernetes is that Kubernetes is used to run containers of several virtual or real computers. Whereas, Docker Compose can only run containers on a single host machine.
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.
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 computing providers offer Kubernetes as a service. Sumo Logic provides support for all orchestration technologies, including Kubernetes-powered applications.
Learn how Sumo Logic turns Kubernetes and Docker performance data into actionable insight and start your free trial today.
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 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.
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 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 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.
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.
It's pretty common to compare Kubernetes and Docker, however, a better comparison is Kubernetes vs Docker Swarm.
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.
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.
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 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 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.
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.
Learn how Sumo Logic turns Kubernetes and Docker performance data into actionable insight and start your free trial today.
Additional Resources
Monitor, troubleshoot and secure your Kubernetes clusters with Sumo Logic cloud-native SaaS analytics solution for K8s.
Learn more