DaemonSet Manifest Validation

DaemonSet Configuration

DaemonSets ensure that a copy of a Pod runs on every node (or a subset of nodes). They are commonly used for log collectors, monitoring agents, and storage drivers.

Example DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  labels:
    app: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
        - name: fluentd
          image: fluent/fluentd:v1.16
          resources:
            requests:
              cpu: 100m
              memory: 200Mi
            limits:
              cpu: 500m
              memory: 500Mi
          livenessProbe:
            httpGet:
              path: /fluentd.healthcheck
              port: 24220
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

DaemonSet Considerations

DaemonSets differ from Deployments in several ways:

• No replicas field: Runs one pod per matching node
• Node scheduling: Uses nodeSelector, affinity, or tolerations to target specific nodes
• Update strategy: Uses RollingUpdate (default) or OnDelete
• Priority: Often needs to run before application pods

Common DaemonSet Use Cases

Agent Type	Example	Typical Requirements
Log collector	Fluentd, Filebeat	Read access to /var/log
Monitoring	Node Exporter, Datadog	Host network, /proc access
Storage driver	CSI drivers	Privileged (necessary)
Network plugin	Calico, Cilium	Host network, privileged

Resource Limits for DaemonSets

Resource limits on DaemonSets are especially important because they run on every node. A DaemonSet without limits can consume node resources needed by application Pods. The total resource consumption is limits x number_of_nodes, so even small limits add up.