Kubernetes vs Docker: Differences and How They Work Together
They aren't alternatives: one builds and runs containers, while the other orchestrates them across machines. Learn what each does and when you need both.
On this page
To understand the difference, it helps to look at the comparison with freight transport, from which these tools borrowed their names and logos: Docker’s whale loads containers, while Kubernetes’ helm (in Greek kubernetes means “helmsman”) guides them.
The container and the port #
The container is a standard box. Inside, you put your application, its libraries, and the exact version of the language it needs. From the outside, it’s always the same box with the same fittings: whoever moves it doesn’t need to know what’s inside. This eliminates the classic “it works on my machine” problem.
Unlike a virtual machine, a container doesn’t carry an entire operating system with it: it uses the kernel of the host system. Because of this, it starts in a second and weighs tens of megabytes instead of gigabytes. In exchange, it is less isolated than a VM, and a Linux container requires a Linux kernel.
Docker is the workshop that builds the box and the crane that loads it onto the truck. You write instructions in a Dockerfile, Docker produces an image, and runs it with the Docker Engine. You can find ready-to-use images on Docker Hub, the most widely used public registry.
Kubernetes is the port. It doesn’t build boxes or open them: it decides which ship each one goes on, how many copies of the same cargo to keep around, what to do when a ship sinks, and how to direct incoming trucks to the right dock. If a box falls into the sea, it immediately loads an identical replacement so that no one even notices.
In practice, a Kubernetes cluster has a control plane that makes decisions and nodes (the machines) that do the work. Containers run inside pods, the smallest unit managed by Kubernetes: usually, a pod contains one container, but sometimes two or three that need to stay together.
A port with only three containers is just a yard with three boxes: organizing it costs more than the problem it solves. This is why many projects are perfectly fine with Docker alone.
What each one does #
| Docker | Kubernetes | |
|---|---|---|
| Scope | A single machine | Many machines together |
| Task | Building and running containers | Distributing, monitoring, and replacing them |
| Problem it solves | “Works the same way everywhere” | “Stays up and carries the load” |
| Difficulty | You can learn the essentials in an afternoon | Weeks, and you’re never truly finished |
| When to use it | In almost all projects | When scale requires it |
Kubernetes justifies itself with five functions. If you don’t need any of these, you don’t need Kubernetes:
- Automatic restarts for anything that stops working (self-healing).
- Scalability: increases and decreases the number of copies based on load.
- Traffic distribution between active copies.
- Rolling updates, which replace copies one by one without interruption, with a rollback to the previous version if something goes wrong.
- Declarative configuration: you write the desired state in a YAML file and the system works to maintain it, rather than executing commands one by one.
“Kubernetes has abandoned Docker”: what actually happened #
This news pops up every now and then, and it is usually told incorrectly.
In version 1.24, released in May 2022, Kubernetes removed dockershim, the component that allowed it to use the Docker Engine to run containers. Today, it uses lighter runtimes that comply with the CRI standard, such as containerd (which, by the way, is the same engine Docker uses internally) and CRI-O.
Images are not affected: those created with Docker follow the open OCI standard and run identically on Kubernetes. For developers, nothing has changed; you build with Docker and run on Kubernetes just as before. The change only affects those who administer clusters.
What to use, depending on where you are #
A single application on a server. Just Docker: one image, one command to run it, and the --restart unless-stopped option so it restarts automatically. Adding an orchestrator here means having a second system to maintain just to manage one thing.
Multiple connected services on one machine, such as an application, a database, and a cache. Here you need Docker Compose: a compose.yaml file describes all the services and how they communicate, and docker compose up starts them together. It covers the development environment of almost every project and many small-scale production setups.
Multiple machines, changing loads, no downtime allowed. This is where Kubernetes starts to pay for itself. The rule of thumb: if a service must stay up even when a machine breaks, and the number of copies must change automatically with traffic, you’re in the right place.
The middle ground. k3s is a lightweight Kubernetes that provides essential functions with much less complexity, suitable for a couple of machines or a Raspberry Pi. Docker Swarm, included with Docker, brings multiple machines together using commands you already know. And managed services from the big providers—Amazon EKS, Google GKE, and Azure AKS—handle the control plane for you, though you’ll still need to learn the Kubernetes model. On AWS, there is also ECS, which runs containers without Kubernetes.
Hidden costs #
Anyone who brings Kubernetes to a small project quickly discovers that the cost isn’t just technical:
- Cluster machines consume resources even without traffic, because system components are always running.
- It requires continuous expertise: internal networking, persistent volumes, credential management, version updates. Kubernetes releases three versions a year and each is supported for about fourteen months, so you can’t just install it and forget about it.
- Debugging takes longer: there are more layers between your code and the user’s request, and learning to read them takes time.
- Docker Desktop is paid for large companies: free for personal use, study, and companies with fewer than 250 employees and less than $10 million in revenue; otherwise, a subscription is required. If you need an open alternative, there are Podman, Rancher Desktop, and on Mac, OrbStack or Colima.
These are great reasons not to use it when you don’t need it, and none of them are reasons to avoid it when you do.
FAQ #
Do I need to learn Docker before Kubernetes? #
Yes, and it will save you time. Kubernetes orchestrates containers: if you don’t know what an image is, how to build one, or how to run it, you’ll end up copying configurations without understanding what they actually do.
Can Kubernetes work without Docker? #
Yes, and that is the norm: since 2022, clusters have been using containerd or CRI-O to run containers. However, Docker remains the most convenient tool for building the images that Kubernetes then executes.
What is the difference between a container and a virtual machine? #
A virtual machine contains a full operating system, weighs several gigabytes, and takes a while to boot up. A container uses the host system’s kernel, weighs much less, and starts in a second. In exchange, it is less isolated; to run Linux containers on Windows or Mac, you still need a small virtual machine, which Docker Desktop handles for you automatically.
Does Kubernetes replace Docker Compose? #
On a single machine, no, and many projects stay on Compose forever. Compose describes multiple services on one computer, making it perfect for development and small-scale deployments. Kubernetes describes those same services distributed across multiple machines, with rules to ensure fault tolerance.
Do I need it for a website or a blog? #
No, in the vast majority of cases. A static site, a blog, or an application with a few hundred visits a day will run fine on a server with Docker, or even without it. Orchestration only starts to pay off when scale and availability requirements demand it.
When should I choose Docker Swarm instead of Kubernetes? #
When you have a few machines, a small team, and want to get started quickly: Swarm is activated with docker swarm init and uses files similar to Compose. However, it is much less widely used and has a smaller ecosystem. If you plan to grow, it’s better to invest directly in Kubernetes, perhaps starting with k3s.
How much does a managed cluster cost? #
It depends on the provider and the size. The main cost is usually the machines that make up the cluster, which are always running, plus a small hourly fee for the control plane on some services. Even a minimal environment with redundancy costs more than a single server: do the math before you start.
