Kubernetes and Docker: It’s not an either/or

This article was written by Udemy instructor Bret Fisher.

I’m a Udemy Instructor Partner, specializing in Docker and Kubernetes. I help students increase their agility and resilience, and reduce their time-to-deploy through mastery of these tools, ultimately building and scaling apps efficiently. 

Many like to pit the two against each other, and engage in the Kubernetes versus Docker debate. In my experience,the “versus” terminology doesn’t really give an accurate portrayal of the space: these tools aren’t an either/or proposition. Docker and Kubernetes are the two top container tooling brands, but it’s important to note that:

• Docker Engine is a “container runtime.” It knows how to run and manage containers on a single operating system host where you must control each host separately. (Note: A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Source: Docker.com)
• Kubernetes is a “container orchestration platform.” It knows how to manage containers across many operating system hosts, which in turn, run their own container runtime.

Docker origins

The concept of containerized applications – using containers to isolate many apps from each other on a single server – has existed for decades. Yet, there wasn’t an easy to use tool that focused on the full application lifecycle until Docker came into the picture.

Docker’s three key innovations

Docker invented three processes for containerized applications that were previously impossible:

1. Easy app packaging: Docker takes your application and all of its software dependencies (minus the OS kernel and hardware drivers) and bundles them in a set of tarballs (similar to zip files). Docker ensures these tarballs are identical on every machine they run on using cryptographic hashing. The app tarball(s) and metadata are known together as a “container image.” 
2. Easy app running: Docker runs each container in an isolated file system. Each container gets its own networking and resource limits and can’t access anything else on the host operating system. 
3. Easy app distribution: Docker created the idea of a “container image registry,” which allows users to store images in a central HTTP/S server and push/pull them easily (just as one could do using git commits). 

These three original innovations helped make Docker the #1 most wanted platform for multiple years in the Stack Overflow developer survey. 

Do we need Kubernetes?

The short answer is yes. Once you start using containers, you’ll want to use them everywhere – and once you have more than a few servers, you’ll wish there was an easier way to run multiple related containers for apps. The downside of Docker is that users still need to manually set up networks between servers, a task which, when it comes to dozens of related containers, creates as much work (if not more) as we had before containerized applications. This is the multi-server problem the Kubernetes founders wanted to solve. 

Kubernetes is to a group of servers what Docker is to a single server. It’s a set of programs and APIs that control many Docker Engines from one CLI (command line interface). Kubernetes orchestrates users’ containers with desired outcomes and it determines the best way to do that across a Kubernetes cluster. It then ensures those containers are always running. If one fails, it’ll recreate to ensure the actual state matches the desired state.

Kubernetes’ main job is to tell the container runtime (in this example, Docker) what to do, yet it now provides an increasing number of related duties. Other built-in features include container health checks, auto-replacing failed apps, automating web proxy configurations, managing network security policies, and auto-provisioning external storage.

One of the most significant features in Kubernetes is its extensibility in the form of Custom Resource Definitions (CRDs), which allow you to add new types of objects and functionality. CRDs turned Kubernetes from a container manager into a jack-of-all-trades automation engine for everything related to managing running applications on servers.

Should you use Docker and Kubernetes together?

Yes. If you only need to control containers on a single machine, and you’re new to containers, Docker tends to have the broadest feature support as a container runtime, especially on Windows Servers. However, if a user needs to run multiple containers for apps, it may be time to consider Kubernetes. Kubernetes can control Docker (or other runtimes as seen below), and you’ll likely still want to use Docker (and Docker Compose) on your local machine.

Using Kubernetes without Docker

Once you choose to run Kubernetes, you’ll rarely need to touch the CLI for your container runtime(Kubernetes will control it for you).  Kubernetes even created an API standard called Container Runtime Interface (CRI) to encourage more runtimes aside from Docker. As alternatives have matured (containerd and cri-o), we’ve seen Docker usage as the standard CRI drop.  I had a whole YouTube Live show on the dockershim deprecation to help you understand it. The good news is Mirantis picked up the maintainer work so we can all continue with Docker as our CRI, if needed.

Remember, tools aren’t the end goal.

Regardless of whether you choose Docker, Kubernetes, or a serverless approach, remember that the tool isn’t the ultimate objective. Always keep your business’s DevOps goals in mind.

Container implementation project metrics usually focus on increasing speed while also increasing reliability. However, the goals I tend to focus on when implementing these tools go broader, and include:

• Increasing agility: reduce the time from first code commit to customer delivery
• Reducing the time-to-deploy: time from an “approved release” to server deployment
• Increasing resiliency: how often you have failures, but more importantly, how quickly they are fixed

Containers and their tools can improve all of those factors. Still, they will come with their own “new problems” and additional workload. Be aware of the trade-offs when choosing your tools, and explore resources like Udemy to help you decide what makes the most sense for you.

I wish you good luck in your container journey, and may all your deployments be successful!