Associate Cloud Engineer free question 6 / 10 · Domain 3: Ensuring the successful operation of a cloud solution
In a Standard cluster, you are deleting the node pool pool-a, which has an older machine type. Pods in pool-a have a PodDisruptionBudget (PDB), and some Pods name pool-a in a nodeSelector. According to the GKE page on node pools, what happens at deletion?
- GKE honors PDBs by default, so draining stalls while a PDB is not met, and the deletion does not proceed
- GKE drains each node; by default it does not honor PDBs, and Pods that target pool-a may be left with no place to run
- GKE stops the VMs without draining, so run kubectl drain first if you want Pods to end gracefully
- Pods that select pool-a with a nodeSelector have the selector removed and move to another node pool and keep running
Show the answer and explanation
Answer: B
Why this is correct
According to the section on deleting node pools, when you delete a node pool GKE drains all the nodes in the node pool, deletes the Pods, and reschedules them. It gives Pods a grace period of up to the maximum terminationGracePeriodSeconds set on the Pods on the node (capped at one hour). By default, GKE does not honor PDBs when it deletes a node pool. Also, Pods with a specific nodeSelector can remain unschedulable if no other node meets the condition. Before deleting, you need to prepare the destination node pool and the Pod settings.
Why the other options are wrong
"GKE honors PDBs by default, so draining stalls while a PDB is not met, and the deletion does not proceed" … The page says that by default GKE does not honor PDB settings when it deletes a node pool. To have them honored, you update the node pool settings to respect PDBs (the one-hour cap applies in that case too).
"GKE stops the VMs without draining, so run kubectl drain first if you want Pods to end gracefully" … Stopping without draining is described on the page for deleting a cluster. When you delete a node pool, GKE drains all the nodes in the node pool, deletes the Pods, and reschedules them. Running kubectl drain first is recommended for deleting a cluster.
"Pods that select pool-a with a nodeSelector have the selector removed and move to another node pool and keep running" … The page says that if a Pod has a specific nodeSelector, it can remain unschedulable when no other node in the cluster meets the condition. There is no explanation that the selector is removed; a nodeSelector is what restricts the Pod to the nodes of that node pool.
Where people get tripped up
The page warns you to keep at least one node pool before deleting the default node pool or putting a strong taint on all node pools, so that kube-system Pods such as kube-dns and konnectivity-agent can still be scheduled. You cannot delete an Autopilot-managed node pool in a Standard cluster. You can create, upgrade, and delete node pools individually without affecting the whole cluster.
Go to the Associate Cloud Engineer practice app (10 free questions; purchase unlocks all questions)