Why Kubernetes?

Docker Isn't the Problem

Kubernetes didn't replace Docker — they solve different problems. Docker answers "how do I run a container?". Kubernetes answers "how do I reliably run thousands of containers across many servers in production?".

Picture a startup with a Node.js app in a single Docker container. Everything works. Six months later the app goes from 100 users to a million, one container isn't enough, and every one of the following problems arrives at once.

The Problems with Docker Alone

1. Manual scaling

Traffic spikes and you need 50 containers instead of 5. With Docker alone, that's docker run fifty times — and fifty docker stops when traffic drops. With Kubernetes you declare "keep 50 replicas running" once, and it creates or removes them to match.

2. Container crashes

A container dies at 2 a.m. With Docker, the app is down until a human notices, runs docker ps, and restarts it. Kubernetes detects the failure and replaces the container automatically — a feature called self-healing.

3. Multiple servers

Once one server isn't enough, containers spread across five, ten, fifty machines. Which server has free memory? Which should run the next container? Kubernetes' scheduler answers that on every deployment, automatically placing workloads on the best available node.

4. Server failure

A server loses power and every container on it disappears. Kubernetes notices the node is gone and recreates its workloads on the remaining healthy servers.

5. Load balancing

Users can't be expected to know which of your four container IPs to hit. A Kubernetes Service gives the whole group one stable endpoint and distributes requests across it.

6. Zero-downtime deployments

With Docker alone, shipping v2 means stopping v1 first — users see 503 Service Unavailable during the swap. Kubernetes performs rolling updates, replacing containers one at a time so users never notice:

Old Old Old  →  New Old Old  →  New New Old  →  New New New

7. Rollback

V2 has a bug. With Docker, getting back to v1 is a manual scramble. With Kubernetes it's one command:

kubectl rollout undo deployment nginx

8. Configuration management

Dev points at localhost, production points at db-prod.company.com. Kubernetes separates configuration (ConfigMaps) and sensitive values (Secrets) from the application, so the same image runs everywhere.

9. Storage

A MySQL container crashes and its data dies with it. Kubernetes Persistent Volumes keep data outside the container lifecycle, so a replacement container reattaches to the same data.

10. Service discovery

Frontend calls backend calls database — but pod IPs change on every restart. Kubernetes gives every service a stable DNS name (backend-service, mysql-service), so components find each other by name, never by IP.

Docker vs Kubernetes

Problem → Kubernetes Object

This table maps each problem above to the Kubernetes object that solves it — a preview of everything Day 1 covers:

Where This Course Is Headed

By the end of Day 1 you'll understand — and build — every layer of this stack:

    Users
      │
      ▼
   Ingress
      │
      ▼
   Service
      │
      ▼
  Deployment
      │
      ▼
  ReplicaSet
      │
      ▼
    Pods
      │
      ▼
  Containers