DaemonSets for per-node workloads in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of DaemonSet Pod Distribution

You have a DaemonSet running on a Kubernetes cluster with 3 nodes. After running kubectl get pods -o wide, how many pods will you see for this DaemonSet?

A 3 pods, one on each node

B 1 pod, scheduled on the master node only

C 0 pods, DaemonSets do not create pods automatically

D 3 pods, but all scheduled on the same node

💡 Hint

DaemonSets ensure one pod per node unless node selectors or taints prevent scheduling.

A DaemonSet creates exactly one pod on each node in the cluster (unless restricted by node selectors or taints). So with 3 nodes, you get 3 pods.

🧠 Conceptual

intermediate

Purpose of DaemonSets

What is the main purpose of using a DaemonSet in Kubernetes?

A To run a copy of a pod on every node for node-level tasks

B To manage multiple replicas of a pod for load balancing

C To schedule pods only on master nodes

D To create pods that run only once and then exit

💡 Hint

Think about tasks that need to run on all nodes, like monitoring or logging.

DaemonSets are designed to run one pod on each node to perform node-specific tasks such as monitoring, logging, or networking.

❓ Troubleshoot

advanced

DaemonSet Pods Not Running on New Nodes

You added two new nodes to your Kubernetes cluster, but the DaemonSet pods are not appearing on these new nodes. What is the most likely cause?

A Pods are scheduled only on nodes labeled as 'worker' and new nodes are labeled 'master'

B DaemonSets only schedule pods on nodes present at creation time

C The DaemonSet controller needs to be restarted manually

D The new nodes are tainted and the DaemonSet has no tolerations

💡 Hint

Check node taints and tolerations for DaemonSet pods.

If new nodes have taints that the DaemonSet pods do not tolerate, pods will not be scheduled on those nodes.

❓ Configuration

advanced

DaemonSet Node Selector Configuration

You want your DaemonSet pods to run only on nodes labeled disk=ssd. Which snippet correctly configures this in the DaemonSet spec?

A "tolerations": [{"key": "disk", "value": "ssd"}]

B "nodeSelector": {"disk": "ssd"}

C "nodeSelector": {"ssd": "disk"}

D "affinity": {"nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disk", "operator": "In", "values": ["ssd"]}]}]}}}

💡 Hint

Node selectors use key-value pairs to filter nodes.

The nodeSelector field uses key-value pairs to select nodes. Option B correctly uses the label key and value.

✅ Best Practice

expert

Best Practice for Updating DaemonSet Pods

You need to update the container image of a DaemonSet without downtime. Which strategy is best to achieve this?

A Delete the DaemonSet and recreate it with the new image

B Manually delete pods one by one to force recreation with the new image

C Use the DaemonSet rolling update strategy with maxUnavailable set to 1

D Update the DaemonSet spec and immediately restart the kubelet on all nodes

💡 Hint

DaemonSets support rolling updates to minimize downtime.

The rolling update strategy allows updating pods gradually, controlling how many pods can be unavailable during the update.