Differentiate requeued object updates from normal reconcilations #2247
-
Hello, we are requeuing our objects so that they are reconciled in a time interval, e.g:
All of the above works flawlessly, the objects are requeued after 300 seconds however, they also run through our entire reconcile code and thus perform client.Update() on our subresources. Usually, in k8s when you use the Is there a way to figure out if the object is "unchanged" by k8s when using client.Update() function? The object is only returning an error, or is there any way for me to figure out if the route object that is being reconciled is a requeued object? Background is, that I do not want to log "subresource has been updated" each time if the reconcile is just a requeued object. If I were able to see if the object was reconciled by a requeue, or if the client.Update() returned an "unchanged" I'd be able to not log "subresource has been updated". I just want to differentiate updates triggered by a requeued object, and a real reconcile that is triggered by someone applying our crd. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hello, For the use case you've described, the most efficient approach would be to leverage Kubernetes' capability to watch resources. This way, instead of reconciling at fixed intervals, you'll only reconcile when there's an actual change to the observed resource. By watching the resources, you can ensure that your reconcile loop is triggered only when there are genuine updates to the resources. This approach eliminates the issue of having to differentiate between a requeued reconcile and a real one, as you'll only be reacting to actual changes. For more details on how to set this up, refer to: Watching Resources. I hope this addresses your concern. Let me know if you have any further questions. Best regards. Closing this one as answered feel free to re-open if you see that is required |
Beta Was this translation helpful? Give feedback.
Hello,
For the use case you've described, the most efficient approach would be to leverage Kubernetes' capability to watch resources. This way, instead of reconciling at fixed intervals, you'll only reconcile when there's an actual change to the observed resource.
By watching the resources, you can ensure that your reconcile loop is triggered only when there are genuine updates to the resources. This approach eliminates the issue of having to differentiate between a requeued reconcile and a real one, as you'll only be reacting to actual changes.
For more details on how to set this up, refer to: Watching Resources.
I hope this addresses your concern. Let me know if you have any further que…