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. Correct
- DResource requests, which reserve CPU and memory so co-located Pods do not starve each other on a shared node.
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.