[Question] What is the recommended way to requeue with rate limiting?

[LeelaChacha]

Now that Result.Requeue is deprecated, is returning an error in the controller's Reconcile() method the only recommended way to requeue with rate limiting?

https://github.com/kubernetes-sigs/controller-runtime/blob/v0.21.0/pkg/reconcile/reconcile.go#L109-L122

[alvaroaleman]

Did you see this comment https://github.com/kubernetes-sigs/controller-runtime/blob/v0.21.0/pkg/reconcile/reconcile.go#L34-L39? Why do you want to do Exponential backoff in the first place?

[terinjokes]

Not OP, but we'd been using it to handle things such as controllerutil.AlreadyOwnedError without incrementing controller_runtime_reconcile_errors_total as this is a user error, not a controller error. We update conditions and send an event in the namespace, then have been happy with the built-in exponential backoff as the human loop is (comparatively) very slow. As we don't yet own the created resource, we can't rely on an event of it being deleted or modified to requeue after a reconcile.TerminalError either.

[alvaroaleman]

As we don't yet own the created resource, we can't rely on an event of it being deleted or modified to requeue after a reconcile.TerminalError either.

What keeps you from building a custom event handler to properly deal with this?

[terinjokes]

We're using the builder's .Owns to avoid reconciling every instance of the created type. Your recommendation is to reconcile all instances (that we're trying to avoid) to find instances we would like to own but don't?

[alvaroaleman]

We're using the builder's .Owns to avoid reconciling every instance of the created type. Your recommendation is to reconcile all instances (that we're trying to avoid) to find instances we would like to own but don't?

I don't have enough context from your project to be able to tell you how exactly you can infer that you would "like to own" something and if that entails you have to react to all events, but basically, yes.

For example and reference, all the upstream workload controllers react to pod events of a pod that either a) is owned by a workload of that type b) is unowned, as that may mean it needs adopting, e.G. here for the statefulset controller: https://github.com/kubernetes/kubernetes/blob/81affffa1b8d8079836f4cac713ea8d1b2bbf10f/pkg/controller/statefulset/stateful_set.go#L263

[terinjokes]

We would adopt it the next time the reconciler would run in that case (likewise with "examples/crd"). Would CR provide an event source if this is the recommended solution?

Is it possible to obtain a reference to a controller's rate limiter? That would allow us to give a RequeueAfter that retains the previous behavior.

[alvaroaleman]

We would adopt it the next time the reconciler would run in that case (likewise with "examples/crd"). Would CR provide an event source if this is the recommended solution?

CR can not reasonably provide eventhandlers for situations like this, as its very dependend on your business logic what should happen. CR provides helpers in the form of handler.EnqueueRequestsFromMapFunc and handler.Funcs (Depending on if the type of event matters) that make it very easy to write your own. You will find plenty of usage examples for these through github codesearch and can leverage LLMs if you need additional help, they are great at helping with standard functionality that one isn't familiar with yet.

[LeelaChacha]

Hi all, thanks for the detailed discussion so far!

To clarify our use case: we were previously using Result{Requeue: true, RequeueAfter: 0} as a way to trigger the default exponential backoff even when err == nil. This was particularly useful in scenarios where we wanted to retry reconciliation without incrementing controller_runtime_reconcile_errors_total, since this isn't really a controller failure.

Now that Result.Requeue is deprecated, is there truly no supported way to achieve exponential backoff unless we return an actual error from the Reconcile method?

I understand the point that returning an error is now the path that triggers rate limiting, but returning an error feels semantically wrong in cases where the controller is behaving correctly and just needs to retry due to some external/user condition.

Would love to know if there's a recommended alternative to preserve that pattern—or if returning an error is now the only way to achieve requeue-with-backoff behaviour.

[alvaroaleman]

@LeelaChacha could you answer the question asked here as to why you want to do this as opposed to repeating your question around how to do it?

[LeelaChacha]

Hi @alvaroaleman, thanks for following up.

To clarify: in our case, the decision to requeue is only made dynamically within the Reconcile() method, based on business logic. For example, the reconciliation completes successfully (no actual error), but due to some user-driven or external condition, we know we need to retry later — and we'd like that retry to respect exponential backoff.

Because this condition is only known at runtime, custom event handlers unfortunately don't help us here. There's no specific resource or event we can watch that would reliably indicate when to retry — we only discover that need after evaluating multiple stateful conditions during reconciliation.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale