Pregunta de Kubernetes #019e3a4f

When a node fails in Kubernetes, any regular pods running on that node are considered lost. The ReplicationController, ReplicaSet, or Deployment that manages the pod detects the discrepancy between the desired and actual number of replicas. It then schedules a new pod on a healthy node. However, the new pod is not identical to the original; it receives a new UID (unique identifier) and typically a new IP address. The original pod's UID is not reused.

How it Works

• Kubernetes controllers continuously monitor the cluster state via the API server.
• When a node fails, the kubelet on that node stops reporting, and the node's status is updated to NotReady or Unknown after a timeout (default 40 seconds).
• The controller manager then detects that the number of running pods for a given ReplicaSet is below the desired count.
• It creates a new pod on a different node, assigning a new UID. The old pod's UID is retained in etcd until the pod object is deleted (which happens after a node failure grace period, typically 5 minutes).

Why the Correct Answer is Right

• The statement "A new, near-identical pod but with different UID is scheduled to another node" is accurate because Kubernetes ensures self-healing by creating a replacement pod with a new UID. The pod is "near-identical" because it uses the same container image, environment variables, and volume mounts, but its identity (UID) and network identity (IP) change.

Why the Incorrect Answers are Wrong

• "A new pod with the same UID is scheduled to another node after a while" is incorrect because Kubernetes never reuses a pod UID. Each pod gets a unique UID generated by the API server.
• "By default, a pod can only be scheduled to the same node when the node fails" is false. A failed node is unavailable, so the pod cannot be scheduled there. Kubernetes schedules the replacement on a different node.
• "A new pod is scheduled on a different node only if it is configured explicitly" is incorrect. This behavior is automatic for pods managed by controllers (Deployments, ReplicaSets, StatefulSets). Only static pods or pods created directly without a controller would not be automatically rescheduled.