英文:
Requeue a kubernetes event in a non-blocking reconcile loop
问题
我们有一个 Kubernetes 集群，在自定义事件触发时会触发一次调谐（reconcile）操作。
使用以下格式用 Golang 实现：
type reconciler struct {}
func (reconciler) Reconcile(ctx context.Context, o reconcile.Request) (reconcile.Result, error) {
// 在这里实现读取和写入对象的业务逻辑
return reconcile.Result{}, nil
}
我们已经确定了当自定义事件过多时，调谐逻辑可能存在瓶颈。因此，代码已更新为具有非阻塞的调谐逻辑。
示例：
type reconciler struct {}
func (reconciler) Reconcile(ctx context.Context, o reconcile.Request) (reconcile.Result, error) {
go func() {
// 在这里实现读取和写入对象的业务逻辑
}()
return reconcile.Result{}, nil
}
然而，在某些情况下，非阻塞的 Go 协程可能会返回：
return ctrl.Result{Requeue: true}, nil
或者
return ctrl.Result{RequeueAfter: someTime}, nil
在这种情况下，我们应该如何将这些事件重新排队到调谐循环中，因为返回语句不会返回给调用者的 Reconcile() 函数。
英文:
We have a kubernetes cluster, where a reconcile is triggered in response to a custom event.
Implemented in Golang using the following format:
type reconciler struct {}
func (reconciler) Reconcile(ctx context.Context, o reconcile.Request) (reconcile.Result, error) {
// Implement business logic of reading and writing objects here
return reconcile.Result{}, nil
}
We have identified possible bottlenecks in the reconcile logic when the custom events are too many. So, the code has been updated to have a non-blocking reconcile logic.
Example:
type reconciler struct {}
func (reconciler) Reconcile(ctx context.Context, o reconcile.Request) (reconcile.Result, error) {
go func() {
// Implement business logic of reading and writing objects here
}()
return reconcile.Result{}, nil
}
However, there are some places where the non-blocking go routine may return
return ctrl.Result{Requeue: true}, nil
or
return ctrl.Result{RequeueAfter: someTime}, nil
How could we requeue such events to the reconcile loop in such scenarios, since the return would not return to the caller Reconcile()
答案1
得分: 3
我认为更好的方法是使用并发调和，允许在处理一个缓慢的调和请求时处理其他请求。这样，调和请求队列就不会被阻塞，而且空闲的Go协程成本相对较低，所以不会对性能产生太大影响。
可以查看controller-runtime中的MaxConcurrentReconciles：
https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller
英文:
I think a better approach would be to use concurrent reconciles allowing other requests to be handled while a single reconcile request is slow to handle. This way the reconcile request queue won't be blocked, and idle go routines are fairly cheap so it should not affect your performance all that much.
Check out the MaxConcurrentReconciles in controller-runtime:
https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论