Kubernetes DaemonSet Status Management

Kubernetes DaemonSet Status Management is the practice of reading and interpreting the .status subresource of an apps/v1 DaemonSet to understand its current coverage, rollout progress, and health across the cluster, distinct from the desired state expressed in .spec. Because a DaemonSet's Pod count is derived dynamically from node membership rather than fixed by a replicas field, its status fields carry more interpretive weight than a Deployment's — they are the only place where the actual, current relationship between "eligible nodes" and "nodes with a healthy Pod" is recorded, and reading them correctly is essential to knowing whether a daemon is functioning as intended.

DaemonSet status is composed of several counters that together describe different facets of the same underlying question — how well is this daemon's coverage matching its intended scope right now — and no single field answers that question completely on its own.

Core Status Counters

desiredNumberScheduled

The number of nodes that should be running a Pod for this DaemonSet, according to its current scheduling constraints (nodeSelector, affinity, tolerations) evaluated against the current set of nodes in the cluster. This number changes automatically as nodes are added or removed, or as the DaemonSet's own scheduling constraints change.

currentNumberScheduled

The number of nodes that currently have at least one Pod running for this DaemonSet, regardless of whether that Pod is up to date with the latest template or fully ready yet.

numberReady

The number of nodes whose DaemonSet Pod is both running and passing its readiness probe. This is generally the most operationally meaningful counter for assessing whether the daemon's function is actually available, as opposed to merely scheduled.

numberMisscheduled

The number of nodes running a Pod for this DaemonSet that no longer satisfy its current scheduling constraints — typically the result of a nodeSelector or taint change made after Pods were already placed, signaling Pods the controller will remove on its next reconciliation.

updatedNumberScheduled

The number of nodes whose Pod matches the latest template revision, which climbs toward desiredNumberScheduled as a RollingUpdate progresses, or remains static under OnDelete until Pods are manually replaced.

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

Interpreting Combinations of Counters

Healthy Steady State

desiredNumberScheduled == currentNumberScheduled == numberReady == updatedNumberScheduled, with numberMisscheduled at zero, describes a fully healthy, fully rolled-out DaemonSet with no pending work and no coverage gaps.

Mid-Rollout State

During a RollingUpdate, it is normal and expected for updatedNumberScheduled to be less than desiredNumberScheduled temporarily, while numberReady may briefly dip below currentNumberScheduled as individual nodes' Pods are replaced and their readiness probes warm back up.

A Persistent Gap Signals a Problem

A sustained, non-transient gap between desiredNumberScheduled and numberReady — one that does not close on its own after a reasonable window — indicates either a scheduling problem (insufficient node capacity, a taint/toleration mismatch) or a runtime problem (crash-looping containers, failing readiness probes) on the affected nodes, and warrants node-by-node investigation.

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

Conditions

Kubernetes DaemonSets do not carry the same rich .status.conditions list that Deployments and Jobs use for high-level state (Available, Progressing, Complete); most of a DaemonSet's operational state is expressed through the numeric counters above rather than typed conditions, making direct counter comparison the primary tool for automation rather than condition-based polling as with other controllers.

Building Monitoring Around Status

A Simple Health Check

#!/usr/bin/env bash
DESIRED=$(kubectl get daemonset codartium-log-agent -o jsonpath='{.status.desiredNumberScheduled}')
READY=$(kubectl get daemonset codartium-log-agent -o jsonpath='{.status.numberReady}')
if [ "$DESIRED" != "$READY" ]; then
  echo "Coverage gap: $READY/$DESIRED nodes ready"
  exit 1
fi
echo "Full coverage: $READY/$DESIRED"

Cluster-Wide Daemon Health Overview

kubectl get daemonsets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,DESIRED:.status.desiredNumberScheduled,READY:.status.numberReady,UPDATED:.status.updatedNumberScheduled

A single query across all namespaces gives a quick, cluster-wide snapshot of every daemon's coverage and rollout state, which is typically the first command run when investigating a suspected infrastructure-wide issue that might trace back to a daemon problem.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-status-example
spec:
  selector:
    matchLabels:
      app: codartium-node-agent
  template:
    metadata:
      labels:
        app: codartium-node-agent
    spec:
      containers:
        - name: agent
          image: codartium/node-agent:latest
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080