Docker vs Kubernetes: One Request Through Both

What it is. Docker turns a Dockerfile into an image (a read-only, layered filesystem with your app and its runtime) and runs that image as a container (an isolated process that shares the host kernel but has its own filesystem, network namespace, and cgroup limits). You type into the Docker client (docker build, docker run); the client sends the command to the Docker daemon, which does the real work of building layers, pulling from a registry, and starting the process.

How it runs. docker build executes each Dockerfile instruction as a cached layer, so a later code change does not reinstall dependencies. docker run starts the process, maps a host port to the container port, and attaches namespaces for isolation. The container is just a process: when it exits, it stops. Nothing restarts it, reschedules it, or moves it to another machine — that is exactly the gap Kubernetes fills.

Boundary. Docker owns packaging and single-host execution. It does not own multi-node placement, self-healing, or a stable network identity across restarts. On one reliable VM with Compose, that is often all you need.

What it is. Kubernetes runs the same image across a cluster of machines and continuously drives the system toward a state you declare in YAML. You do not run containers directly; you tell the API server "I want 3 replicas of checkout-api:1.0.0," and controllers make reality match.

The mechanism that matters — reconciliation. This is the one idea that explains almost everything Kubernetes does. Your desired state lives in etcd. A controller watches for any difference between desired and actual state and acts to close the gap. Declare 3 replicas and only 2 are running? The Deployment/ReplicaSet controller creates one more. The scheduler picks a node with room; that node's kubelet pulls the image and starts the Pod; the container runs on containerd. Kill a Pod and the same loop notices and replaces it. You are not scripting steps — you are declaring an end state and a loop keeps enforcing it.

Boundary. Kubernetes owns desired-state orchestration: placement, self-healing, stable service identity, and coordinated rollouts. It does not replace Docker's image format (it runs the same OCI images) and it does not make an app correct — a bad image crash-loops faster and more visibly, not less.

Knowing Pods run somewhere is not enough — you need to know why curl http://checkout-api/health lands on a healthy instance and never on a crashing one. Pods are mortal and their IPs change; a Service exists precisely to hide that churn behind one stable name and virtual IP (ClusterIP).

Trace one request. In-cluster DNS resolves checkout-api to the Service's ClusterIP. On each node, kube-proxy has programmed iptables/IPVS rules that rewrite that virtual IP to the real IP of one backing Pod. The set of eligible Pods is the Endpoints (EndpointSlice) list — and this is the key mechanism: a Pod appears in that list only while it passes its readinessProbe. A Pod that is still booting, or is failing /health, is removed from the list, so kube-proxy never forwards traffic to it.

Why this is the payoff of the whole model. Self-healing and rolling updates only look smooth because readiness gates the Endpoints list. During a rollout, a new Pod receives traffic after it passes readiness, and an old Pod is removed before it is killed. Get the probe wrong — point it at a path that returns 200 before dependencies are ready — and Kubernetes will happily route real users to a Pod that cannot serve them.

The most common first production incident is not exotic: a Pod stuck in CrashLoopBackOff. This section is the one every reader should be able to run.

Trigger → symptom → root mechanism. You ship checkout-api:1.1.0, but it reads DATABASE_URL from an env var that is missing in the manifest. The process throws on startup and exits non-zero. Kubernetes' job is to keep the declared replica alive, so the kubelet restarts it — then applies an exponential backoff (roughly 10s, 20s, 40s, capped) to avoid hammering a doomed container. The symptom you see is STATUS: CrashLoopBackOff with a climbing RESTARTS count. Nothing is "broken" in Kubernetes; the control loop is doing exactly what you told it to, around an app that cannot start.

Recovery. Read the events, then the logs, then roll back — in that order. kubectl describe pod shows the reason (Error, OOMKilled, ImagePullBackOff are different root causes with different fixes). kubectl logs --previous shows the crashed process's own output. Because you deployed declaratively, recovery is one command: kubectl rollout undo returns to the last healthy ReplicaSet while you fix the manifest. Contrast the sibling failure ImagePullBackOff — that is a bad tag or registry auth, so no amount of restarting helps; you fix the image reference, not the app.

Moving from Docker to Kubernetes does not just add machines — it moves where security and scaling decisions live, and skipping that shift is how clusters become liabilities.

Security boundary. On one Docker host, isolation is namespaces plus whatever the host firewall allows. In a cluster, identity and blast radius are explicit objects: RBAC decides which humans and ServiceAccounts can touch which resources; Secrets hold DATABASE_URL and are mounted into Pods rather than baked into the image; NetworkPolicies decide which Pods may talk to which; and a securityContext (runAsNonRoot, dropped Linux capabilities, read-only root filesystem) limits what a compromised container can do. The same USER node instinct from the Dockerfile now has a cluster-level counterpart — and forgetting it means a single exploited Pod can reach far more than one host.

Scaling boundary. Docker scales by you running more containers. Kubernetes can scale on measured conditions: a HorizontalPodAutoscaler adds replicas when a signal (CPU, memory, or a custom metric like requests-per-second) crosses a target, and the Cluster Autoscaler adds nodes when Pods cannot be scheduled. Autoscaling only works if you set resource requests/limits honestly — requests drive scheduling and HPA math; limits cap a noisy neighbor. Wrong requests give you either constant pending Pods or a cluster that scales on noise. Scaling is a workload property (does load actually vary? is the app horizontally scalable?), not a default you turn on.

Choose from the operational requirement backward. Use Docker (with Compose) when one host can meet your availability and scale needs: local development, CI image builds, internal tools, and small single-server deployments. You keep the entire mental model in your head, and there is no control plane to operate.

Add an orchestrator when you can name the capability you are missing — multi-node failover, coordinated zero-downtime rollouts, autoscaling on real signals, or policy-driven placement — and you can staff its operation. Notice the trap: service count is a weak trigger. One regulated payment service may justify a cluster; twenty stateless internal workers may run happily on a PaaS. Reach for the reason, not the number.

Prefer managed before self-managed. Managed container platforms — Cloud Run, ECS/Fargate — preserve the Docker workflow (build image → push → deploy) with little or no control-plane work, and managed Kubernetes (EKS/GKE/AKS) removes the hardest operational parts while keeping the full API. Self-managing a cluster is a deliberate choice you make when portability or specific control genuinely requires it — not a rite of passage.