4 min read
Updated July 25, 2018.
While many of us want to compare Kubernetes vs. Docker, the two systems actually provide closely related but seaparate functions. Both of these tools provide extensive capabilities to build and manage virtual containers at scale, but the ways they go about it differ significantly.
ALSO READ: Puppet vs. Chef: Comparing Configuration Management Tools
Kubernetes is an open source container storage program built by teams at Google and bases its container-worldview on how Google develops within their walls in Mountain View. While it provides a useful, scalable, and powerful tool, Kubernetes also gets a lot of clout because it’s an intricate and sometimes overly-complicated system. If you want an example of the power of Kubernetes, look no further than the launch of the Pokemon Go app. While there were troubles, that app is a prime example of the ability of Kubernetes (and containers) to scale rapidly.
Docker is a flexible container storage platform that takes usability into account, which should be expected for a consumer-focused product. While you can access and learn Docker for free with the community version, you can also purchase Enterprise subscriptions that come with their own perks.
The rapid rise of containerization tools from 2016-2018 has led to a proliferation of platforms that help companies better wrap their systems in security, scalability, and services. Google released its Cloud Services Platform in July of 2018 to compete with similar products offered by RedHat, AWS, VMWare, and Docker that all use Kubernetes to run containerized systems. These Platform as a Service (PaaS) models, which are also dubbed Container as a Service (CaaS) models make access to orchestrated containerized services quick and easy for companies looking to scale development via containers without constructing the surrounding infrastructure from scratch.
Comparing Kubernetes vs. Docker really comes down to comparing Kubernetes to Docker’s Swarm product. New subscribers to Docker have immediate access the Swarm features, while legacy versions require a quick toggle switch to turn it on.
Set Up and Installation
One of the main complaints users have about Kubernetes is that it uses a different setup for each OS. You can use the Kubernetes online resources to help you configure your workspace, but you should also prepare yourself to do plenty of googling to build custom environments that break from the standard implementation. Setting Kubernetes up takes a lot of planning, too, as you’ll need to define your nodes before you get started. Add to that some manual integrations, and the installation of Kubernetes can feel like a mammoth task.
Docker Swarm uses the docker CLI to run all portions of its programs. With Docker you’ll only need to learn that one set of tools to build your environments and configurations. Because the Swarm program runs on your current Docker, there’s almost no setup other than opting into the Swarm. From there, you can build your containers via commands as they arise, in contrast to how Kubernetes requires you to map out your clusters before you even begin.
Working in the Two Systems
Kubernetes can run on top of Docker but requires you to know the command line interface (CLI) specifications for both to access your data over the API. You must know your docker CLI to navigate within that structure, and then the supplemental Kubernetes CLI, kubectl, to run those programs. Have several developers running the containers throughout your network? They should become familiar with the Kubernetes CLI if they want to get anything done in those clusters.
Docker Swarm will feel much like working in other Docker tools (like Compose). You’ll use the same Docker CLI, and you can even spin up new containers with a single command. The speed and variability of this tool, along with its easy-to-use command structure gives Docker the usability edge. Whereas Kubernetes can feel like reinventing the wheel, Docker allows for speed. The major detraction from working in Docker? If you want to perform a function and can’t based on the current API, you’re stuck.
Logging and Monitoring
Kubernetes supports several versions of logging and monitoring when the services are deployed within the cluster:
- Elasticsearch/Kibana (ELK) logs within the container
- Heapster/Grafana/Influx for monitoring in the container
- Sysdig cloud integration
On the other hand, Docker only supports monitoring with third-party applications. Docker recommends using Reimann for monitoring, but the open API makes connecting with lots of apps easy. Docker logs can be shipped via ELK within the cluster as well.
Size Matters
The size and number of the containers you could spin used to define the difference in the choice between Kubernetes vs. Docker, but release of recent Docker updates has significantly closed the gap. Both systems now support 1,000 node clusters and up to 30,000 containers. Kubernetes may be somewhat difficult to get going, but once running, it boasts that 99 percent of API calls respond within one second. Once you spin up those containers, you have more flexibility around what you can do with them, too.
Docker reported on an independent test of Kubernetes vs. Docker in March of 2016. The study found that Docker could spin up the same number of containers five times faster than Kubernetes. This is largely due to the complexity of the Kubernetes tool.
Conclusions
Kubernetes vs. Docker is not an easy comparison. The elitist in me fights the former customer support agent: one wants to recommend the technology that has cooler roots and capabilities, while the other just wants things to work. Because of the recent release of PaaS and CaaS systems that streamline the use of Kubernetes, it’s no longer too complicated to be of immediate use to your local developer. My recommendation? Use both. Learn Kubernetes to orchestrate and Docker to contain, and work faster and with fewer failures than ever before.
To learn more about containerization and related products, check out our mobile device management software category page.
Update: This article has been updated to correct the definition of CLI from common language infrastructure to command line interface.
