How does Kubernetes decide where to run a pod, and what happens when that pod crashes?

The scheduler assigns pods to nodes; kubelets manage their containers; ReplicaSets replace missing pods. They explain placement, crashes, and recovery.

For this example, the web Deployment wants one replica. It manages a ReplicaSet, which creates the pod to match that desired count. The pod is pending, so it exists, but it hasn't been assigned to a node; replica count and node selection are separate jobs.

The scheduler doesn’t simply pick the emptiest-looking machine. It checks Node A and Node B against the pod’s resource requests and placement constraints, then ranks the nodes that remain feasible. In this example, assume Node A is selected. The scheduler binds the pending pod there, but another cluster could choose differently.

Binding records the node assignment through the API. Kubelet A watches the API, sees that the web pod is assigned to Node A, and starts its container. It then reports pod status through the API. The scheduler chooses placement; the kubelet on the chosen node acts on it.

Kubelet A checks two different kinds of health. A failed liveness probe tells it to restart the Web container, while a failed readiness probe leaves the container running but removes the pod from Service traffic. One probe repairs a stuck process; the other protects requests from an unready one.

The kubelet restarts a failed container inside the existing web pod; it doesn't create a new pod. Whether it restarts depends on the pod's restart policy, and repeated failures can trigger increasing backoff. Controllers replace missing pods, then the scheduler assigns those pending replacements to nodes.

Let's think this through. The web container fails its liveness probe, but Node A and its pod still exist. What normally happens next? A: The scheduler chooses a new node. B: Node A's kubelet restarts the container. C: The ReplicaSet immediately creates another pod. Choose an answer, or just think it through. I'll explain in a moment.

The answer is B: Node A's kubelet restarts the container. A liveness failure tells the kubelet to restart the container within the existing pod. The scheduler places pending pods; it does not handle each container restart. A replacement pod is needed when the pod itself is missing.

Deleting the web pod is different: the ReplicaSet falls below its desired count, so it must create a replacement.

When the web pod is deleted, the ReplicaSet reconciles the Deployment’s desired count by creating a distinct pending pod. The Scheduler watches for that pod and binds it to a node. Only after assignment can that node’s Kubelet see the pod and start its container. This is fresh scheduling, not a restart.

When Node A becomes unavailable, Kubernetes has to detect the failure before eviction and replacement can proceed. That takes time; recovery isn’t instantaneous. The ReplicaSet creates a new pod, and the Scheduler can bind it to feasible Node B. The application recovers only after the replacement pod starts.

Scheduling assigns pending pods to feasible nodes; kubelets manage containers on assigned nodes; controllers maintain desired pod counts. A failed container can restart inside its existing pod, while a deleted pod must be recreated and scheduled as a new pod.