What Update Strategies Are Available for DaemonSets?

Detailed Answer

Updating a DaemonSet affects every node in the cluster. A botched rollout can take down logging, monitoring, or networking on all nodes simultaneously. DaemonSets provide two update strategies to manage this risk.

RollingUpdate (Default)

The RollingUpdate strategy updates DaemonSet Pods node by node:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 0
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3.0
          volumeMounts:
            - name: varlog
              mountPath: /var/log
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

With maxUnavailable: 1 and maxSurge: 0 (default):

1. Terminate the old Pod on node-1
2. Wait for it to stop
3. Create the new Pod on node-1
4. Wait for it to be Ready
5. Move to node-2 and repeat

Zero-Downtime Updates

To avoid any gap in coverage, use maxSurge: 1 with maxUnavailable: 0:

updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

With maxSurge: 1 and maxUnavailable: 0:

1. Create the new Pod on node-1 (now two DaemonSet Pods exist temporarily)
2. Wait for the new Pod to be Ready
3. Terminate the old Pod on node-1
4. Move to node-2 and repeat

This ensures every node always has at least one healthy DaemonSet Pod.

Faster Rollouts

For large clusters where node-by-node updates are too slow, increase maxUnavailable:

updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: "25%"  # Update 25% of nodes simultaneously

You can use an absolute number or a percentage:

| Setting | 100-node cluster behavior | |---|---| | maxUnavailable: 1 | Updates 1 node at a time | | maxUnavailable: 10 | Updates 10 nodes simultaneously | | maxUnavailable: "10%" | Updates 10 nodes simultaneously | | maxUnavailable: "25%" | Updates 25 nodes simultaneously |

OnDelete Strategy

The OnDelete strategy does not automatically update Pods. You must manually delete each Pod, and the DaemonSet controller recreates it with the new spec:

updateStrategy:
  type: OnDelete

Usage:

# Update the DaemonSet image
kubectl set image daemonset/fluent-bit fluent-bit=fluent/fluent-bit:3.1 -n kube-system

# Pods still run the old image — verify
kubectl get pods -n kube-system -l app=fluent-bit -o jsonpath='{.items[0].spec.containers[0].image}'
# fluent/fluent-bit:3.0

# Manually update one node at a time
kubectl delete pod fluent-bit-abc12 -n kube-system
# New Pod is created with fluent-bit:3.1

When to Use Each Strategy

| Scenario | Strategy | Configuration | |---|---|---| | Standard infrastructure updates | RollingUpdate | maxUnavailable: 1 | | Zero-downtime requirement | RollingUpdate | maxUnavailable: 0, maxSurge: 1 | | Large cluster, fast rollout | RollingUpdate | maxUnavailable: "25%" | | Critical networking changes | OnDelete | Manual control | | CNI plugin updates | OnDelete | Prevents cluster-wide outage |

Monitoring a DaemonSet Rollout

# Watch rollout status
kubectl rollout status daemonset/fluent-bit -n kube-system

# Check rollout history
kubectl rollout history daemonset/fluent-bit -n kube-system

# Roll back to previous version
kubectl rollout undo daemonset/fluent-bit -n kube-system

Unlike StatefulSets, DaemonSets support kubectl rollout undo for quick rollbacks, similar to Deployments.