DaemonSets for per-node workloads in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the kind of Kubernetes object for a DaemonSet.

Kubernetes

apiVersion: apps/v1
kind: [1]
metadata:
  name: node-logger
spec:
  selector:
    matchLabels:
      name: node-logger
  template:
    metadata:
      labels:
        name: node-logger
    spec:
      containers:
      - name: logger
        image: busybox
        command: ['sh', '-c', 'echo Logging from node; sleep 3600']

Drag options to blanks, or click blank then click option'

ADaemonSet

BDeployment

CService

DPod

Attempts:

3 left

💡 Hint

Common Mistakes

Using Deployment instead of DaemonSet

Using Pod directly without a controller

The kind field specifies the type of Kubernetes object. For running a pod on every node, use DaemonSet.

2fill in blank

medium

Complete the code to select pods with the correct label for the DaemonSet.

Kubernetes

spec:
  selector:
    matchLabels:
      name: [1]
  template:
    metadata:
      labels:
        name: node-logger

Drag options to blanks, or click blank then click option'

Aweb-server

Bnode-logger

Cdatabase

Dcache

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatch between selector and pod labels

Using unrelated labels

The selector.matchLabels must match the labels in the pod template to manage the pods correctly.

3fill in blank

hard

Fix the error in the container command to keep the pod running.

Kubernetes

containers:
- name: logger
  image: busybox
  command: ['sh', '-c', [1]]

Drag options to blanks, or click blank then click option'

A"echo Logging from node; sleep 3600"

B"echo Logging from node"

C"sleep 10"

D"exit 0"

Attempts:

3 left

💡 Hint

Common Mistakes

Using only echo causes the container to exit

Using too short sleep time

The command must keep the container running. Using sleep 3600 after echo keeps it alive for an hour.

4fill in blank

hard

Fill both blanks to specify the container image and the restart policy for the DaemonSet pods.

Kubernetes

spec:
  template:
    spec:
      containers:
      - name: logger
        image: [1]
      restartPolicy: [2]

Drag options to blanks, or click blank then click option'

Abusybox

BAlways

CNever

Dnginx

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong image name

Using restartPolicy other than Always

The container image is busybox for a lightweight shell. The restart policy for DaemonSet pods is usually Always to keep pods running.

5fill in blank

hard

Fill all three blanks to create a DaemonSet that runs a pod with label 'app: monitor', image 'alpine', and command to sleep indefinitely.

Kubernetes

apiVersion: apps/v1
kind: [1]
metadata:
  name: monitor
spec:
  selector:
    matchLabels:
      app: [2]
  template:
    metadata:
      labels:
        app: monitor
    spec:
      containers:
      - name: monitor
        image: [3]
        command: ['sh', '-c', 'sleep infinity']

Drag options to blanks, or click blank then click option'

ADaemonSet

Bmonitor

Calpine

DDeployment

Attempts:

3 left

💡 Hint

Common Mistakes

Using Deployment instead of DaemonSet

Mismatch between selector and pod labels

Wrong container image

The kind is DaemonSet to run pods on all nodes. The label app: monitor matches the pod template. The image alpine is a small Linux image suitable for this task.

Practice

1. What is the main purpose of a DaemonSet in Kubernetes?

easy

A. To expose services outside the cluster

B. To manage persistent storage volumes

C. To run one pod on every node in the cluster

D. To schedule batch jobs at specific times

Solution

1. Step 1: Understand DaemonSet functionality

   A DaemonSet ensures that a copy of a pod runs on all or some nodes in the cluster.

2. Step 2: Compare with other Kubernetes objects

   Other objects like Jobs or Services do not guarantee one pod per node; DaemonSet does.

3. Final Answer:

   To run one pod on every node in the cluster -> Option C

4. Quick Check:

   DaemonSet = one pod per node [OK]

Hint: DaemonSet always runs pods on all nodes [OK]

Common Mistakes:

• Confusing DaemonSet with Deployment
• Thinking DaemonSet manages storage
• Assuming DaemonSet schedules batch jobs

2. Which of the following is the correct way to specify a DaemonSet selector in the YAML manifest?

easy

A. selector:
labels:
app: my-daemon

B. selector:
matchLabels:
app: my-daemon

C. selector:
matchExpressions:
- key: app
operator: Equals
values: [my-daemon]

D. selector:
matchLabels:
app: my-daemon
matchExpressions:
- key: tier
operator: In
values: [backend]

Solution

1. Step 1: Recall DaemonSet selector syntax

   The selector must use matchLabels or matchExpressions under selector.

2. Step 2: Identify correct syntax

   selector: matchLabels: app: my-daemon uses matchLabels correctly with key-value pairs. selector: labels: app: my-daemon is invalid because it uses labels instead of matchLabels. selector: matchExpressions: - key: app operator: Equals values: [my-daemon] has wrong operator case and structure. selector: matchLabels: app: my-daemon matchExpressions: - key: tier operator: In values: [backend] mixes both but DaemonSet selector only supports one selector type.

3. Final Answer:

   selector: matchLabels: app: my-daemon -> Option B

4. Quick Check:

   DaemonSet selector uses matchLabels [OK]

Hint: Use matchLabels under selector for DaemonSet [OK]

Common Mistakes:

• Using 'labels' instead of 'matchLabels'
• Incorrect operator casing in matchExpressions
• Mixing matchLabels and matchExpressions in selector

3. Given this DaemonSet YAML snippet, what will happen when a new node joins the cluster?

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
      - name: log-agent
        image: log-agent:latest

medium

A. A pod named log-agent will be created on the new node automatically

B. No pod will be created until manually triggered

C. The DaemonSet will fail due to missing node selector

D. Pods will be created only on nodes labeled 'log-agent'

Solution

1. Step 1: Understand DaemonSet behavior on new nodes

   DaemonSets automatically create pods on every node that matches the selector, including new nodes joining the cluster.

2. Step 2: Check node selector usage

   This DaemonSet has no node selector restricting nodes, so it applies to all nodes.

3. Final Answer:

   A pod named log-agent will be created on the new node automatically -> Option A

4. Quick Check:

   DaemonSet pods auto-create on new nodes [OK]

Hint: DaemonSet pods auto-launch on all nodes by default [OK]

Common Mistakes:

• Assuming manual pod creation on new nodes
• Thinking node selector is mandatory
• Believing pods only run on labeled nodes

4. You created a DaemonSet but no pods are running on any node. Which of these is the most likely cause?

medium

A. The DaemonSet is created in the wrong namespace

B. The DaemonSet spec is missing the container image

C. The cluster has no nodes available

D. The pod template labels do not match the DaemonSet selector

Solution

1. Step 1: Check DaemonSet selector and pod template labels

   DaemonSet requires the selector to match the pod template labels exactly; otherwise, pods won't be created.

2. Step 2: Evaluate other options

   Missing container image causes pod creation failure but usually shows pod errors. No nodes means no pods but is rare. Wrong namespace means DaemonSet exists but unrelated to nodes.

3. Final Answer:

   The pod template labels do not match the DaemonSet selector -> Option D

4. Quick Check:

   Selector and pod labels must match [OK]

Hint: Match pod labels with selector to run DaemonSet pods [OK]

Common Mistakes:

• Ignoring label mismatch between selector and template
• Assuming missing image stops pod creation silently
• Not verifying cluster node availability

5. You want to run a logging agent on all Linux nodes but exclude Windows nodes in your Kubernetes cluster. How should you configure the DaemonSet?

hard

A. Add a nodeSelector with kubernetes.io/os: linux in the pod spec

B. Add a tolerations for Windows taints in the pod spec

C. Set the DaemonSet selector to os: linux label

D. Use a Deployment instead of DaemonSet with node affinity

Solution

1. Step 1: Identify how to target Linux nodes only

   Kubernetes labels nodes with kubernetes.io/os set to their OS. Using nodeSelector with kubernetes.io/os: linux restricts pods to Linux nodes.

2. Step 2: Evaluate other options

   Tolerations are for taints, not OS filtering. Selector matches pod labels, not nodes. Deployment does not guarantee one pod per node.

3. Final Answer:

   Add a nodeSelector with kubernetes.io/os: linux in the pod spec -> Option A

4. Quick Check:

   Use nodeSelector to filter nodes by OS [OK]

Hint: Use nodeSelector with OS label to filter nodes [OK]

Common Mistakes:

• Using selector to filter nodes instead of nodeSelector
• Confusing tolerations with node filtering
• Using Deployment instead of DaemonSet for per-node pods