Skip to main content
DaemonSets ensure that a copy of a pod runs on all (or selected) nodes in the cluster. They are ideal for cluster-wide services like log collectors, monitoring agents, and storage daemons.

​
Key Concepts

DaemonSet

A controller that ensures pods run on all matching nodes automatically.

Node Selector

Labels that restrict which nodes run the DaemonSet pods.

Tolerations

Allow DaemonSet pods to run on tainted nodes (e.g., master nodes).

Rolling Update

Gradual update of pods across nodes while maintaining availability.

​
Required Permissions

​
DaemonSet Status Values

​
DaemonSet Metrics

​
How to View DaemonSets

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

Select Namespace

Choose a namespace or select “all” to view DaemonSets across all namespaces.
3

Filter and Search

Use the search box to find DaemonSets by name, or filter by status.

​
How to View DaemonSet Details

1

Find the DaemonSet

Locate the DaemonSet in the list.
2

Click DaemonSet Name

Click on the DaemonSet name to open the detail drawer.
3

Review Details

View DaemonSet information including:
  • Pod distribution across nodes
  • Container specifications
  • Update strategy configuration
  • Node selector and tolerations
  • Labels and annotations

​
How to Restart a DaemonSet

Restart triggers a rolling restart of pods on all nodes.
1

Find the DaemonSet

Locate the DaemonSet in the list.
2

Open Actions Menu

Click the actions menu (three dots) on the DaemonSet row.
3

Click Restart

Select Restart from the menu.
4

Monitor

Watch the status change to Updating as pods are replaced on each node.
Restart performs a rolling update by adding a kubectl.kubernetes.io/restartedAt annotation. Pods are updated one node at a time by default.

​
How to Create a DaemonSet

1

Click Create DaemonSet

Click the Create DaemonSet button in the page header.
2

Write YAML

Enter the DaemonSet manifest in YAML format. A template is provided.
3

Select Namespace

Choose the target namespace for the DaemonSet.
4

Create

Click Create to apply the manifest.
Common DaemonSet use cases include log collectors (Fluentd, Filebeat), monitoring agents (Prometheus Node Exporter, Datadog), and storage plugins (CSI drivers).

​
How to Edit a DaemonSet

1

Open Actions Menu

Click the actions menu on the DaemonSet row.
2

Click Edit YAML

Select Edit YAML to open the editor.
3

Modify Spec

Edit the DaemonSet specification. Common changes:
  • Container image (triggers rolling update)
  • Resource requests/limits
  • Environment variables
  • Node selector or tolerations
4

Save

Click Update to apply changes.
Changes to the pod template spec trigger a rolling update. Pods are replaced on each node according to the update strategy.

​
How to Delete a DaemonSet

1

Open Actions Menu

Click the actions menu on the DaemonSet row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion.
Deleting a DaemonSet removes pods from all nodes. Services relying on these pods (logging, monitoring) will stop functioning.

​
Update Strategies

DaemonSets support two update strategies: RollingUpdate parameters:
  • maxUnavailable - Maximum pods that can be unavailable during update (default: 1)
  • maxSurge - Maximum extra pods that can be created during update (optional)

​
Node Selection

DaemonSets use node selectors and tolerations to control pod placement: Node Selector:
Tolerations (for running on control plane nodes):

​
Troubleshooting

  • No nodes match the node selector
  • All matching nodes are tainted and DaemonSet lacks tolerations
  • Check node labels match the DaemonSet’s node selector
  • Verify tolerations for any taints on target nodes
  • Node may have taints that pods don’t tolerate
  • Node may not match the node selector
  • Node may have insufficient resources
  • Check node conditions and taints
  • Node selector was changed after pods were scheduled
  • Manually created pods matching the selector
  • Delete misscheduled pods or update the selector
  • maxUnavailable set too low (default is 1)
  • Pods taking long to become ready
  • Check pod events and logs for startup issues
  • Consider increasing maxUnavailable for faster updates
  • Check container logs for crash reasons
  • Verify resource limits aren’t too restrictive
  • Check if readiness/liveness probes are misconfigured
  • Ensure required volumes (hostPath, ConfigMaps) exist on nodes
  • New node may not match node selector
  • New node may have taints
  • Check if DaemonSet controller is healthy
  • Verify the new node is in Ready state

​
FAQ

Deployments run a specified number of replicas scheduled across available nodes. DaemonSets run exactly one pod per matching node, automatically adding pods when nodes join and removing them when nodes leave.
Yes, by adding tolerations for control-plane taints. By default, master nodes have node-role.kubernetes.io/control-plane:NoSchedule taint.
Use nodeSelector to match nodes with specific labels, or use nodeAffinity for more complex selection rules.
The DaemonSet controller automatically schedules a pod on the new node if it matches the node selector and the pod tolerates any taints.
No. DaemonSets don’t have a replica count. The number of pods is determined by the number of matching nodes. To control pod placement, modify the node selector or node labels.
RollingUpdate automatically updates pods when the template changes. OnDelete only updates pods when they are manually deleted, giving you full control over update timing.
Use RollingUpdate strategy with maxUnavailable: 1 (the default). This ensures only one pod is updated at a time across the cluster.
Check node selector matches, taint tolerations, and resource availability. Some system DaemonSets intentionally exclude certain node types.