Kubernetes DaemonSet Management

Kubernetes DaemonSet Management is the overarching practice of defining, deploying, updating, and operating apps/v1 DaemonSet resources, which guarantee that a copy of a specified Pod runs on every node (or every eligible node) in a cluster. It encompasses the full lifecycle of a daemon workload: the initial spec design, how the DaemonSet controller reconciles Pods against cluster node membership as nodes join and leave, how rolling updates are rolled out across an entire fleet of nodes without disrupting the function the daemon provides, and how daemon-specific failures are diagnosed given their inherently distributed, one-per-node nature.

Because a DaemonSet's Pod count is derived from cluster topology rather than chosen directly, management of a DaemonSet differs meaningfully from managing a Deployment: there is no replicas field to tune, and the primary levers available are which nodes are targeted, how updates are rolled out, and how individual Pod failures on specific nodes are detected and resolved.

The DaemonSet Controller's Reconciliation Loop

Node Membership Drives Pod Count

The DaemonSet controller continuously watches the set of nodes in the cluster and ensures exactly one Pod matching the DaemonSet's template exists on every node satisfying its scheduling constraints (nodeSelector, affinity, and tolerations for any taints present). When a new node joins the cluster and matches those constraints, a new Pod is created on it automatically; when a node is removed, its corresponding Pod is removed as well, without any explicit scaling action needed.

No replicas Field

Unlike Deployments and StatefulSets, a DaemonSet spec has no replicas field at all — attempting to set one is simply not part of the schema, since the desired count is implicitly "one per eligible node" and is not something an operator specifies as a number.

Scheduling Constraints

nodeSelector and Affinity

Restricting which nodes a DaemonSet targets is done the same way as for any other Pod template — nodeSelector for simple label matching, nodeAffinity for more expressive matching rules — allowing a DaemonSet to be scoped to a labeled subset of nodes (for example, only nodes with specific hardware) rather than the entire cluster.

Tolerations for Control-Plane and Special-Purpose Nodes

Because control-plane nodes and specially tainted nodes are excluded from ordinary scheduling by default, DaemonSets that need to run everywhere — including control-plane nodes — must explicitly add tolerations matching those taints. This is a common configuration point for infrastructure daemons like log collectors or CNI plugins, which genuinely do need presence on every node type.

tolerations:
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Exists"
    effect: "NoSchedule"

Update Strategies

RollingUpdate

spec.updateStrategy.type: RollingUpdate (the default) updates DaemonSet Pods incrementally, tearing down and recreating one node's Pod at a time (or a bounded number, via maxUnavailable) rather than all at once, so the daemon's function is never completely absent across the entire fleet simultaneously during an upgrade.

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

OnDelete

spec.updateStrategy.type: OnDelete disables automatic rollout entirely — updated Pods are only created when an operator manually deletes the existing Pod on a given node. This is used for daemons where an automatic, unattended fleet-wide rollout is considered too risky, and updates should instead be applied deliberately, node by node, under closer operator control.

Health and Failure Diagnosis

Per-Node Failure Isolation

Because each node has its own independent Pod, a DaemonSet failure is typically node-scoped rather than fleet-wide: one node's daemon Pod crash-looping does not affect the daemon's function on other nodes. Diagnosis therefore usually starts by identifying which specific node(s) are missing a healthy daemon Pod, rather than assuming the DaemonSet as a whole is broken.

kubectl get pods -l app=codartium-log-agent -o wide
kubectl get daemonset codartium-log-agent -o jsonpath='{.status.numberReady}/{.status.desiredNumberScheduled}'

Status Fields

.status.desiredNumberScheduled, .status.currentNumberScheduled, .status.numberReady, and .status.numberMisscheduled together describe rollout progress and health — numberMisscheduled in particular flags Pods running on nodes that no longer match the DaemonSet's current scheduling constraints, typically following a nodeSelector change.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-node-agent
spec:
  selector:
    matchLabels:
      app: codartium-node-agent
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
  template:
    metadata:
      labels:
        app: codartium-node-agent
    spec:
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
      containers:
        - name: agent
          image: codartium/node-agent:latest
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "100m"
              memory: "128Mi"