You create a Deployment with 2 replicas in a Google Kubernetes Engine cluster that has a single preemptible node pool. After a few minutes, you use kubectl to examine the status of your Pod and observe that one of them is still in Pending status:
What is the most likely cause?
In a Google Kubernetes Engine cluster with a preemptible node pool, preemption can cause nodes to be terminated unexpectedly. This may lead to pods being marked as pending while they are being rescheduled onto new nodes. Given the scenario where one pod is running and the other is pending, it is most likely that the pending pod was originally scheduled on a node that has been preempted. This would result in it being in the pending state while the cluster reschedules it. Therefore, the most likely cause is that the pending pod was originally scheduled on a preempted node, and it is currently being rescheduled.
Correct Answer is (B): Reasons for a Pod Status Pending: Troubleshooting Reason #1: Not enough CPU Troubleshooting Reason #2: Not enough memory Troubleshooting Reason #3: Not enough CPU and memory https://managedkube.com/kubernetes/k8sbot/troubleshooting/pending/pod/2019/02/22/pending-pod.html
I agree with you. The correct answer is B
D gives you the reason why the resource could not be available a it was preempted
If it was preempted, then it has to be restarted right? then it will show its failing not pending, check the articles mentioned by ESP_SAP
No, it will show as pending initially while realocating
Its in a deployment, the pod will be recreated. There is insufficient resources in the node, not because its preemptible but because there is no memory/cpu......
The real crux of this question is the mention about "Pre-emptible Node pool". That need to take into consider while determining the answer. If we choose B, then the importance of "Pre-emptible node pool" is not there. Whether the node pool is pre-emptible or not, resource scarcity can lead to pending pods. When we consider the mention of "Pre-emptible Node Poll" , then the answer is obviously D. if a pre-meptible Node get pre-empted there will be a delay in cluster to sync it. Answer is D.
This is to throw you off, when there is insufficient resources for a Pod to stand up, then the status will equal pending : https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/#:~:text=If%20a%20Pod%20is%20stuck,be%20scheduled%20onto%20a%20node.&text=You%20don't%20have%20enough,new%20nodes%20to%20your%20cluster.
Questions says "Single Node" at that case the second pod can't be in running state.
It says a single node pool, not a single node. Meaning there can be multiple nodes, right?
A node can have multiple pods. So that is not a problem.
Pre-emptible would have been an issue if the cluster had more than one node. The question clearly states that it is a single node cluster. That means if that single VM was pre-empted, neither of the pods should have been running. Since one pod is running, that means that (the only) VM is running. So, the reason the second pod is still pending because the VM is not having enough resources to run both the pods. Hence B.
Actually the question stated "single preemptible node pool" and not "single node" so it's possible that there are multiple nodes and one of the node on which the pod was scheduled on was preempted
D is correct as the node on which pod was scheduled to run was preempted & now this pod is scheduled to run on different preemtible node from the node-pool
Incorrect. There is a single preemtible instance, if it was preempted then both pods would show as 'Pending'. B is correct.
> There is a single preemtible instance Where does it say that? It doesn't. Don't make things up. There's a single pre-emptible node pool. A single pool is not the same as a single node.
No, because one of the pods may run on another node that its still up
D is a decoy meant to confuse you, answer is B
B , seems more correct as it dont have enough resources
When we consider the mention of "Pre-emptible Node Poll" , then the answer is obviously D.
I'm going D ....
option D: The pending Pod was originally scheduled on a node that has been preempted between the creation of the Deployment and your verification of the Pods' status. It is currently being rescheduled on a new node.
I will pick option D
answer is B
I go with B
B is correct
I would go with B. While D is possible, this scenario is less likely compared to the resource constraint issue, especially if the Pending status is observed consistently over a few minutes. Preemption would usually lead to a quicker rescheduling unless there are resource constraints.
The term 'preemptible node pool' is in the question. D is the answer.
D good choice
I would go for B
B is more correct. Maybe Troubleshooting Reason Not enough CPU or Memory or both of them.
I think so because main word of the question is preemptible pool nodes it can initialize some latency during creating node to find compliance machine.