The two names appear side by side in job posts, tutorials, and conference talks, so it is natural to think they are rivals. They are not, and this chapter shows why.

Let us start with three plain definitions. A container is a small, sealed package that holds an application together with everything it needs to run, such as its code, its libraries, and its settings. Docker is the most famous set of tools for building and running such containers on a single computer. Kubernetes is a system that takes many containers and decides which computer should run each one, keeps them healthy, and connects them to each other and to the outside world. The word for that management job is orchestration, just like a conductor guiding an orchestra of musicians who each play their own instrument.

Where the confusion comes from

There are three main reasons. First, the word “Docker” is used for many things. It is the name of a company, of a desktop application, of a background program called the Docker Engine, and loosely of the whole idea of containers. When someone says “we use Docker”, they might mean any of these.

Second, Docker once had its own built-in orchestrator called Docker Swarm. Swarm did a smaller version of what Kubernetes does, so for a few years the two really were competitors. Kubernetes won that race, and Swarm became a niche choice. The memory of that rivalry still lingers in many articles.

Third, in 2022 Kubernetes version 1.24 removed a small piece of code that let it talk to the Docker Engine directly. Headlines shouted that Kubernetes was “dropping Docker”, and many beginners panicked. In truth, almost nothing changed for everyday users, and we will explain exactly why in a later chapter.

Before comparing the two tools, we must understand the one thing they both depend on: the container.

The “it works on my machine” problem

Every programmer has heard the sentence “but it works on my machine”. An application that runs perfectly on one laptop may crash on a server because the server has a different version of a library, a different setting, or a different operating system. Teams used to lose days chasing such differences. A container fixes this by carrying the application and its surroundings together, so the app sees the same world everywhere it goes.

Containers versus virtual machines

You may have heard of virtual machines, or VMs. A virtual machine pretends to be a whole computer, including its own full operating system. That is powerful, but heavy. A single VM often needs several gigabytes of disk space and may take minutes to start. A container is lighter because it borrows the operating system core, called the kernel, from the machine it runs on. It only carries the application and its libraries. A very small base image such as Alpine Linux is only about 5 megabytes, and a container usually starts in a second or less.

flowchart TB
    subgraph VMSIDE["Virtual Machines"]
        direction TB
        VH["Physical Server"] --> VHY["Hypervisor"]
        VHY --> VA["Guest OS 1 + App 1"]
        VHY --> VB["Guest OS 2 + App 2"]
    end
    subgraph CSIDE["Containers"]
        direction TB
        CH["Physical Server"] --> COS["Host Operating System Kernel"]
        COS --> CR["Container Runtime"]
        CR --> CA["App 1 + Libraries"]
        CR --> CB["App 2 + Libraries"]
    end

Because containers are light, one server can run dozens or even hundreds of them. That is why companies such as Netflix, Uber, and Spotify use them heavily: the same hardware serves more work at a lower cost.

Four words you will see everywhere

Docker did not invent containers, but it made them easy enough for everyone to use. That ease is the reason it changed the industry.

A short history

Container ideas existed long before Docker. Unix systems had a feature called chroot in 1979, and Linux gained the building blocks of modern containers in the 2000s. But using them was hard and needed deep expert knowledge. In 2013 an engineer named Solomon Hykes showed Docker to the world at a Python conference. It came from a small company called dotCloud. Docker wrapped the difficult pieces in a friendly command line and a simple file format, and within a few years almost every software team was talking about it.

The main parts of Docker

The three basic moves: build, ship, run

A container looks like magic, but it is built from a few clever features of the Linux operating system. Knowing them removes the mystery.

Here is the surprising truth: a container is not a tiny computer. It is just an ordinary program running on the host, wrapped in rules that limit what it can see and how much it can use. Two Linux features create those rules, and a third makes images efficient.

Namespaces: what the program can see

A namespace gives a program its own private view of part of the system. One namespace hides other programs so the container thinks it is the only thing running. Another gives it its own network address. Another gives it its own file system view and its own computer name. The program lives inside a small illusion of having a whole machine to itself.

Control groups: how much the program can use

A control group, usually shortened to cgroup, sets limits. It can say “this container may use at most half a processor and 512 megabytes of memory”. Without such limits, one greedy program could starve all its neighbours. Engineers at Google contributed the original cgroups feature to the Linux kernel in 2007, years before Docker existed. That is a hint about where Kubernetes ideas came from.

Layered file systems: how images stay small

A Docker image is made of stacked, read-only layers. When a container starts, Docker adds one thin writable layer on top. If ten containers use the same base layers, the computer stores those layers once and shares them. This saves disk space and makes downloads faster, because only missing layers need to travel over the network.

Networking and storage for a single container

A container is sealed, so it needs deliberate doorways to talk to the world. Docker gives every container a private network address on a virtual network inside the host. To let visitors reach a web application, you publish a port, which means telling Docker “send traffic arriving at this number on the host to that number inside the container”. Containers placed on the same virtual network can also find each other by name, which is how a web container reaches its database container.

Storage works in a similar deliberate way. A volume is a folder managed by Docker that lives outside the container’s own layers. When the container is deleted, the volume stays, and a new container can attach to it and carry on where the old one stopped. A bind mount is a simpler cousin that connects a folder from the host directly into the container, which developers love because they can edit code on their laptop and see changes instantly inside the running app.

The chain of programs behind one command

When you type a Docker command, several programs cooperate. The command-line tool sends your request to the daemon. The daemon hands the job to a lower-level manager called containerd, which downloads images and tracks running containers. Containerd then calls runc, a tiny program that asks the kernel to create the namespaces and cgroups and start your application. Once the container is running, runc exits and the kernel keeps enforcing the rules.

flowchart LR
    U["Developer runs Docker command"] --> CLI["Docker CLI"]
    CLI --> D["Docker Daemon dockerd"]
    D --> R["Registry such as Docker Hub"]
    D --> C["containerd"]
    C --> RC["runc"]
    RC --> K["Linux Kernel"]
    K --> NS["Namespaces: private view"]
    K --> CG["Cgroups: resource limits"]
    NS --> APP["Running Container"]
    CG --> APP

Why images work everywhere: open standards

In 2015 the industry created the Open Container Initiative, or OCI, to write shared rules for how images and runtimes should behave. Because of OCI, an image built by Docker can be run by other tools such as containerd, CRI-O, or Podman. This portability is the hidden reason that the 2022 Kubernetes change did not break anyone’s images.

Docker gets one container running. Kubernetes exists for the moment you have hundreds or thousands of them and a single human cannot keep track any more.

Where the name and the idea came from

The word Kubernetes comes from a Greek word meaning helmsman, the person who steers a ship. People often write it as K8s, because there are eight letters between the K and the s. Google created it, building on lessons from an internal system called Borg, which had been starting and managing Google’s own programs across huge fleets of machines for many years. Google announced Kubernetes in June 2014, released version 1.0 in July 2015, and handed it to a neutral home called the Cloud Native Computing Foundation, so that no single company controls it.

The problems it solves

Imagine your shop grows from one container to five hundred, spread over forty machines. Suddenly you face questions that Docker alone does not answer.

The big idea: you describe the goal, not the steps

With Kubernetes you do not give orders such as “start container A on machine 7”. Instead you write a description of the world you want, for example “I want three copies of my web app running, using this image, each with this much memory”. This description is called the desired state. Kubernetes constantly compares desired state with the actual state and fixes any difference. This repeating check-and-fix routine is called a control loop or reconciliation loop.

A Kubernetes installation is called a cluster. Every cluster has a thinking part and a working part, and knowing who does what makes everything else easier.

A cluster is a group of computers that act as one big machine. The computers that run your applications are called worker nodes. The computers that make decisions and keep records form the control plane. In small setups these can be the same machines, but in production they are usually separated.

flowchart TB
    USER["Engineer using kubectl or CI pipeline"] --> API
    EXT["Users on the internet"] --> LB["Cloud Load Balancer"]
    LB --> ING["Ingress Controller"]
    subgraph CP["Control Plane"]
        API["API Server"]
        ETCD["etcd database"]
        SCH["Scheduler"]
        CM["Controller Manager"]
        API  ETCD
        SCH --> API
        CM --> API
    end
    subgraph N1["Worker Node 1"]
        KL1["kubelet"]
        KP1["kube-proxy"]
        RT1["Container Runtime"]
        P1["Pod A"]
        P2["Pod B"]
        KL1 --> RT1
        RT1 --> P1
        RT1 --> P2
    end
    subgraph N2["Worker Node 2"]
        KL2["kubelet"]
        KP2["kube-proxy"]
        RT2["Container Runtime"]
        P3["Pod C"]
        KL2 --> RT2
        RT2 --> P3
    end
    API --> KL1
    API --> KL2
    ING --> P1
    ING --> P3

The parts, one by one

How pods talk to each other

Kubernetes follows one simple networking promise: every pod gets its own address, and every pod can reach every other pod without clever tricks, no matter which node each one lives on. The network plugin makes this promise true. Because pods are replaced often and their addresses change, other programs should never remember a pod’s address. They talk to a Service instead, which has a fixed name and address, and kube-proxy quietly forwards each request to one of the healthy pods behind it.

Traffic from the internet follows a slightly longer road. A cloud load balancer receives the visitor first and spreads visitors across nodes. An ingress controller, which is a web server that understands Kubernetes rules, then looks at the web address and decides which service should receive the request. You can think of it as the reception desk of a large building, sending each guest to the right office.

In Kubernetes, everything you want is described as an object. A handful of objects cover most of daily life.

The pod: the smallest unit

Kubernetes does not run bare containers. It wraps one or more containers in a pod. The containers in a pod always land on the same node, share one network address, and can share storage. Most pods hold just one container, but a second helper container can sit next to it when the two must work as a pair.

Labels: stickers that hold everything together

A label is a small tag such as “app equals shop” that you stick on objects. Other objects then find their targets by asking for “everything with this sticker”. This loose connection is what lets a service find its pods even as pods are replaced.

The most important objects at a glance

Deployment and Service: the everyday pair

Most stateless web applications use just two objects together. A Deployment says “keep three copies of this image running and update them gently”. A Service says “give all pods with this label one steady name and share incoming traffic between them”. Users and other apps talk to the service name and never worry about which pod answers.

Let us follow one application from the developer’s keyboard to a live service, first with Docker alone and then with Kubernetes added.

Path one: Docker on a single server

Path two: Kubernetes across a cluster

The first three steps are the same. The difference begins when the image is ready to run. Instead of logging in to servers, the engineer sends a description of the desired state to the cluster. Here is what happens inside, step by step.

sequenceDiagram
    participant E as Engineer
    participant A as API Server
    participant D as etcd
    participant C as Controllers
    participant S as Scheduler
    participant K as kubelet on Node
    participant R as Container Runtime
    E->>A: Submit Deployment with 3 replicas
    A->>D: Save desired state
    A-->>E: Accepted
    C->>A: Notice Deployment, create ReplicaSet and 3 Pods
    S->>A: Find Pods with no node, assign each to a node
    K->>A: See Pods assigned to my node
    K->>R: Pull image and start containers
    R-->>K: Containers running
    K->>A: Report Pod status Running
    Note over K,A: Health probes keep checking every few seconds

Notice a beautiful detail: the parts of Kubernetes do not give commands to each other. Each one simply watches the API server for work that belongs to it, does that work, and writes the result back. This makes the system loosely coupled, so one part can crash and restart without confusing the others.

The life of a pod

A pod moves through a few simple phases. It starts as Pending while the scheduler finds a node and the images download. It becomes Running when at least one container has started. If it finishes its work successfully, as a batch job does, it becomes Succeeded. If a container fails and cannot be restarted, it becomes Failed. If the node stops talking to the control plane, the state is Unknown. Pods are treated as disposable: when one dies, Kubernetes does not repair it, it creates a fresh replacement.

Health checks and rolling updates

Kubernetes uses small tests called probes. A liveness probe asks “is this container stuck?” and triggers a restart if it fails. A readiness probe asks “is this container ready to receive visitors?” and keeps traffic away until the answer is yes. When you release a new version, a rolling update starts a few new pods, waits for them to become ready, and only then removes old ones. Users see no interruption. If the new pods never become ready, the update pauses, and you can roll back to the previous version with one action.

Scaling in action

Suppose an online shop normally needs four pods to serve its visitors, but on a festival sale day traffic jumps to ten times the usual amount. A HorizontalPodAutoscaler watches a number such as average processor use. When the number climbs above the target you set, it raises the desired count of pods, and the normal control loops create them. If the cluster runs out of room, a separate cluster autoscaler can ask the cloud provider for more nodes. When the sale ends and traffic falls, the same process runs in reverse, and you stop paying for unused machines.

With plain Docker, the same event would need a human to start extra containers, adjust a load balancer, and remember to shut everything down afterwards. That manual effort is exactly the pain that Kubernetes was created to remove. It is also why companies with sudden traffic spikes, such as ticketing, food delivery, and streaming services, value it so highly.

Now that both tools are clear on their own, we can compare them fairly. The table below shows why they are teammates and not opponents.

Where Compose and Swarm fit

Swarm’s decline was helped by business events. Docker announced support for Kubernetes in 2017, and in 2019 the company sold its enterprise business to Mirantis. Swarm mode still works and some small teams like its simplicity, but most new projects choose Kubernetes.

The famous “Kubernetes dropped Docker” story

Kubernetes talks to container runtimes through a standard plug-in interface called the Container Runtime Interface, or CRI. The Docker Engine was created before this interface existed and does not speak it. To keep supporting Docker, Kubernetes carried a special adapter named dockershim. Maintaining that adapter was a burden, so version 1.24, released in 2022, removed it.

But remember the chain from Chapter D: the Docker Engine itself uses containerd underneath. Kubernetes simply started talking to containerd directly and skipped the middle layer. Images built with Docker follow the OCI standard, so they run unchanged. What really changed is that you can no longer type Docker commands on a Kubernetes node to inspect containers, and you use CRI tools instead.

Every tool gives something and takes something. Being honest about the costs is what separates a good decision from a fashionable one.

Docker

Kubernetes

The trade-offs that matter most

Power against simplicity. Kubernetes gives you automation, but each feature is one more thing to learn, configure, and debug. Flexibility against lock-in. Kubernetes runs almost anywhere, which protects you from depending on one cloud, but a fully managed cloud service can be faster to operate. Efficiency against isolation. Sharing a kernel packs more work onto each machine, yet a serious flaw in the kernel or runtime could affect all containers on that machine. For highly sensitive work, teams add extra sandboxing or separate machines.

Notice also the hidden cost: people. A Kubernetes platform needs engineers who understand it. For a team of three people running one website, the time spent on cluster upkeep may be larger than the benefit.

Thinking about cost honestly

Cost has three parts. The first is infrastructure: the machines, storage, and network traffic. Containers help here because they pack more work onto each machine, and Kubernetes helps further by scheduling pods onto nodes that have room. The second is platform overhead: a Kubernetes cluster runs its own helper programs on every node, and managed services usually charge a small hourly fee for each control plane. The third and biggest is human time: learning, upgrades, incident handling, and security reviews.

A useful rule of thumb is to compare the cost of a mistake with the cost of prevention. If an hour of downtime would cost your business a lot of money or trust, then automatic recovery and safe releases are worth their price. If an hour of downtime on a quiet evening costs almost nothing, a simpler setup is the wiser purchase.

Containers make delivery fast, but they also make it easy to ship a mistake to thousands of machines at once. Security must be planned in layers.

Docker-level protection

Kubernetes-level protection

Lessons from real incidents

In 2018, security researchers found that an administration console for a Kubernetes cluster at Tesla was reachable from the internet with no password. Attackers had used it to run hidden cryptocurrency mining inside the company’s cloud account. The lesson is simple and timeless: never leave management doors open to the public internet, and always require strong login. In 2019 a flaw in runc, the small program from Chapter D, allowed a malicious container to break out to the host on unpatched systems. The lesson: keep runtimes and nodes updated, because a shared kernel means bugs in the shared layer matter to everyone.

Containers appear and vanish quickly, so you cannot log in and look around after a problem. You must record what happens as it happens.

The three pillars

Monitoring with Docker

A healthy container writes its messages to standard output and standard error, and Docker collects them. You can read them with the logs command and see live processor and memory use with the stats command. Docker also supports health checks, which mark a container as healthy or unhealthy. For a single server this is often enough. For many servers you need a central place to gather everything.

Monitoring with Kubernetes

Kubernetes has no complete monitoring system built in, but it provides hooks for a rich ecosystem. A small add-on called metrics-server supplies basic processor and memory numbers and powers automatic scaling. kube-state-metrics reports the state of objects, such as how many pods are ready. Prometheus collects and stores metrics, Grafana draws dashboards, and Alertmanager sends messages to people when something crosses a limit. For logs, a small agent such as Fluent Bit runs on every node, reads container output, and forwards it to a search system like OpenSearch or Amazon CloudWatch. For traces, teams commonly use OpenTelemetry.

flowchart LR
    P["Pods write logs and expose metrics"] --> FB["Log agent on each node"]
    P --> PR["Prometheus collects metrics"]
    P --> OT["OpenTelemetry collector for traces"]
    FB --> LS["Central log store"]
    PR --> GF["Grafana dashboards"]
    PR --> AM["Alertmanager"]
    OT --> TS["Trace viewer"]
    AM --> ON["On-call engineer"]
    LS --> ENG["Engineers searching logs"]
    GF --> ENG
    TS --> ENG

What to watch first

Google’s engineers, in their well-known reliability book, suggest four golden signals that suit almost any service. They are latency, which is how long requests take; traffic, which is how many requests arrive; errors, which is how many requests fail; and saturation, which is how full your resources are. In Kubernetes also watch pod restarts, pods stuck in Pending, and nodes that are running out of memory or disk space.

Engineers have discovered reliable shapes for container applications, and also some tempting shapes that cause trouble.

Patterns that work well

Anti-patterns to avoid

These habits come from years of painful lessons in real production systems. Adopt them early and you skip most of the pain.

Good habits for Docker images and containers

Good habits for Kubernetes

Common mistakes and how to fix them

Failure scenarios and how each tool reacts

Good engineers plan for failure before it arrives. Consider three common events. If a single container crashes, Docker with a restart policy will start it again on the same machine, and Kubernetes will create a replacement pod, possibly on a different node. If a whole machine dies, Docker has no answer beyond a person noticing and acting, while Kubernetes notices that the node stopped reporting, waits a short grace period, and recreates its pods on healthy nodes. If a bad release is deployed, Docker offers no built-in memory of the previous version, while a Kubernetes Deployment keeps a history and can return to the last good version quickly.

These differences explain why teams practise failure on purpose. Netflix made this famous with its Chaos Monkey tool, which randomly shuts down servers during working hours to prove that the system survives. The same spirit works well on a Kubernetes cluster: delete a pod, drain a node, and watch that users notice nothing.

Theory is useful, but seeing how real companies think makes the choice clearer.

How well-known organisations use these tools

A simple way to decide

flowchart TD
    S["Start: I have an application"] --> Q1{"Do I need it to run the same everywhere?"}
    Q1 -->|"Yes"| D["Package it with Docker"]
    Q1 -->|"No"| STOP["Plain servers may be enough for now"]
    D --> Q2{"More than a few services or servers?"}
    Q2 -->|"No"| C["Docker Compose on one server or a simple managed container service"]
    Q2 -->|"Yes"| Q3{"Need auto-scaling, self-healing, zero-downtime updates?"}
    Q3 -->|"Yes"| Q4{"Do I have a platform team?"}
    Q3 -->|"No"| C
    Q4 -->|"Yes"| K["Kubernetes, self-managed or managed"]
    Q4 -->|"No"| M["Managed Kubernetes such as EKS, GKE, AKS, or ECS with Fargate"]

Short, plain answers to the questions beginners ask most.

Let us close the loop with the lunchbox and the cafeteria one more time.

Docker made packaging simple. It taught the world to put an application and its surroundings into one portable box and to move that box anywhere. Kubernetes then solved the next problem: when there are thousands of boxes and hundreds of machines, someone must place them, watch them, replace the broken ones, connect them, and update them without stopping the service. The two tools meet at the container image, which is the standard box they both understand. Choosing between them is rarely an either-or decision. It is a question of timing, and of how much complexity your project can honestly justify.