City GPU GIS Pods must run only on workers labeled for GPUs. Which scheduling mechanism most directly constrains them to those nodes?
Select an answer to reveal the explanation.
Short Explanation
Want Pods only on GPU boxes? Label those nodes and point nodeSelector or required affinity at that label. Services and Ingress move traffic—they do not pick which node a Pod lands on.
Full Explanation
City GPU GIS Pods that must run only on workers labeled for GPUs should use a nodeSelector or required node affinity matching the GPU worker labels. Those scheduling constraints tell the scheduler to place Pods only on nodes that carry the required labels, which is the direct CKA mechanism for pinning accelerator workloads to labeled municipal GPU workers without relying on unrelated networking objects.
A ClusterIP Service that advertises only GPU node hostnames is a discovery object, not a scheduling constraint. An Ingress rule that redirects pods to nodes with accelerators operates at HTTP routing, not Pod placement. A ConfigMap that lists GPU serial numbers for kube-proxy to enforce invents a kube-proxy role that does not schedule Pods onto GPU nodes.
Exam caveat: required affinity or nodeSelector hard-fail when no matching nodes exist, leaving Pods Pending; preferred affinity is softer. Operational check: label GPU nodes, set nodeSelector or required affinity on the GIS Pods, and confirm they schedule only on those workers. 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.