Change:
toUpdate := ds.DeepCopy() var updateErr, getErr error <del> for i := 0; i < StatusUpdateRetries; i++ { </del> <ins> for i := 0; ; i++ { </ins> if updateObservedGen { toUpdate.Status.ObservedGeneration = ds.Generation }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Almost every update to a DaemonSet can lead to 2~3 error logs in kube-controller-manager even when the DaemonSet manages very few Pods, for example, there were 3 error logs when updating a daemonset in a small cluster of 2 Nodes. Other controllers like deployment don't have this issue when they manage much more Pods. After looking at DaemonSet controller code, it seems the retry logic in "storeDaemonSetStatus" was not implemented correctly. It never really retried and always made an useless GET call. DaemonSet controller should produce less error logs in normal case. Create or update a DaemonSet to trigger Pod recreation. Kubernetes version (use ): v1.20.4 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig apps /assign created to fix the retry logic.
Same problem with me. </brCould you explain why other controllers(like deployment controller) is not easy to get conflict when updating status? I think there are many in every controller.
the number of workers doesn't matter here as the workqueue guarantees that they will not process the same resource at the same time. The conflict comes from multiple successive processing of a resource because of the update delay of the resource's cache in . For example, when a DaemonSet manages 2 Pods and they are getting ready. first Pod is ready and triggers updating Daemonset, whose resourceVersion is in Lister. updates DaemonSet's ready count to 1 with resourceVersion set to and it succeeds. The resourceVersion in server becomes and the Informer/Lister hasn't received the update.

second Pod is ready and triggers updating Daemonset, whose resourceVersion is still in Lister. updates DaemonSet's ready count to 2 with resourceVersion set to and it fails with the "the object has been modified" error. To avoid this error, retry is the most straightforward way but it is implemented differently in controllers. In deployment controller, it actually has the same conflict but it only logs the error with so normally you don't see it, and it requeues the resource and re-processes it upon conflict. DaemonSet controller and Replicaset controller retry directly when calling fails. However, the former made a mistake when checking the loop's boundary condition and it never retried. is fixing it.
Very clear explanation. Thanks.