KCNA - Container Orchestration (28% of the exam) - Section 2.4
Identify the cause of common workload failures from the symptoms a cluster reports.
ImagePullBackOff, CrashLoopBackOff, Pending due to insufficient resources or unsatisfied affinity, OOMKilled, and failing readiness probes. Candidates should map a described symptom to its most likely cause and the next diagnostic step.
ImagePullBackOffCrashLoopBackOffOOMKilledPending podskubectl logs and events
Practice question for this objective
lock_openFree sampleContainer Orchestrationmedium
A HorizontalPodAutoscaler has already raised a Deployment to its maximum replicas, but several of the new Pods remain in Pending state with a message that no node has enough allocatable CPU to schedule them. Every existing node is already fully committed. Which cluster component is responsible for resolving this by adding capacity?
AThe HorizontalPodAutoscaler raising the replica ceiling
BThe cluster autoscaler watching for unschedulable Podscheck_circle Correct
CA LimitRange loosening per-container requests
DThe kube-scheduler retrying placement more aggressively
The cluster autoscaler adds worker nodes when Pods are unschedulable because existing nodes lack allocatable resources. The cluster autoscaler continuously checks for Pods stuck Pending due to insufficient resources and, when it finds them, requests new nodes from the infrastructure so the scheduler gains somewhere to place those Pods.
Why A is wrong: Tempting because the HPA is already involved, but it only adjusts replica count and is at its maximum; adding still more Pods cannot help when no node has capacity to run them.
Why B is correct: Correct because the cluster autoscaler detects Pods that cannot be scheduled for lack of node resources and provisions additional nodes so the pending Pods can be placed.
Why C is wrong: Tempting because request sizing affects scheduling, but a LimitRange sets defaults and bounds for container requests and limits and cannot create the extra node capacity the Pods need.
Why D is wrong: Tempting because the scheduler is what leaves the Pods Pending, but it can only place Pods onto existing nodes and has no ability to add nodes to the cluster.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
The Pod is missing a readiness probe, so the scheduler refuses to place it until the probe is defined.
errorWhy it is wrong: A missing readiness probe is a plausible cause of a Pod not receiving traffic, but a readiness probe governs Service endpoint membership, not whether a claim can bind or a Pod can be scheduled onto a node.
A HorizontalPodAutoscaler on the affected workloads
errorWhy it is wrong: Tempting because it adds Pods under load, but creating more replicas without more node capacity only produces more Pending Pods.
A NodePort Service, which reserves a port on every node so internal Pods can connect through any node address reliably.
errorWhy it is wrong: NodePort is tempting because it also gives a stable target, but it opens a port on every node's external IP, exposing the cache beyond the cluster, which the requirement forbids.