DaemonSet
Does ZopNight manage DaemonSet?
DaemonSets run 1 pod on every eligible node, so their requests are overhead multiplied by cluster size. A 200-millicore agent on 50 nodes reserves 10 full cores. ZopNight tracks desired, current, ready, and updated pod counts, and flags under-scheduling only when 2 or more pods, or over 10 percent, are missing.
Rules that fire on DaemonSet
A DaemonSet runs one pod on every eligible node, the standard delivery mechanism for log shippers, monitoring agents, and CNI components. Its cost is a per-node overhead, which means it scales with the cluster whether or not anyone looks at it.
A request that multiplies by node count
A 200-millicore, 256 MiB agent looks harmless in isolation; on 50 nodes it reserves 10 cores and 12.5 GiB before any application pod schedules. Because the multiplier is the cluster itself, DaemonSet requests deserve tighter review than any single workload’s, and discovery captures the full container detail (requests, limits, images, probes, privileged and host-network flags) to make that review concrete. The desired pod count is stored as the resource’s unit count, so the multiplier is visible in the inventory.
Desired versus ready, with rollout awareness built in
Discovery records desiredNumberScheduled, currentNumberScheduled, numberReady, numberAvailable, and updatedNumberScheduled. Status derives from the first and third: zero ready with a positive desired count maps to stopped, ready below desired maps to degraded. The updated count exists specifically so a rolling update, which proceeds node by node and is transiently under-ready by design, is recognized as in progress rather than broken.
When under-scheduling is signal instead of noise
Single-node gaps are routine: taints, node selectors, and cordons all legitimately keep a DaemonSet off individual machines. The DaemonSet Not Fully Scheduled rule (RC-1716 / RC-1816 / RC-1916, high severity) therefore only fires when at least 2 pods are missing or more than 10 percent of the desired count is not ready, and it skips entirely while updatedNumberScheduled shows a rollout mid-flight.
kubectl get daemonsets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,DESIRED:.status.desiredNumberScheduled,READY:.status.numberReady,UPDATED:.status.updatedNumberScheduledThe agent stack is a fixed tax, so price it once
Most clusters run 3 to 6 DaemonSets from their observability and security vendors. Summing their requests and multiplying by node count gives the standing tax every new node pays; it is one of the few Kubernetes numbers that gets worse automatically as you grow, and one of the easiest to trim once written down.