What is the difference between Docker and Kubernetes?
Docker is a tool for building container images and running containers on a single machine. Kubernetes is a system for running containers across many machines: it decides where each container runs, restarts it when it fails and scales it with demand. They are not alternatives. A typical team builds images with Docker and deploys them to a Kubernetes cluster.
Docker and Kubernetes compared
| Docker | Kubernetes | |
|---|---|---|
| Main job | Build images, run containers | Schedule and manage containers across a cluster |
| Scope | One host | Many nodes, from a few to thousands |
| Unit you work with | Container | Pod (one or more containers) |
| Configuration | Dockerfile, compose.yaml |
YAML manifests such as Deployment and Service |
| Failure handling | Restart policies on the same host | Replaces Pods on healthy nodes when a node fails |
| Scaling | Manual, on one host | Manual or automatic, across nodes |
| Networking | Bridge networks on one host | Cluster-wide Pod network, Services and DNS |
What Docker does
Docker covers the developer side of containers. docker build turns a Dockerfile into an image, a layered file system with your application, its libraries and metadata about how to start it. You push that image to a registry and run it anywhere a compatible runtime exists. Docker Engine runs containers on the local machine, and Docker Compose starts several related containers, such as an app and its database, from one compose.yaml file.
Everything Docker Engine runs stays on the host it runs on. If that machine goes down, its containers go down with it, and nothing moves them elsewhere.
What Kubernetes does
Kubernetes works one level up. You declare what should run, for example five replicas of an image with a given amount of CPU and memory, and the control plane picks nodes with free capacity, starts the containers there and keeps the count at five. It adds the parts a single host cannot provide: Services with stable addresses, rolling updates, health-based restarts, autoscaling and placement rules across zones.
Kubernetes does not build images. It pulls images that something else built, which is often Docker on a laptop or in a CI pipeline.
Does Kubernetes still use Docker?
Not as its runtime. Kubernetes talks to container runtimes through the Container Runtime Interface (CRI). Docker Engine predates CRI, so Kubernetes carried an adapter for it called dockershim. That adapter was removed in Kubernetes 1.24, and the container runtimes page now covers containerd, CRI-O, Docker Engine and Mirantis Container Runtime. Clusters that still need Docker Engine on their nodes use cri-dockerd, an adapter maintained by Mirantis and Docker.
The removal did not affect images. The Kubernetes project’s FAQ is explicit: “the images produced from docker build will work with all CRI implementations.” That works because Docker images follow the Open Container Initiative (OCI) image specification, which containerd and CRI-O also implement. Docker on a developer machine is unaffected too.
| Runtime | Relationship to Docker |
|---|---|
| containerd | A CNCF graduated runtime. Docker Engine runs on top of it and is listed among its adopters. |
| CRI-O | An implementation of the Kubernetes CRI that runs OCI-compliant containers. |
Docker Engine with cri-dockerd |
Docker Engine behind an external CRI adapter. |
Docker Compose vs Kubernetes manifests
A Compose file describes a multi-container application on one host in a few lines. The same application on Kubernetes needs several objects: a Deployment per service, a Service for each network endpoint, a PersistentVolumeClaim for storage and often a ConfigMap and a Secret. The extra verbosity buys scheduling across nodes, self-healing and rolling updates.
Teams moving from Compose can start from a converter such as Kompose, which translates a Compose file into Kubernetes manifests, and then adjust resource requests, health checks and storage by hand.
Where Docker Swarm fits
Docker Swarm is Docker’s own orchestrator, built into Docker Engine. It also schedules containers across several hosts and is simpler to set up, but its ecosystem and feature set are smaller than Kubernetes’. For a detailed comparison, see Kubernetes vs. Docker Swarm.
Which one do you need?
- Docker alone fits local development, CI builds and small applications on a single server.
- Kubernetes fits applications that need several machines, high availability, rolling deployments or autoscaling.
- Both is the common case: Docker, or another OCI-compatible builder, produces the images, and Kubernetes runs them.
If the real question is how a container differs from a VM, see containers vs virtual machines.
Docker images on Cloudfleet
Images built with Docker run unchanged on Cloudfleet Kubernetes Engine (CFKE). Cloudfleet Container Registry is an OCI-compliant registry that accepts pushes from the standard Docker CLI, and CFKE clusters pull from it without image pull secrets. See the registry overview.