DaemonSets

Introduction to DaemonSets

DaemonSets ensure that a copy of a pod runs on all (or some) nodes in the cluster. As nodes are added to the cluster, pods are automatically added to them. When nodes are removed, the pods are garbage collected.

DaemonSets are particularly useful for infrastructure-related workloads that need to run on every node, such as monitoring agents, log collectors, and networking components.

Key Features of DaemonSets

• One Pod Per Node: Ensures exactly one instance of the pod runs on selected nodes
• Node Coverage: Automatically deploys on new nodes as they join the cluster
• Node Selection: Can be configured to run only on specific nodes using node selectors, taints, and tolerations

When to Use DaemonSets

• Cluster storage daemons (Ceph, GlusterFS)
• Log collection agents (Fluentd, Filebeat)
• Monitoring agents (Prometheus Node Exporter)
• Network plugins that require a component on every node

Example DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

In this example:

• The DaemonSet deploys Fluentd for log collection on every node
• It has a toleration to run even on master nodes (normally tainted to prevent workloads)
• It mounts host paths to collect logs from the node

DaemonSets vs Other Workloads

AKS Considerations for DaemonSets

When using DaemonSets in AKS:

• Some AKS components already run as DaemonSets (kube-proxy, Azure CNI, etc.)
• Node-specific services like monitoring and logging work well as DaemonSets
• Be mindful of resource consumption when deploying custom DaemonSets (they run on every node)
• Consider using node selectors or node affinity to limit DaemonSets to specific node pools

Advanced DaemonSet Patterns

Running on Specific Nodes

You can target DaemonSets to specific nodes using various selection mechanisms:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      nodeSelector:
        nodepool: workload  # Only run on nodes in the 'workload' pool
      containers:
      - name: monitoring-agent
        image: monitoring-agent:1.0

DaemonSet Update Strategies

DaemonSets support two update strategies that control how pods are replaced during updates:

For the RollingUpdate strategy, you can configure:

• maxUnavailable: Maximum number/percentage of pods that can be unavailable during the update
• minReadySeconds: Minimum time a pod should be ready before being considered available

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

Common DaemonSet Use Cases in AKS

AKS environments typically use DaemonSets for these infrastructure components:

Further Reading and Resources

• Kubernetes DaemonSet Documentation