An open-data portal wants Deployment replicas to avoid co-locating on the same host for higher availability. Which scheduling feature helps spread those Pods?
Select an answer to reveal the explanation.
Short Explanation
Anti-affinity is how you tell the scheduler not to stack all your eggs on one node. Service sticky sessions and probe timers do not spread replicas across hosts.
Full Explanation
An open-data portal that wants Deployment replicas to avoid co-locating on the same host for higher availability should use Pod anti-affinity rules that prefer or require placing replicas on different nodes. Inter-pod anti-affinity, and similarly topology spread constraints, express spreading so one worker failure does not take out every portal replica at once during a civic open-data incident.
Session affinity on a ClusterIP Service forcing sticky node placement is about client stickiness to backends, not spreading replicas across nodes. A single-replica Deployment combined with hostNetwork reduces HA rather than improving it. readinessProbe.periodSeconds set lower than liveness does not scatter Pods across hosts.
Exam caveat: required anti-affinity can leave Pods Pending if not enough nodes exist; preferred is softer for smaller clusters. Operational check: add pod anti-affinity on hostname topology, scale the portal, and verify replicas land on distinct nodes with kubectl get pods -o wide. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.