1.3.3 Kubernetes Contrast

The Kubernetes contrast clarifies the relationship between Docker and Kubernetes: Docker (or a compatible container runtime) is responsible for building and running individual containers, while Kubernetes is responsible for deciding where containers run across a cluster of machines, keeping them running, and managing how they are networked and scaled — the two operate at different layers rather than competing directly.

Docker's Layer: Building and Running One Container

Docker defines how an individual container is built and what happens when it runs on a single host: its filesystem, its startup command, its resource limits.

docker build -t myapp:1.0 .
docker run -d -p 8080:8080 myapp:1.0

This is sufficient for running an application on one machine, but says nothing about what happens if that machine fails, or how to run many replicas across many machines.

Kubernetes' Layer: Managing Many Containers Across Many Machines

Kubernetes takes a container image — typically the same kind of image Docker builds — and schedules it onto one of many available nodes in a cluster, restarts it if it fails, and can run many replicas behind a stable network address.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 5
  template:
    spec:
      containers:
        - name: myapp
          image: registry.example.com/myapp:1.0

kubectl apply -f deployment.yaml

Why the Comparison Is Sometimes Confusing

Because Docker also has its own orchestration feature (Docker Swarm), and because Docker was for a long time the default container runtime Kubernetes used internally, the two names became associated in a way that suggested they were alternatives. In practice, Kubernetes today typically uses containerd (the same runtime Docker itself is built on) directly, and the image format both systems consume is the same standardized format regardless of which orchestrator or runtime is involved.

crictl images

What Stays the Same Regardless of Orchestrator

The Dockerfile used to build an application's image, and the resulting image itself, do not change based on whether that image is eventually run with plain docker run, Docker Swarm, or Kubernetes — the packaging step is shared, only the orchestration layer above it differs.

Choosing Based on Scale and Need

A single application on a single server has little need for an orchestrator at all; Docker alone is sufficient. As the number of services, instances, and machines grows, an orchestrator like Kubernetes becomes valuable specifically for the scheduling, scaling, and resilience concerns that plain Docker does not address on its own.