What is the difference between Docker and Kubernetes?

Docker builds container images and runs containers, usually on a single host. Kubernetes orchestrates containers across a cluster of machines. It handles scheduling, scaling, networking and self-healing so the desired number of healthy containers keeps running.

They mostly work together. Docker is commonly used to build OCI images and push them to a registry. Kubernetes then pulls those images and runs them at scale across nodes. The only overlapping product is Docker Swarm, which competes with Kubernetes as an orchestrator.

Not directly. Kubernetes removed dockershim in v1.24, so kubelet now talks to CRI runtimes such as containerd or CRI-O. Images built with Docker still run unchanged because they follow the OCI image format. Using Docker Engine as the node runtime now needs the separate cri-dockerd adapter.

Docker alone fits local development, CI builds, small apps and internal tools on one or a few servers. If occasional downtime during deploys is acceptable and traffic is predictable, docker run or Compose with restart policies is simpler. You avoid running a cluster you do not need.

Choose Kubernetes when you run many services across several machines and need automatic scaling, rolling updates, self-healing and service discovery. It also helps when you need high availability across nodes or zones. The team must be ready to handle its operational complexity, or use a managed service.

Compose defines multi-container apps in one YAML file and runs them on a single Docker host. Kubernetes runs workloads across many nodes and keeps reconciling them to a desired state. Compose has restart policies but no cross-node scheduling, rescheduling of failed hosts or built-in autoscaling.

With Docker you scale manually, for example docker compose up --scale web=3 on one host. Kubernetes can scale a Deployment with kubectl scale or automatically with the Horizontal Pod Autoscaler based on CPU, memory or custom metrics. Node count can also scale with Cluster Autoscaler or Karpenter.

A container is a single isolated process group from an image. A Pod is the smallest unit Kubernetes schedules and can hold one or more containers. Containers in a Pod share a network namespace and IP, and can share volumes. Kubernetes manages Pods, not raw containers.

Docker restart policies such as unless-stopped or on-failure restart a crashed container on the same host. If the host dies, nothing moves the container elsewhere. Kubernetes controllers notice missing or failed Pods and recreate them, rescheduling onto healthy nodes when a node fails.

Both orchestrate containers across a cluster. Swarm is built into Docker Engine, is simpler to set up and uses familiar Compose-style files. Kubernetes has a much larger ecosystem, richer scheduling, autoscaling and extensibility through CRDs and operators, and is the industry default, but it is more complex.