DevOps Dictionary

Kubernetes DaemonSet is a Kubernetes workload API object that runs a copy of a pod on every selected node in a cluster. In practical terms, it is how you deploy node-level agents such as log collectors, metrics exporters, storage plugins, or security scanners without manually scheduling one pod per node.

What a DaemonSet does

A DaemonSet ensures that matching nodes run one pod from its template. When you add a new node to the cluster, Kubernetes automatically schedules the DaemonSet pod on that node. When you remove a node, Kubernetes removes the pod with it.

You typically use a DaemonSet when the workload must run close to the node itself, rather than as a normal application replica behind a Service.

Common use cases

• Log collection: Run Fluent Bit, Fluentd, or Vector on each node to collect container and node logs.
• Metrics collection: Run Prometheus Node Exporter or other node-level metric agents.
• Security monitoring: Run runtime security agents, file integrity agents, or vulnerability scanners on every node.
• Networking: Run CNI-related components that need to exist on each node.
• Storage: Run CSI node plugins that attach, mount, or manage volumes on worker nodes.

How a DaemonSet works

A DaemonSet uses a pod template, selectors, and optional scheduling rules. The Kubernetes controller watches the cluster and creates or removes pods so the desired node coverage stays correct.

By default, a DaemonSet targets all eligible nodes. You can narrow that scope with node selectors, node affinity, taints, and tolerations. For example, you might run a GPU monitoring agent only on nodes labeled accelerator=nvidia, or run an infrastructure agent on nodes that normal application pods cannot tolerate.

Key parts of a DaemonSet

• Pod template: Defines the container image, commands, environment variables, ports, volumes, and security context.
• Selector: Tells Kubernetes which pods belong to the DaemonSet.
• Node selection rules: Control which nodes should run the pod.
• Tolerations: Allow the pod to run on tainted nodes, such as control plane nodes or dedicated infrastructure nodes.
• Update strategy: Controls how Kubernetes rolls out changes to DaemonSet pods.

DaemonSet updates

DaemonSets usually use a rolling update strategy. When you change the pod template, Kubernetes updates the pods across nodes while respecting the configured rollout settings.

This matters for cluster-critical agents. A bad logging or networking agent update can affect every node. In production, test DaemonSet changes in a staging cluster or limit rollout speed with maxUnavailable. During cluster version changes, include DaemonSets in your plan because old agents may not work with newer Kubernetes versions. This is especially important when preparing Kubernetes upgrades for startup environments.

DaemonSet vs Deployment

A Deployment runs a desired number of pod replicas. Kubernetes can place those replicas on any suitable nodes. You use a Deployment for stateless application workloads, APIs, workers, and web services.

A DaemonSet runs one pod per selected node. You use it when the workload is tied to the node itself. For example, an API service should usually run as a Deployment, while a log collector should usually run as a DaemonSet.

DaemonSet vs StatefulSet

A StatefulSet manages pods that need stable identities, ordered rollout, and persistent storage. Databases and distributed systems often use StatefulSets.

A DaemonSet does not focus on stable pod identity. It focuses on node coverage. If a node exists and matches the rules, the DaemonSet should have a pod there.

Benefits

• Automatic node coverage: New nodes get the required agent without manual work.
• Consistent operations: Every selected node runs the same monitoring, logging, or security component.
• Simple node-level scheduling: You define the rule once, and Kubernetes handles placement.
• Useful for platform teams: Platform and SRE teams can standardize infrastructure agents across many workloads.

Tradeoffs and limitations

• Cluster-wide blast radius: A broken DaemonSet can affect many nodes at once.
• Resource overhead on every node: Even a small agent can add up across large clusters.
• Scheduling complexity: Taints, tolerations, affinity, and node labels can make placement harder to debug.
• Not ideal for normal app scaling: If you need 3, 10, or 50 replicas based on demand, use a Deployment or autoscaling pattern instead.

Simple example

Assume you run a Kubernetes cluster on Amazon EKS and need to collect logs from every worker node. You can deploy Fluent Bit as a DaemonSet. Kubernetes schedules one Fluent Bit pod on each eligible node. Each pod reads logs from that node and forwards them to your logging backend.

If your node group scales from 5 nodes to 8 nodes, Kubernetes creates 3 more Fluent Bit pods automatically. If the cluster scales back down to 4 nodes, Kubernetes removes the DaemonSet pods from the deleted nodes.

Managing DaemonSets

You can create and manage DaemonSets with standard Kubernetes YAML and kubectl. Many teams also manage them through Helm, Kustomize, GitOps tools, or Terraform. If your team manages Kubernetes manifests through infrastructure as code, the same workflow used to deploy Kubernetes resources using Terraform can also manage DaemonSets.

DaemonSets often sit near cluster infrastructure rather than application code. In mature setups, platform teams define baseline DaemonSets for logging, metrics, security, and networking, then application teams deploy their services on top of that foundation.

When to use a DaemonSet

Use a DaemonSet when the workload must run on every selected node and perform node-specific work. Avoid it for ordinary application services, background jobs, or workloads that should scale by replica count rather than node count.

A good rule: if the pod needs access to node logs, node metrics, host paths, local devices, or node-level networking, a DaemonSet may be the right Kubernetes object.