KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.5
Explain how the scheduler places Pods and which mechanisms influence that placement.
Resource requests and limits, node selectors, affinity and anti-affinity, taints and tolerations, and the filtering-then-scoring model the scheduler applies. Candidates should be able to predict whether a Pod schedules given a described cluster state.
resource requests and limitsnodeSelectornode and pod affinitytaints and tolerationsscheduler filtering and scoring
Practice question for this objective
lock_openFree sampleKubernetes Fundamentalsmedium
A team wants two Pods of the same latency-sensitive application to be scheduled onto the same node so they share a low-latency link, and they want this decided relative to where other Pods of that application already run. Which placement mechanism expresses a rule based on the location of other Pods rather than on node attributes?
AnodeSelector, which matches Pods to nodes by comparing required labels against the labels present on each node.
BNode affinity, which constrains a Pod to nodes whose labels satisfy expressions such as a required zone or disk type.
CPod affinity, which schedules a Pod relative to nodes already running other Pods that match a label selector, using a topology key.check_circle Correct
DResource requests, which reserve CPU and memory so co-located Pods do not starve each other on a shared node.
Pod affinity places a Pod relative to other Pods' locations, whereas node affinity and nodeSelector match node attributes. Pod affinity and anti-affinity evaluate a label selector against Pods that are already scheduled, combined with a topology key that defines the co-location boundary such as a node or a zone. Node affinity and nodeSelector, by contrast, only inspect labels on the nodes themselves and are blind to other Pods.
Why A is wrong: nodeSelector is tempting because it also controls placement, but it matches on node labels alone and has no notion of where other Pods are running.
Why B is wrong: Node affinity is a richer version of nodeSelector, yet it still evaluates node labels rather than the presence of other Pods, so it cannot co-locate Pods relative to each other.
Why C is correct: Correct: pod affinity evaluates the labels of Pods already placed and a topology key, so it can draw a new Pod onto the same node or zone as matching Pods.
Why D is wrong: Requests influence which nodes have room, which sounds related to co-location, but they express capacity needs and never reference other Pods' locations.
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 limit, because it represents the maximum the container is ever allowed to use
errorWhy it is wrong: The limit does cap peak usage, which makes it seem like the figure that must fit, but the scheduler ignores limits when checking fit because a container is not guaranteed to reach its limit, so using it would overcount required capacity.
The limit of 1000m, because the scheduler must guarantee the Pod can burst to its maximum before placing it.
errorWhy it is wrong: This is tempting because the limit is the largest number and feels like the safe planning figure, but the scheduler does not reserve the limit; the limit is enforced at runtime by the kubelet and cgroups, not used for placement.
The container's CPU limit, which caps how much CPU the container may burst to at runtime
errorWhy it is wrong: Tempting because limits also mention CPU and feel like a ceiling the node must honour, but limits govern runtime throttling, not the scheduling filter, so they do not cause a Pending state.