Kubernetes DaemonSet Availability Management

Kubernetes DaemonSet Availability Management is the set of practices and mechanisms for ensuring that a DaemonSet's node-level function remains sufficiently present across a cluster during both routine operation and disruptive events — node maintenance, voluntary evictions, rolling updates — so that the daemon's absence on any given node is bounded, expected, and does not silently compound into a larger gap in coverage. Availability for a DaemonSet has a distinctive shape compared to availability for a Deployment: there is no single "percentage of desired replicas" metric that captures user-facing impact in the same way, since each DaemonSet Pod serves a specific node rather than contributing interchangeably to a shared capacity pool.

Because many daemon workloads are themselves infrastructure that other systems depend on continuously (a CNI plugin, a service mesh node agent), availability management for DaemonSets is as much about protecting the workloads that depend on the daemon as it is about the daemon itself.

Readiness and Liveness Probing

Readiness Gates Rolling Updates

A DaemonSet Pod's readiness probe is the primary signal the rolling update mechanism uses to decide when it is safe to proceed to updating the next node; a daemon without a meaningful readiness probe effectively removes the update process's ability to detect a bad rollout before it spreads further.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

Liveness Probing for Self-Healing

A liveness probe causes the kubelet to restart a daemon container that has become unresponsive, restoring availability on that specific node without requiring the DaemonSet controller to intervene at all — this is the first line of defense against a hung or deadlocked daemon process, distinct from the controller-level mechanisms that handle node eligibility and rollout progression.

Protecting Availability During Node Disruption

Voluntary Disruption and PodDisruptionBudget

DaemonSet Pods are, by Kubernetes convention, excluded from PodDisruptionBudget accounting and from the eviction API's normal voluntary-disruption checks, since a DaemonSet Pod cannot be rescheduled elsewhere the way an evicted Deployment Pod can — evicting it would simply remove the daemon from that node until it becomes eligible again, which most cluster tooling avoids doing casually as a matter of course.

Draining Nodes Without Losing Daemon Coverage

kubectl drain requires --ignore-daemonsets specifically because it otherwise refuses to proceed in the presence of daemon Pods it cannot safely evict; this flag does not remove the Pods, it simply permits the drain of other, evictable workloads to continue while daemon Pods remain running on the node throughout the maintenance operation.

kubectl drain node-worker-07 --ignore-daemonsets --delete-emptydir-data

Node Removal and Its Availability Impact

When a node is fully removed from the cluster (rather than merely drained), its daemon Pod is removed along with it — this is an expected, permanent reduction in that node's coverage, not a fault, and availability monitoring should treat node removal as a topology change rather than a daemon failure.

Monitoring Availability

Aggregate Coverage Ratio

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

Tracking this ratio over time, and alerting when it drops below a threshold for longer than an expected transient window (a brief dip during a rolling update is normal; a sustained drop is not), is the most direct availability signal available without needing to inspect individual Pods.

Per-Node Availability History

Because aggregate coverage can mask a single node's daemon being persistently unavailable while every other node reports healthy, availability monitoring that only watches the aggregate ratio can miss a chronic, single-node problem. Supplementing aggregate monitoring with periodic node-by-node coverage checks (comparing the full node list against Pods with a Ready status) catches localized availability gaps the aggregate signal would smooth over.

comm -23 <(kubectl get nodes -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n' | sort) \
         <(kubectl get pods -l app=codartium-log-agent --field-selector=status.phase=Running -o jsonpath='{.items[*].spec.nodeName}' | tr ' ' '\n' | sort)

Availability Considerations During Rollouts

Choosing a conservative maxUnavailable and a meaningful minReadySeconds during rolling updates is itself an availability management decision — it directly trades rollout speed for the size and duration of the coverage gap tolerated on any given node during the transition, which should be sized according to how tolerant downstream consumers of the daemon's function actually are to a brief absence.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-availability-example
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  minReadySeconds: 20
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
    spec:
      containers:
        - name: log-agent
          image: codartium/log-agent:latest
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 15