If you are building server-based applications, at some point you are likely to encounter containers. Docker is a popular container technology that allows you to package and deploy an application and its dependencies. Kubernetes is a cluster and container management tool (often abbreviated as K8S). Both Docker and Kubernetes are complex technologies, and the vast details surrounding each make seeing the big picture harder. In preparation for a talk I gave at CodeMash 2020, I came up with an analogy to explain Docker and Kubernetes in relation to traditional server deployment. I realize any analogy is imperfect, but hopefully it helps you to understand how Docker differs from traditional server deployments, and how Docker relates to Kubernetes.
Let’s start with how web applications have traditionally been deployed. Regardless of platform, typically some kind of web or application server and its dependencies gets installed directly on the operating system of the host server, whether that is an actual server or a virtual machine. Sometimes there’s a database, and helper services or web APIs as well. Often more than one web site/application end up on the same server to efficiently use the server, but there is only so much memory and processing power to go around. Now, imagine the server is a house. There are only so many rooms in the house, and some of those rooms are common to all the occupants. Imagine that each application or database you install is an occupant of the house. They all bring their own furniture (or dependencies in software lingo) and a need for space and resources like water and electricity (memory and processing power). Unfortunately, sometimes the furniture styles clash, with some occupants bringing along mid-century modern furniture while others may have classic country style furniture. There is only so much space in the home so some of each occupants’ furniture ends up in the common areas. This might cause some occupants to behave poorly because of the style conflicts. On top of the style conflicts, it’s really difficult to manage how the occupants use the water and electricity in a house, and if one of the occupants misbehaves and consumes all the hot water (memory) it directly impacts the other occupants that need some hot water. If one of the occupants leaves the house, it’s often difficult to get rid of their old furniture. The other occupants may have come to rely on that furniture as well because it was in a common area. So removing the old furniture upsets other occupants.
Docker containers are one way to solve the conflicting occupants problem. To continue the analogy, think of a server hosting Docker containers as an apartment building. Each occupant gets their own apartment. They put their furniture in their own space, and this eliminates style conflicts with other occupants. Lots of poor behavior gets eliminated, and it’s really easy to change the occupant of a single apartment because the other occupants can’t use that furniture, they have to bring their own furniture. While the separation of occupants is good, there still can be resource issues. The plumbing and electricity of the building is split up between all the apartments, and each occupant doesn’t interfere directly with other occupants like they might in a house, but they can over-use resources if the apartment is poorly constructed. Containers make resource consumption more manageable but there is still a finite amount of space, water and electrical capacity in the building. That’s where Kubernetes helps out.
So lets look at how Kubernetes helps solve our resource issues and continue our analogy. Think of Kubernetes as an apartment complex (our analogy for a cluster of servers that host containers). We still get all the benefits of the apartment building but with added management of the occupants. The main office decides which occupants belong in which buildings according to their resource needs and available space. The main office can move the occupants around if their needs change or if there is a problem with their current building. The occupants still share resources the way they did in a single apartment building, but now there is a way to manage the apartment buildings. If all the resources get consumed, the complex could add additional buildings and move occupants to the new buildings to manage resource consumption. When visitors (messages, files, or network traffic in our software context) arrive, the main office directs them to the right building and apartment. The occupants don’t worry about any of these things, the main office just takes care of it.
This is, of course, an over-simplification of Kubernetes and leaves out a lot of the benefits of Kubernetes, does but I think the analogy is a good place to start when trying to understand what Docker is and its relationship to Kubernetes. Now it’s time to learn more technical details about both Docker and K8S. Here’s a couple good articles that are more technical starting points:
A feature-oriented description of Docker vs Kubernetes
Getting started with Docker and Kubernetes: a beginner’s guide
