Topic 8.3
Where Docker Ends and Kubernetes Begins
In one line
The single most common Docker interview question: 'so what does Kubernetes actually add?' — and the honest answer is a clean, specific list, not a vague 'it's for scale.'
Think of it like this
Docker is like knowing how to drive a single truck extremely well — loading it, maintaining it, driving it safely. Kubernetes is like running an entire logistics company with hundreds of trucks — deciding which truck goes where, replacing a truck that breaks down automatically, and rerouting deliveries around a closed highway, all without a human manually deciding each of those things in real time.
Key ideas
- 01
Docker (and Docker Compose) is fundamentally a SINGLE-HOST tool — great at building, running, and networking containers on ONE machine (or, with Compose, orchestrating several containers together on that one machine). It has no native concept of 'if this machine dies, move my containers to a different machine.'
- 02
Kubernetes is a MULTI-HOST ORCHESTRATOR — it manages containers across a CLUSTER of many machines (nodes), and its core value additions over plain Docker/Compose are things Docker was never designed to do at all: automatic rescheduling of containers when a node fails, horizontal auto-scaling based on load, rolling deployments with automatic rollback on failure, and service discovery/load balancing across a fleet rather than just between containers on one host.
- 03
Kubernetes doesn't replace Docker's IMAGE format or Dockerfile — a Kubernetes Pod still runs a container built from a perfectly ordinary Docker image, built with a perfectly ordinary Dockerfile, using everything from Phases 1-7 of this course. Kubernetes operates ONE LEVEL UP: deciding WHICH machine runs that container, how many copies to run, and what to do when something goes wrong.
- 04
The practical decision point: if your app runs happily on one machine (or a small, manually-managed set of machines) and doesn't need automatic failover/scaling, Docker + Compose is often genuinely sufficient and meaningfully SIMPLER to operate. Reach for Kubernetes when you need multi-machine scale, automatic healing, or team-scale multi-service deployment coordination that outgrows what one person can manage by hand.
- 05
Interview-ready one-liner: 'Docker packages and runs a container on one machine; Kubernetes decides which machines run which containers across a whole cluster, and automatically keeps that desired state true even when things fail.'
In your stack
- →
A concrete Java-team trajectory many companies actually follow: start with
docker compose upfor local development AND even early production (a handful of Spring Boot services on one or two servers) — migrate to Kubernetes specifically once the number of services, the need for zero-downtime rolling deploys, or genuine multi-machine scaling requirements outgrow what Compose can reasonably coordinate by hand.
Code & diagrams
The exact layer boundary this topic is entirely about.
Explain it without notes
A candidate says 'Kubernetes is just a more complicated version of Docker.' Give the precise correction.
Why can't Docker Compose alone provide the 'automatically move my container to a healthy machine if this one dies' guarantee, no matter how you configure it?
Practice
Write, from memory, a 2-3 sentence answer to 'what's the difference between Docker and Kubernetes' that you'd be comfortable giving in a real interview.
List 3 concrete things Kubernetes provides that plain Docker Compose genuinely cannot, no matter how it's configured.
Trade-offs
- ↔
Kubernetes' power comes with genuinely significant operational complexity (its own steep learning curve, more moving pieces to secure and monitor) — adopting it before you actually need multi-machine orchestration is a common, avoidable source of unnecessary complexity; Docker Compose (or even a single well-run Docker host) remaining sufficient for a smaller or simpler deployment is a legitimate, common, and often WISER choice, not a sign of falling behind.
Done when you can
I can give a precise, correct one-paragraph explanation of Docker vs Kubernetes.
I can name at least 3 specific capabilities Kubernetes adds beyond what Docker/Compose provide.
I understand Kubernetes runs ordinary Docker images — it doesn't replace the image format or Dockerfiles.