Stakeholders say both a DaemonSet and a Deployment can "run on all nodes." Which distinction should guide the choice?
Select an answer to reveal the explanation.
Short Explanation
"All nodes" sounds the same in a meeting, but the controllers differ. DaemonSet means coverage per node; Deployment means "keep N copies alive somewhere." Pick the controller that matches the promise, not the slogan.
Full Explanation
Stakeholders sometimes say both a DaemonSet and a Deployment can “run on all nodes.” Guide the choice with a clear distinction: choose a DaemonSet when you need one Pod per eligible node (node log agents, host networking helpers, local caches); choose a Deployment when you need a desired replica count scheduled onto any eligible nodes for an ordinary application. Setting Deployment replicas equal to today’s node count only coincidentally covers nodes and drifts as the cluster autoscales.
Deployments do not always pin exactly one Pod to every node. The objects are not identical merely because replicas equals node count at create time. Using a Job for per-node coverage is wrong—Jobs finish, and they do not automatically assign nodeName for fleet-wide coverage the way DaemonSets track the node lifecycle.
Exam caveat: DaemonSet versus Deployment selection is a frequent CKAD discriminator. Add nodeSelector, affinity, and tolerations on DaemonSets when municipal nodes are tainted or pooled.
Operational check: scale the cluster (or simulate with an extra node) and observe DaemonSet Pod count track nodes while a Deployment Pod count stays at its replicas; kubectl get ds,deploy -o wide to compare placement.