Docker vs Kubernetes: What's the Difference and Which Do You Need?

Docker and Kubernetes are the two most talked-about tools in modern infrastructure — but they're often misunderstood as competing alternatives. They're not. Docker creates containers; Kubernetes orchestrates them. Most production systems use both. This guide explains exactly what each tool does, how they differ, and when you need each one.

At a glance

What is Docker?

Docker is a containerisation platform. It lets you package an application and all its dependencies (runtime, libraries, config) into a single portable unit called a container. Containers are isolated processes that share the host OS kernel — lighter than VMs, yet consistent across environments.

Core Docker concepts

Dockerfile  →  build  →  Image  →  run  →  Container
                                ↑
                          Docker Hub / Registry

Dockerfile — instructions to build an image:

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Build and run:

docker build -t myapp:1.0 .
docker run -d -p 3000:3000 --name myapp myapp:1.0
docker logs myapp
docker exec -it myapp sh

Docker Compose — multi-container on one host

For local development and simple single-server deployments, Docker Compose defines a multi-container application in one YAML file:

# docker-compose.yml
services:
  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: pass
      POSTGRES_USER: user
      POSTGRES_DB: mydb
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user"]
      interval: 5s
      retries: 5
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

docker compose up -d       # start
docker compose ps          # status
docker compose logs -f api # logs
docker compose down        # stop

Docker Compose is great for local dev and small single-server deployments. When you need multi-host, auto-scaling, and self-healing — that's when Kubernetes enters.

What is Kubernetes?

Kubernetes (K8s) is a container orchestration platform. It manages the lifecycle of containers across a cluster of machines — scheduling, scaling, healing, load balancing, rolling updates, and secret management.

Core Kubernetes concepts

Kubernetes architecture

Control Plane                  Worker Nodes
┌────────────────────┐         ┌──────────────────────┐
│  API Server        │◄───────►│  kubelet             │
│  Scheduler         │         │  kube-proxy          │
│  Controller Mgr    │         │  Container Runtime   │
│  etcd (state)      │         │    (containerd)      │
└────────────────────┘         │  Pods → Containers   │
                               └──────────────────────┘

Basic Kubernetes manifest

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 15
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: myapp-secrets
                  key: database-url
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  namespace: production
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-svc
                port:
                  number: 80

kubectl apply -f deployment.yaml
kubectl get pods -n production
kubectl rollout status deployment/myapp -n production
kubectl scale deployment myapp --replicas=5 -n production

Docker and Kubernetes work together

A common misconception: "Docker vs Kubernetes" implies you choose one. In practice, you use both:

Developer writes Dockerfile
        ↓
docker build → image → pushed to registry (Docker Hub / ECR / GCR)
        ↓
Kubernetes pulls the image from the registry
        ↓
Kubernetes runs it inside containers on worker nodes
        ↓
kubelet uses a container runtime (containerd / CRI-O) to run the containers

Note: Kubernetes deprecated the Docker daemon (dockershim) in 2020. Kubernetes now uses containerd or CRI-O directly. The Docker image format (OCI) is still supported — images you build with docker build run perfectly on Kubernetes.

Docker Compose vs Kubernetes

This is the more practical comparison for most developers deciding what to use:

Docker Swarm vs Kubernetes

Docker Swarm was Docker's built-in orchestrator (before K8s won the container wars). You may encounter it on older systems:

Docker Swarm is largely considered legacy. New projects should use Kubernetes or a managed serverless platform (AWS Fargate, Cloud Run).

Docker vs Kubernetes: feature deep-dive

Scaling

Docker (manual):

# Run 3 instances manually — no coordination
docker run -d -p 3001:3000 myapp:1.0
docker run -d -p 3002:3000 myapp:1.0
docker run -d -p 3003:3000 myapp:1.0
# You manage load balancing yourself

Kubernetes (automatic):

# HorizontalPodAutoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

K8s automatically adds/removes pods as CPU load changes.

Rolling updates

Docker Compose:

# All containers restart at once — downtime
docker compose up -d --force-recreate

Kubernetes (zero-downtime):

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # allow 1 extra pod during update
      maxUnavailable: 0  # never kill a pod before new one is ready

kubectl set image deployment/myapp myapp=myapp:2.0
kubectl rollout status deployment/myapp   # watch progress
kubectl rollout undo deployment/myapp     # instant rollback

Self-healing

Docker: if a container crashes, it respects restart: always — but if it's unhealthy (returns 500 but is still running), Docker does nothing.

Kubernetes:

livenessProbe:           # kill + restart pod if this fails
  httpGet:
    path: /health
    port: 3000
  failureThreshold: 3
  periodSeconds: 10

readinessProbe:          # remove pod from load balancer if this fails
  httpGet:
    path: /ready
    port: 3000
  failureThreshold: 2
  periodSeconds: 5

K8s continuously monitors and replaces unhealthy pods. If a node dies, K8s reschedules all its pods onto healthy nodes.

Networking

Storage

Docker:

volumes:
  - ./data:/app/data              # bind mount
  - pgdata:/var/lib/postgresql    # named volume

Kubernetes:

# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myapp-pvc
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp3   # EBS on AWS

# Mount in pod
volumes:
  - name: data
    persistentVolumeClaim:
      claimName: myapp-pvc

K8s PVCs are decoupled from pods — storage survives pod restarts/rescheduling. StorageClasses enable dynamic provisioning (AWS EBS, GCP Persistent Disk, Azure Disk, etc.).

When to use Docker without Kubernetes

Docker alone (or Docker Compose) is the right choice when:

When to add Kubernetes

Add Kubernetes when you have:

Full comparison

Managed Kubernetes options

You don't have to manage the K8s control plane yourself:

Common mistakes

Docker vs Kubernetes vs serverless

FAQ

Q: Is Docker required to use Kubernetes? No. Kubernetes uses any OCI-compatible container runtime (containerd, CRI-O). You still use Docker to build images, but the Docker daemon isn't running on K8s nodes in modern clusters.

Q: Can I replace Kubernetes with Docker Compose in production? For simple single-server apps, yes — Docker Compose is a valid production choice. But Compose can't span multiple machines, auto-heal failing containers (beyond restart policy), or auto-scale. For high-availability production systems, K8s (or a managed alternative like ECS/Fargate) is the right choice.

Q: When does Kubernetes stop being worth it? For apps that receive predictable, moderate traffic and run on a single server, K8s overhead (complexity, cost, learning curve) often outweighs benefits. Use it when you genuinely need multi-node HA, auto-scaling, or are running many microservices.

Q: What is Helm and do I need it? Helm is the "package manager" for Kubernetes — it templates and versions YAML manifests. For anything beyond a personal project, Helm (or Kustomize) is essential for managing configuration across environments.

Q: Docker Swarm vs Kubernetes — should I ever use Swarm? Only if you have existing Swarm infrastructure and can't migrate. All new projects should use Kubernetes or a managed container service. Docker Swarm is effectively in maintenance mode.

Q: What's the minimal Kubernetes setup for a small team? Start with a managed cluster (GKE Autopilot, DOKS, or AKS with free control plane). Use namespaces for dev/staging/prod. Add ArgoCD for GitOps. This keeps ops overhead low while giving you production-grade orchestration.