When should I use a DaemonSet instead of a Deployment?

Use a DaemonSet whenever you need exactly one copy of a Pod running on every node (or every node matching a selector), such as a log collector, node monitoring agent, or CNI/storage plugin. A Deployment's replica count is decoupled from the number of nodes, so it's the wrong tool whenever 'one per node' is the actual requirement.

Why would I need tolerations on a DaemonSet?

Nodes are often tainted to repel ordinary workloads, control-plane nodes, GPU nodes reserved for specific jobs, nodes still being provisioned, and so on. Since a DaemonSet's whole purpose is often to run infrastructure-level agents everywhere (including on those tainted nodes), tolerations are how you tell the scheduler this particular DaemonSet Pod is allowed to run there anyway.

What's the difference between the toleration operators Exists and Equal?

'Equal' matches a taint only when both the key and the value match exactly, and requires you to fill in a value. 'Exists' matches any taint with the given key regardless of its value (and if you also leave the key blank, it matches all taints), which is the more common choice for broadly tolerating a category of taint like 'node-role.kubernetes.io/control-plane'.

RollingUpdate vs OnDelete, what changes?

RollingUpdate (the default) automatically replaces old DaemonSet Pods with new ones as soon as you update the manifest, node by node. OnDelete only replaces a Pod once you manually delete it, giving you full manual control over rollout timing, useful for cautious rollouts of node-critical agents.

DaemonSet YAML Generator

Overview

Introduction

DaemonSets exist for the class of workloads that need to run on every node rather than a fixed replica count, log shippers, node exporters, CNI agents, but their tolerations and nodeSelector fields have a fiddly nested shape that's easy to get wrong from memory.

This tool builds a DaemonSet manifest from a form covering image, ports, environment variables, a node selector, repeatable tolerations, and the update strategy.

What Is Kubernetes DaemonSet Generator?

A form-based generator for the `apps/v1/DaemonSet` resource, the workload controller that ensures a copy of a Pod runs on every node (or every matching node) in the cluster.

It supports a nodeSelector for pinning the DaemonSet to nodes with a given label, and a repeatable list of tolerations so the Pod can be scheduled on nodes that would otherwise repel it.

How Kubernetes DaemonSet Generator Works

Name, image, container ports, and env vars fill in the Pod template the same way they would for any other workload, while nodeSelector and each toleration row map directly onto their respective spec.template.spec fields.

For each toleration, the operator you choose determines which fields are emitted: 'Exists' omits value entirely, 'Equal' requires and includes it, matching how the Kubernetes API itself treats the two operators.

When To Use Kubernetes DaemonSet Generator

Use it for cluster-wide infrastructure Pods: log collectors (Fluent Bit, Fluentd), metrics agents (node-exporter), CNI plugins, or storage daemons that need a presence on every node.

Use the tolerations rows whenever that agent also needs to run on tainted nodes, like control-plane nodes or nodes reserved for a specific workload class.

Often used alongside Kubernetes NetworkPolicy Generator and Kubernetes RBAC Generator.

Features

Advantages

Handles the Exists/Equal toleration operator distinction correctly, only emitting a `value` field when the operator actually requires one.
Supports multiple container ports and environment variables without extra boilerplate.
Covers both update strategies, so rollout behavior is explicit in the generated manifest rather than left to the (often forgotten) default.

Limitations

Supports one nodeSelector key/value pair; workloads needing multiple selector labels will need to hand-add additional lines.
Doesn't generate the RollingUpdate strategy's `maxUnavailable` sub-field, defaulting instead to the API server's own default for that value.

Examples

A log-collector DaemonSet tolerating the control-plane taint

Input

name: log-agent, image: fluent/fluent-bit:3.1, containerPorts: [2020], nodeSelectorKey: '', tolerations: [{operator: Exists, key: node-role.kubernetes.io/control-plane, effect: NoSchedule}], updateStrategy: RollingUpdate

Output

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      tolerations:
        - operator: Exists
          key: node-role.kubernetes.io/control-plane
          effect: NoSchedule
      containers:
        - name: log-agent
          image: fluent/fluent-bit:3.1
          ports:
            - containerPort: 2020

The Exists operator lets this DaemonSet run on control-plane nodes without needing to match a specific taint value.

Best Practices & Notes

Best Practices

Only add tolerations for the specific taints you actually need to run on, over-tolerating can put agent Pods on nodes they weren't meant to run on.
Use RollingUpdate for most day-to-day agents, and switch to OnDelete only when you need to stage a rollout manually across a fleet of nodes.
Set resource requests/limits on the container even though this generator focuses on scheduling fields, an unconstrained DaemonSet Pod runs on every node and can starve real workloads if it misbehaves.

Developer Notes

Toleration rendering mirrors the API server's own handling of the two operators: `Equal` always includes both `key` and `value` fields plus `effect`, while `Exists` omits `value` and includes `key` only when one was provided (an empty key with `Exists` tolerates all taints matching the given effect). The node selector is intentionally a single key/value pair rather than a repeatable list, since `nodeSelector` is a flat map and most real DaemonSets only pin on one or two labels.

Kubernetes DaemonSet Generator Use Cases

Deploying a node-level logging or metrics agent across an entire cluster
Running a CNI or CSI node plugin that must be present on every node, including control-plane nodes
Restricting an infrastructure Pod to a specific node pool via nodeSelector, e.g. GPU nodes only

Common Mistakes

Using operator Equal but leaving the value blank, which the Kubernetes API rejects since Equal requires an exact value match.
Forgetting a toleration entirely and then wondering why the DaemonSet Pod never schedules onto tainted control-plane or dedicated nodes.
Setting nodeSelector to a label that no nodes actually carry, silently leaving the DaemonSet with zero running Pods.

Tips

Check `kubectl describe node <name>` for existing taints before writing tolerations, so the effect and key you choose actually match what's applied in your cluster.

Kubernetes DaemonSet Generator