Running one container is easy. Running hundreds of containers reliably, across many machines, is a full-time job for software — that job is what Kubernetes does.
The one-sentence version: you tell Kubernetes what you want running ("5 copies of this container, always"), and it continuously works to make that true — restarting crashed containers, moving them off failed machines, and scaling up or down — without a human babysitting each one.
A single Docker command can start one container on one machine easily enough. But a real production system might run dozens of different services, each needing multiple copies for reliability and to handle load, spread across many machines, with traffic routed correctly to healthy instances, updates rolled out without downtime, and automatic recovery when something fails. Doing all of that by hand, or with custom scripts, doesn't scale — Kubernetes is the standardized tool that handles it.
Kubernetes usually sits at the end of a CI/CD pipeline — after code is built, tested, and packaged into a container image, Kubernetes is what actually runs and manages that image in production.
Kubernetes is fundamentally declarative: instead of issuing commands like "start this container," you write a configuration file describing the desired end state ("this deployment should have 5 replicas of this image, exposing port 8080"), and Kubernetes' control loop continuously compares that desired state against reality and takes whatever action is needed to close the gap. This is why Kubernetes can recover automatically from failures — it isn't running a one-time script, it's constantly re-checking and re-converging.
A Deployment can be scaled up or down (manually, or automatically via a Horizontal Pod Autoscaler reacting to CPU/memory/custom metrics), and a Service in front of it automatically load-balances traffic across all healthy Pods, so scaling doesn't require any change to how other parts of the system find and talk to it.
Kubernetes brings meaningful operational overhead: someone has to run, secure, and maintain the cluster itself (or pay a managed service to do it), and its configuration surface (YAML manifests, RBAC, networking policies) has a real learning curve. For a handful of services or a small team, simpler options — a single-server Docker Compose setup, or a fully-managed container platform that hides the orchestration layer — often deliver the needed reliability with far less operational burden.
Kubernetes automates running, scaling, and healing a fleet of containers across a cluster of machines. You describe the desired state ("I want 5 copies of this container running"), and Kubernetes continuously works to make reality match that description — restarting failed containers, moving them to healthy machines, and scaling up or down as needed, all without a human manually managing each container.
A Pod is the smallest deployable unit — one or more tightly coupled containers that run together. A Deployment manages a set of identical Pods, handling scaling and rolling updates (replacing old Pods with new ones without downtime). A Service gives a stable network address to a group of Pods, so other parts of the system can reach them reliably even as individual Pods are replaced.
Usually not. Kubernetes adds real operational complexity — it's worth it once you're running enough services, need automated scaling/healing across multiple machines, or need to standardize deployment across many teams. A small project with a handful of containers is often better served by simpler tools (a single Docker Compose file, or a managed container platform) until scale or complexity actually demands Kubernetes.
Docker builds and runs individual containers on one machine. Kubernetes orchestrates many containers across many machines — deciding which machine runs which container, restarting failed ones, load-balancing traffic between them, and rolling out updates. They're complementary, not competing: Kubernetes commonly uses container images built by Docker (or another container build tool) as the unit it schedules and runs.
If a container crashes, becomes unresponsive, or the machine it's running on fails, Kubernetes automatically detects this (via health checks) and takes corrective action — restarting the container or rescheduling it onto a healthy machine — to bring the actual running state back in line with the declared desired state, without a human needing to intervene.