Why use Kubernetes if Docker already runs containers?

Who keeps the web app running across servers? Docker runs each container; Kubernetes coordinates the Pods as one deployment, rather than leaving them as unrelated containers.

Server A runs Web A, and Server B runs Web B. Docker starts both containers, but it doesn't track whether this two-server app still has two healthy instances.

You declare two replicas, and the Kubernetes controller keeps comparing that desired count with the Pods that are actually running. Here, Pod A and Pod B sit on separate nodes by assumption; Kubernetes doesn’t guarantee that placement automatically.

When Node A fails, only Pod B remains, leaving one working replica. The Controller schedules a New Pod on available Node C, restoring the declared count of two.

Let's think this through. Node A fails, leaving one working web app Pod. What does Kubernetes try to do? A: Start a replacement Pod on an available node. B: Wait for someone to restart Node A. C: Send all requests to the failed Pod. Choose an answer, or just think it through. I'll explain in a moment.

The answer is A: Start a replacement Pod on an available node. The app's desired count is two replicas, but only one remains. Kubernetes tries to schedule a replacement on a node with capacity; it does not need the failed server to recover first.

Change the desired count to three, and Kubernetes’ Controller works to maintain three Pods, placing Pod C on Node C when capacity allows. You don’t manually start containers server by server; cluster capacity still determines whether that target can be met.

A client requests a page through the external load balancer, which forwards it to the Kubernetes Service. The Service routes to a ready Pod, like Pod B, so clients don’t need to track changing Pod addresses.

Docker handles individual containers; Kubernetes coordinates a declared application state across servers. That coordination supports recovery, scaling, and stable routing to ready Pods.