kubernetes/kubernetes · error
couldn't get list of nodes when syncing daemon set %#v: %v
Error message
couldn't get list of nodes when syncing daemon set %#v: %v
What it means
Returned by syncDaemonSet when dsc.nodeLister.List(labels.Everything()) fails. The node list is required for every DS reconcile (to compute desired placement and to iterate nodes). When it fails the sync aborts for that DS. Node-Not-Found is not special-cased here -- any list error bubbles up.
Source
Thrown at pkg/controller/daemon/daemon_controller.go:1323
).Inc()
}
return err
}
ds, err := dsc.dsLister.DaemonSets(namespace).Get(name)
if apierrors.IsNotFound(err) {
logger.V(3).Info("Daemon set has been deleted", "daemonset", key)
dsc.expectations.DeleteExpectations(logger, key)
dsc.consistencyStore.Clear(dsNamespacedName, "")
return nil
}
if err != nil {
return fmt.Errorf("unable to retrieve ds %v from store: %v", key, err)
}
nodeList, err := dsc.nodeLister.List(labels.Everything())
if err != nil {
return fmt.Errorf("couldn't get list of nodes when syncing daemon set %#v: %v", ds, err)
}
everything := metav1.LabelSelector{}
if reflect.DeepEqual(ds.Spec.Selector, &everything) {
dsc.eventRecorder.Eventf(ds, v1.EventTypeWarning, SelectingAllReason, "This daemon set is selecting all pods. A non-empty selector is required.")
return nil
}
// Don't process a daemon set until all its creations and deletions have been processed.
// For example if daemon set foo asked for 3 new daemon pods in the previous call to manage,
// then we do not want to call manage on foo until the daemon pods have been created.
dsKey, err := controller.KeyFunc(ds)
if err != nil {
return fmt.Errorf("couldn't get key for object %#v: %v", ds, err)
}
// If the DaemonSet is being deleted (either by foreground deletion or
// orphan deletion), we cannot be sure if the DaemonSet history objectsView on GitHub (pinned to b882c60b40)
Solutions
- Verify the node informer is synced (check kube-controller-manager readiness/liveness).
- Scale/check kube-controller-manager memory if the cluster has many nodes.
- If flooding all DSs, restart the controller-manager to rebuild caches.
- Transient at startup -- suppress alert noise during the first minutes after a controller restart.
Defensive patterns
Strategy: retry
Validate before calling
// Confirm the node informer has synced:
// if !dsc.nodeListerSynced() { /* wait; node list will be unreliable */ } Try / catch
// nodeList, err := dsc.nodeLister.List(labels.Everything())
// if err != nil { return fmt.Errorf("...: %v", err) } // requeue retries Prevention
- Ensure controller-manager readiness gate covers node informer sync.
- Size controller-manager memory for the node count.
- Expect transient flooding at startup; alert after the warm-up window.
When it happens
Trigger: The node informer's cache returns an error on full list; cache not synced at controller start; indexer corruption. Triggered on every DS sync, so this tends to flood logs for every DS when it occurs.
Common situations: kube-controller-manager starting up before node informer sync completes; very large clusters where the node cache is slow to hydrate; memory pressure on the controller manager causing cache faults.
Related errors
- error getting node %s: %w
- unable to retrieve ds %v from store: %v
- error listing daemon sets: %w
- error getting pods by node name: %w
- couldn't get node for nodeName %q: %v
AI-assisted analysis of kubernetes/kubernetes@b882c60b40 (2026-08-07).
Data as JSON: /api/errors/7364d5a83aeef7b4.
Report an issue: GitHub.