Kubernetes vs Docker is not a contest, even if the search query sounds like one. Docker builds container images and runs containers on a single machine. Kubernetes takes finished images and runs them as an application across many machines: it distributes the containers, restarts them when they fail, scales them, and routes network traffic to them. In most projects the two work together: Docker in development and in the build pipeline, Kubernetes in operations.
The comparison you are probably really after is not Kubernetes against Docker, but Kubernetes against Docker Compose or Docker Swarm. Those are the tools Docker itself offers for running several containers together. That is where the difference shows, and that is where you decide which tool your project needs.
I have worked with containers in Kubernetes since 2017 and wrote the Kubernetes practical guide published by Rheinwerk Computing in 2024. Today I advise mid-sized companies and run clusters in production. Everything I have written about Kubernetes is collected on the Kubernetes page, and the basics are in Kubernetes explained simply.
Kubernetes vs Docker: who does what
Docker is first of all a tool for one machine. It consists of a daemon that starts and stops containers, a command line you control it with, and an image format plus a registry you push images to. A Dockerfile describes how an image is built, and docker run starts a container from it. That is the part almost every developer knows, and the reason Docker is often used as a synonym for containers, the way Kleenex stands for tissues.
Kubernetes does not care how an image comes into existence. It receives a description of the desired state: which image, how many copies, how much memory, which port faces outward. Then it makes sure that state is reached on a cluster of several servers and stays that way. If a server dies, the containers start on another one. If load increases, more copies run. If a new version arrives, Kubernetes swaps the containers one after the other without users noticing.
So the difference is one of level. Docker answers the question "How does my application run in a container?" Kubernetes answers the question "How do a hundred containers run on ten servers without anyone getting up at night?" That is not a comparison between equals, more like a workbench against a factory floor.
What Docker still is for Kubernetes today
One question comes up in almost every training: "Do I need Docker if I have Kubernetes?" The honest answer has two halves.
For running containers, Kubernetes no longer needs Docker. Kubernetes talks to a container runtime through an interface called the Container Runtime Interface (CRI), and in current clusters that runtime is usually containerd or CRI-O. containerd, by the way, is the core Docker uses internally; it was spun out of Docker as a separate project. The Docker daemon itself never fit cleanly into that interface. For a long time Kubernetes shipped a bridge called dockershim, which has not been part of Kubernetes since spring 2022. The project explains the background in its dockershim removal FAQ, and the setup of the runtimes is in the Kubernetes documentation on container runtimes.
For building images you still need a tool, and in most teams that tool is Docker. An image you build with docker build follows the OCI standard and runs unchanged under containerd in Kubernetes. Kubernetes itself does not build images. Your pipeline builds them, pushes them to a registry, and Kubernetes pulls them from there. Alternatives like Buildah or Kaniko exist, but you do not need to know them to get started with Kubernetes.
In practice that means: Docker Desktop on the laptop, Docker in CI, containerd in the cluster. Your Dockerfile is the part that stays the same everywhere.
The same application as a Compose file and as a Kubernetes manifest
The difference is clearest when you describe the same application in both worlds. Take an nginx web server that should be reachable on port 8080. With Docker Compose it looks like this:
services:
web:
image: nginx:stable
ports:
- "8080:80"
A docker compose up -d starts the container on your machine. Done. The file describes one container on one machine, and Compose does not want to do more than that.
The same application in Kubernetes needs two objects. A Deployment describes which image should run and in how many copies:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:stable
ports:
- containerPort: 80
A Service gives those copies a stable address inside the cluster, because the individual containers can be replaced at any time and change their IP address when that happens:
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 8080
targetPort: 80
That address is cluster-internal to begin with; you expose the application to the outside later through an Ingress or a Service of type LoadBalancer. With kubectl apply -f web-deployment.yaml -f web-service.yaml you hand both files to the cluster. Kubernetes creates two Pods from them, spreads them across the available nodes, and keeps them running. What a Pod is exactly and why Kubernetes wraps containers in one is explained in Kubernetes Pod: what is a Pod?.
Two things stand out immediately. First: the Kubernetes manifest is noticeably longer even though it does the same thing. Second: it contains settings that make no sense in Compose, such as replicas: 2. That line is the heart of the difference. You are not saying "start a container", you are saying "I want two of these running, always". If one dies, Kubernetes replaces it. That is what you pay for with the extra YAML.
When Docker Compose is enough
My first piece of advice when someone asks about Kubernetes for a small project: look at Compose. I mean that seriously. Compose is the right tool when your application runs on one machine and is allowed to stay there.
Do not underestimate what a single host carries. With a reverse proxy, TLS termination, health checks, backups and a clean update script, serious production setups run on one machine, sometimes for years. The limit of Compose is not how serious your application is, it is the number of machines.
That applies to more cases than the hype suggests. A development environment with database, backend, and frontend on a laptop. An internal tool used by a few dozen colleagues. A prototype nobody knows will still exist in three months. A company website with a contact form. In all of these cases Kubernetes brings complexity for a problem that does not exist yet. I deliberately wrote a section in my book about which companies Kubernetes is not a good fit for, and the startup case with three tiers on a single server sits right at the top.
Compose has three limits you should know. It only knows one machine. It restarts crashed containers, but it has no replacement for a failed server. And an update means a short outage, because the old container is stopped before the new one runs. As long as none of these three limits hurts, stay with Compose and save yourself a lot of operations work.
When you need Kubernetes
Among my clients, the move from Compose to Kubernetes was never triggered by a single feature but always by one of three thresholds.
The first threshold is downtime. As soon as an hour of outage costs money or trust, one server is no longer enough. Kubernetes spreads your application across several nodes and moves it automatically when one dies. That is why the control-plane nodes in my own clusters run in three different data centers.
The second threshold is the number of services. With three containers you still manage ports, environment variables, and restarts in your head. With fifteen services in four environments you do not. Kubernetes gives you namespaces, service discovery, rollouts with rollback, and one uniform API that tools like ArgoCD or Helm speak as well.
The third threshold is release frequency. If you deploy several times a day, you do not want an outage per deployment. Kubernetes swaps containers one after the other and checks that the new one is healthy first. Compose cannot do that, Swarm only in a simple form.
If one of these thresholds is in sight, getting started pays off. You do not need to rent a cluster for that: how to start Kubernetes on your own machine is covered in Kubernetes locally: a cluster on your machine.
Kubernetes vs Docker Swarm: why Swarm hardly matters any more
Docker Swarm was Docker's own answer to the question of how containers run across several machines. Swarm is built into Docker, is active within a minute with docker swarm init, and uses almost the same Compose file as development. That is convenient, and for a small team with two or three servers Swarm can still be enough today.
Even so, I do not recommend Swarm for new projects. Not because it is bad, but because the ecosystem lives elsewhere. Managed offerings from cloud providers, operators for databases, GitOps tools, policy engines, monitoring stacks, certifications, job postings: all of that targets Kubernetes. If you start with Swarm today, you build on an island, and the migration to Kubernetes comes later anyway, just with more legacy attached.
|
Docker Compose |
Docker Swarm |
Kubernetes |
| Runs on |
one machine |
several machines |
several machines |
| Server failure |
application gone |
containers move |
containers move |
| Zero-downtime updates |
no |
yes, in a simple form |
yes, with health checks and rollback |
| Automatic scaling by load |
no |
no |
yes |
| Configuration |
Compose file |
Compose file with extensions |
manifests, Helm, Kustomize |
| Learning effort |
low |
low |
high |
| Ecosystem and managed offerings |
not needed |
small |
very large |
| Fits |
development, small single servers |
small clusters without growth |
production with availability and scaling requirements |
The table also shows what Kubernetes costs: learning effort. That price is real, and I do not hide it in any client conversation. Compose is not a fallback, for a lot of projects it is the right answer.
The path from Compose to Kubernetes
If you have a Compose application and the threshold is reached, you do not start from zero. Your images stay, your Dockerfile stays, your registry stays. What changes is the description of how it runs.
For the first step there is Kompose, a tool from the Kubernetes project that translates a Compose file into Kubernetes manifests. The result is a usable starting point but not a finished production manifest: resource limits, health checks, secrets, and Ingress you have to add yourself. That is why I use Kompose more for learning than for migration. The translation shows you which Compose concept maps to which Kubernetes object.
After that I recommend three steps, in this order. First a local cluster where you try out the generated manifests. Then a Deployment and a Service per service written by hand, with requests, limits, and a readiness probe. Finally the manifests move into a Git repository from which a tool like ArgoCD feeds the cluster. From then on, Docker is once again what it was at the beginning of your day: the place where images are made.
Frequently asked questions
Do I need Docker to use Kubernetes?
Not for running containers: current clusters use containerd or CRI-O as the runtime. For building images you need a tool, and that is usually Docker. Your images run unchanged in Kubernetes because both follow the OCI standard.
Can Kubernetes replace Docker?
Only the part that runs containers. Building images, local development with Compose, and the registry remain Docker jobs. A more useful view: Kubernetes replaces Docker Compose and Docker Swarm in operations, not Docker itself.
Does a Docker Compose file run on Kubernetes?
Not directly, Kubernetes reads its own manifests. With Kompose you translate a Compose file and get Deployments and Services as a starting point. For production you then add resources, probes, and secrets.
Is Docker Swarm dead?
No, Swarm still ships with Docker and works. But the ecosystem, the managed offerings, and the ongoing development happen around Kubernetes. For new projects beyond one machine I would no longer bet on Swarm.
What is containerd?
containerd is a container runtime that pulls images, unpacks them, and starts containers. It sits inside the Docker daemon and runs on its own in Kubernetes through the CRI interface. For you as a developer nothing changes about images or Dockerfiles.
Where to go from here
The "Kubernetes vs Docker" decision is really the question: is one machine enough, or do I need a cluster? If one is enough, take Compose and enjoy the simplicity. If availability, many services, or a high release frequency are pressing, take the route through a local cluster and then into production.
If you are still missing the basics, read Kubernetes explained simply first. If you want to start your first cluster, continue with Kubernetes locally.
All of this, with every example, is in chapter 2 of my book "Kubernetes: Practical Guide for Developers and DevOps Teams" (Rheinwerk Computing). More about the book.
