Kubernetes Course
Kubernetes vs Docker
This is the question that confuses almost everyone who's new to this space. People hear both names in the same sentence so often that they assume they're competing tools, or that one replaces the other. Neither is true. Let's sort this out once and for all.
Think of It Like a Restaurant Kitchen
This analogy is going to make the rest of this lesson very easy to follow.
The chef knows how to take raw ingredients and cook a perfect dish. Every time. Give Docker a recipe (a Dockerfile) and it will package your application into a container — consistently, reliably, on any machine.
The manager doesn't cook. But they decide how many chefs are working, which kitchen each chef uses, what happens when a chef calls in sick, and how to handle a sudden rush of 500 customers without anyone waiting too long.
You need both. The chef without a manager is chaos when the restaurant gets busy. The manager without a chef has nobody to actually make the food.
That's Docker and Kubernetes in a nutshell. Docker creates and runs the containers. Kubernetes orchestrates them at scale.
What Docker Actually Does
Docker has one job and it does it brilliantly. It takes your application — your code, your libraries, your config — and wraps it into a single portable unit called a container image.
That image can run on any machine that has Docker installed. Your laptop. Your colleague's laptop. A server in Frankfurt. A cloud machine in Singapore. Same image, same result, every time.
That's it. That's Docker's job. Write a Dockerfile → build an image → run a container. Elegant, simple, powerful.
Now here's where Docker runs out of answers. You have one container running. What if you need twenty? What if one crashes? What if the server it's running on dies? What if you need to update it without downtime? Docker alone has no good answer to any of these questions. That's not a criticism — it was never trying to solve them.
What Kubernetes Actually Does
Kubernetes picks up exactly where Docker leaves off. It takes those container images that Docker built and decides:
Notice that none of that is about building images or starting a single container. That work is already done by Docker. Kubernetes is purely about managing what happens at scale, over time, across many machines.
Side by Side — The Real Differences
| Question | Docker | Kubernetes |
|---|---|---|
| What does it do? | Builds, packages and runs containers on a single machine | Manages containers running across many machines |
| What does it work with? | Your source code and a Dockerfile | Container images that already exist (built by Docker or anything else) |
| How many machines? | One — the machine you're on | Many — a whole cluster of machines |
| What happens if a container crashes? | Nothing — it stays down until you restart it manually | Kubernetes detects it and starts a replacement automatically |
| Scaling? | Manual — you run extra docker run commands yourself | Automatic — Kubernetes scales up and down based on traffic |
| Zero-downtime deploys? | Not built in — you'd have to script this yourself | Built in — rolling updates replace containers one at a time |
| Good for? | Development, building images, running containers locally | Production deployments, large-scale systems, microservices |
Do They Work Together?
Yes — and for a long time, almost every Kubernetes cluster used Docker directly as its container runtime. The typical workflow in most teams looks like this:
docker build -t payment-api:v2 . — Docker reads the Dockerfile and creates a versioned, portable image.docker push payment-api:v2 — The image is uploaded to a central store (Docker Hub, AWS ECR, Google Artifact Registry) so all servers can access it.A Quick Note: Kubernetes Doesn't Require Docker
Here's something that trips a lot of people up. In late 2020, the Kubernetes project announced it was deprecating direct Docker support. Headlines popped up everywhere: "Kubernetes is dropping Docker!" People panicked.
The reality was much less dramatic. Kubernetes didn't remove Docker from the picture at all. It just changed how it talks to the container runtime underneath. Instead of calling Docker directly, Kubernetes now uses a standard interface called CRI (Container Runtime Interface) that any compatible runtime can plug into.
The important takeaway? Your Docker images still work everywhere. The image format is standardised (it's called OCI — Open Container Initiative). A container image built with Docker will run on containerd, CRI-O, or any other compliant runtime without any changes. You don't need to rebuild anything.
Think of it like a USB drive. Old USB-A and new USB-C are different connectors, but the data on the drive is the same. The container image is the data. The runtime is just the port.
What About Docker Compose?
If you've used Docker before, you've probably come across Docker Compose. It lets you run multiple containers together on a single machine using a simple YAML file. A lot of developers use it locally to spin up their app alongside a database and a cache in one command.
Docker Compose is great for development. But it only works on one machine. The moment you need things to run across multiple servers, survive failures, or scale automatically — it has nothing to offer. That's the wall you hit, and that's exactly when teams graduate to Kubernetes.
| Docker Compose | Kubernetes | |
|---|---|---|
| Machines | One only | Many — a whole cluster |
| Self-healing | No | Yes |
| Auto-scaling | No | Yes |
| Rolling updates | No | Yes |
| Best for | Local development | Production at any real scale |
The Mental Model to Keep Forever
Every time you see "Kubernetes vs Docker" written as a competition, remember: they sit at completely different layers of the stack. Asking which one wins is like asking whether a factory needs workers or a factory manager. It needs both.
In this course you will be writing Kubernetes YAML files and running kubectl commands — not writing Dockerfiles. We assume your containers already exist (either ones you built yourself or publicly available images from Docker Hub). If you've never used Docker before, that is completely fine for this course. But at some point, spending an hour or two on the official Docker getting-started guide will fill in that gap nicely and make your understanding of the whole stack much stronger.
Practice Questions
Type from memory — no scrolling back up.
1. What is the name of the container runtime that most modern Kubernetes clusters use under the hood — and which is also the core engine inside Docker itself?
2. Docker Compose is great for local development but only works across ________ machine — which is why teams move to Kubernetes for production.
3. Container images built with Docker work on containerd, CRI-O and other runtimes because they all follow the same standard image format. What is that standard called?
Knowledge Check
Pick the best answer.
1. What is the most accurate way to describe the relationship between Docker and Kubernetes?
2. You're running a container directly with Docker (no Kubernetes). The container crashes. What happens?
3. Kubernetes now uses containerd instead of Docker directly. What does this mean for your existing Docker container images?
Up Next · Lesson 4
Kubernetes Architecture
We crack open the cluster and look at every single component — the control plane, the worker nodes, and how they all talk to each other to keep your applications running.