-
Notifications
You must be signed in to change notification settings - Fork 98
Introduce DefaultPrepUnprepRateLimiter (less aggressive) #656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,7 +20,9 @@ import ( | |
| "context" | ||
| "fmt" | ||
| "sync" | ||
| "time" | ||
|
|
||
| "golang.org/x/time/rate" | ||
| "k8s.io/apimachinery/pkg/runtime" | ||
| "k8s.io/client-go/util/workqueue" | ||
| "k8s.io/klog/v2" | ||
|
|
@@ -38,6 +40,24 @@ type WorkItem struct { | |
| Callback func(ctx context.Context, obj any) error | ||
| } | ||
|
|
||
| // Return composite rate limiter that combines both per-item exponential backoff | ||
| // and an overall token bucket rate-limiting strategy. It calculates the | ||
| // exponential backoff for the individual item (based on its personal retry | ||
| // history), checks the global rate against the token bucket, and picks the | ||
| // longest delay from either strategy, ensuring that both per-item and overall | ||
| // queue health are respected. | ||
| func DefaultPrepUnprepRateLimiter() workqueue.TypedRateLimiter[any] { | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Review feedback was
(from #633 (comment)) This is not necessarily for all retrying work in the kubelet plugins. This is supposed to be specific for retrying Prepare and Unprepare requests. The context-specific choice of retrying methodology is kinda the point of this patch, and hence I'd like the name to also reflect that. So, I am not unhappy with the name In the future, we may have different retrying parameters for e.g. each of these:
The retrying parameters will become highly relevant when we measure overall duration/latencies, and generally one-size-fits-all doesn't quite work. (I really like the idea of tuning time constants over time! in software -- it's a sign of growing maturity and clearer goals) |
||
| return workqueue.NewTypedMaxOfRateLimiter( | ||
| // This is a per-item exponential backoff limiter. Each time an item | ||
| // fails and is retried, the delay grows exponentially starting from the | ||
| // lower value up to the upper bound. | ||
| workqueue.NewTypedItemExponentialFailureRateLimiter[any](250*time.Millisecond, 3000*time.Second), | ||
| // Global (not per-item) rate limiter. Allows up to 5 retries per | ||
| // second, with bursts of up to 10. | ||
| &workqueue.TypedBucketRateLimiter[any]{Limiter: rate.NewLimiter(rate.Limit(5), 10)}, | ||
| ) | ||
| } | ||
|
|
||
| func DefaultControllerRateLimiter() workqueue.TypedRateLimiter[any] { | ||
| return workqueue.DefaultTypedControllerRateLimiter[any]() | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked this question here also for my future self. I probably know everything to answer that. Some thoughts:
If this plugin operates on multiple retry loops concurrently (which it does), it could make sense to use a a global retry rate limit as some kind of upper bound in case things go unexpectedly crazy. Currently, this is a noop: