What is the difference between Docker and Kubernetes?

Quick answer: Docker is a container runtime and packaging tool — it builds an image from a Dockerfile and runs that image as a container on a single machine. Kubernetes is a container orchestrator — it takes containers (built with Docker or any other OCI-compatible tool) and schedules, scales, heals, and network-connects them across a cluster of machines. They solve different problems and are usually used together, not as alternatives.

What Docker actually does

Docker packages an application and everything it needs to run — code, runtime, libraries, config — into a single image, and runs that image as an isolated container. docker build produces the image, docker run starts it. On its own, Docker has no concept of "run three copies of this across five servers and restart it if it crashes on any of them" — that is one container, on one host, that you manage by hand.

What Kubernetes actually does

Kubernetes takes a declarative description of what you want running (a Deployment manifest saying "3 replicas of this image") and continuously reconciles the cluster to match it: scheduling pods onto nodes with capacity, restarting containers that crash, replacing nodes that fail, load-balancing traffic across replicas via Services, and rolling out new versions without downtime. Kubernetes does not build container images itself — it pulls images that were already built (commonly with Docker, but buildah, kaniko, or podman work just as well since Kubernetes only cares that the image is OCI-compliant).

Complementary, not competing

The comparison that trips people up is that Docker also ships its own orchestrator, Docker Swarm — so "Docker vs Kubernetes" sometimes really means "Docker Swarm vs Kubernetes," which is a genuine orchestrator-vs-orchestrator choice (see how containers streamline deployments beyond just Kubernetes for where Swarm and other lighter-weight options fit). But "Docker vs Kubernetes" in the plain sense is comparing a packaging tool to an orchestrator — Kubernetes runs containers, and those containers still get built somehow, often still with Docker.

When you need which

• Just Docker — a single service on a single VM, a local dev environment, a small side project. No orchestration overhead, no cluster to maintain.
• Docker plus a simpler orchestrator — a handful of services that need restarts and basic scaling but not the full complexity of Kubernetes; Docker Swarm or a managed container service (ECS, Container Instances) covers this.
• Docker plus Kubernetes — multiple services, multiple environments, a need for self-healing, autoscaling, and rolling deployments across a cluster of machines. This is where most production platform teams end up, and it is also where questions like how do you achieve zero-downtime deployments in Kubernetes and how do you fix CrashLoopBackOff start to matter.

If you are not sure which combination fits your setup, that is exactly what an office-hours call is for.