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

The scheduler selects a node; its kubelet runs the pod. Liveness can restart containers; controllers replace missing pods.

For this example, the web Deployment wants one replica. It manages a ReplicaSet, which creates the pod needed to maintain that count. The pod is pending because it doesn’t have a node yet; creating a pod and choosing where it runs are separate jobs.

The scheduler compares the pending pod’s resource request and placement constraints with available nodes. It filters out nodes that can’t meet them, then scores the eligible ones. Here, Node A is the illustrative choice; scoring ranks options, but doesn’t guarantee a particular placement.

Binding and starting are separate actions. The Scheduler asks the API to bind the web pod to Node A, and the API records that assignment. Kubelet A then observes the pod and asks the Runtime to start its container. The Runtime reports the container’s status back to the kubelet.

Kubelet A runs both probes against the Web container, but they have different jobs. If Readiness fails, the pod stops receiving traffic through matching Service endpoints. If Liveness fails, the kubelet restarts the container in the same pod; it doesn’t schedule a replacement.

Placement is separate from container recovery: Kubelet A restarts the crashed container inside the existing Web pod on Node A, so the ReplicaSet doesn’t need to create a replacement.

Let's think this through. The web container crashes, but Node A remains healthy. What normally happens first? A: The kubelet restarts the container in the same pod. B: The scheduler moves the existing pod to Node B. C: The ReplicaSet immediately creates a second pod. Choose an answer, or just think it through. I'll explain in a moment.

The answer is A: The kubelet restarts the container in the same pod. With the assumed restart policy, Node A's kubelet restarts the crashed container inside the existing pod. The scheduler does not move an existing pod, and a container crash alone does not mean the ReplicaSet must create a replacement.

Deletion is different from a container crash: the original pod is gone, so the ReplicaSet sees fewer matching pods than the Deployment’s desired one and creates a new pod. The scheduler then chooses an eligible node again; here, the new pod is assigned to Node B. It isn’t a restart of the original pod.

When Node A becomes unreachable, the Controller has to detect the failure and remove the Web pod before the ReplicaSet can create a New pod. The Scheduler can then bind it to Node B. This takes time, and Kubernetes may not know whether the old container has actually stopped.

Scheduler places a pending pod on an eligible node. Kubelet restarts a crashed or liveness-failing container, usually in the same pod. Readiness changes Service traffic eligibility; ReplicaSet creates a pod when a replica is missing.

Placement, container recovery, and replica reconciliation are separate loops. A container restart stays in the same pod; replacement creates a new pod, which returns to scheduling for a fresh placement decision.