Library catalog Pods should prefer SSD-backed nodes when available but still schedule elsewhere if needed. Which construct expresses that soft preference?
Select an answer to reveal the explanation.
Short Explanation
Soft preference is preferred affinity—Kubernetes tries for the SSD nodes but will settle elsewhere if it must. Required affinity is a hard gate; that is not what soft preference means.
Full Explanation
Library catalog Pods that should prefer SSD-backed nodes when available but still schedule elsewhere if needed need preferredDuringSchedulingIgnoredDuringExecution node affinity weighting SSD node labels. Preferred soft affinity scores matching nodes higher but still allows scheduling on non-SSD nodes when preferred capacity is insufficient—exactly the soft preference municipal catalogs need for performance without hard downtime when SSD nodes fill up.
A requiredDuringScheduling node affinity that makes non-SSD nodes permanently unschedulable is a hard rule, not a soft preference. A taint without any toleration repels Pods rather than expressing a soft SSD preference. A LimitRange that converts preferred affinity into a memory limit invents a nonexistent conversion between scheduling and resource defaults.
Exam caveat: IgnoredDuringExecution means affinity is evaluated at schedule time, not continuously enforced by eviction when labels change later. Operational check: apply preferred node affinity for SSD labels, fill SSD nodes in a test, and confirm catalog Pods still schedule onto other Ready nodes. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.