CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Delete the taint from the node

  Why it's wrong here

  Deleting the taint from the node only erases the 'NoSchedule' marker; it does not create or free any CPU capacity. The scheduler still requires a node whose allocatable resources can accommodate the pod's requests, and if the previously tainted node is already at its request limit or the other nodes are full, the pod stays pending. In a production cluster, removing a taint prematurely can cause other workloads to be scheduled onto the node, further increasing CPU pressure and making the situation worse.

• ✓

  Scale down other deployments to free CPU

  Why this is correct

  Scaling down other Deployments reduces the total CPU requests reported against those nodes, which is exactly what the scheduler uses to compute resource availability. When the request sums drop below a node's allocatable capacity, the pending pod's request can fit, enabling successful placement. This resolves the root cause of the pending state without altering the pod's toleration settings or risking node stability, and it is a common operational remedy for clusters experiencing CPU exhaustion.

• ✗

  Increase the CPU limits only

  Why it's wrong here

  Increasing the CPU limits only changes the upper bound enforced by the cgroup for runtime throttling; it does not alter the CPU request, which is the value used by the kube-scheduler when determining node fit. Without a toleration, the pod still cannot be placed on the tainted node, and on all other nodes the scheduler sees the same request, so no new node becomes feasible. Limits affect how much CPU the container may consume after admission, not whether it can be admitted.

• ✗

  Add the required toleration to the pod spec and increase CPU requests

  Why it's wrong here

  Adding the required toleration removes the taint-based admission restriction, so the pod would be allowed onto the tainted node, but that node already lacks allocatable CPU to satisfy the pod's request. Raising CPU requests simultaneously increases the amount of idle CPU the scheduler demands on every candidate node, making the existing resource shortage more severe and shrinking the set of feasible nodes. The pod remains pending because the underlying capacity deficit is not resolved; the toleration only addresses a scheduling restriction, not resource availability.

Go deeper

Related to this question