Workloads and Scheduling

Controlling Where and How Pods Run

Kubernetes rarely runs a bare Pod directly in production. A Deployment wraps a ReplicaSet, which wraps a set of identical Pods, giving you self healing and rolling updates for free. On top of that, several independent mechanisms let you steer which node a Pod lands on and how many can run at once, and the exam expects you to combine them correctly rather than just recall each one in isolation.

Exam tip. A Pod that will not schedule despite plenty of free capacity is almost always a taint with no matching toleration, or an affinity rule with no node that satisfies it. Check kubectl describe node for taints before assuming the scheduler is broken.

1. A DaemonSet is used to run a logging agent on every node, but a set of dedicated nodes reserved for GPU workloads has the taint dedicated=gpu:NoSchedule applied. What must be added to the DaemonSet's pod template so the logging agent still runs on those GPU nodes?

• A. A toleration matching key dedicated, value gpu, and effect NoSchedulecorrect
• B. A nodeSelector for dedicated=gpu
• C. A resource limit that exceeds the GPU node's capacity
• D. An affinity rule with preferredDuringSchedulingIgnoredDuringExecution

Taints repel pods unless the pod defines a matching toleration, so the DaemonSet's pod template needs a toleration with the same key, value, and effect as the node's taint to be scheduled there. A nodeSelector alone would target the nodes but the taint would still block scheduling without a toleration. Resource limits are unrelated to taints. A preferred affinity rule only expresses a scheduling preference and does not override a taint.