自定义控制器是否应该在缓存同步之前响应 addfunc 事件处理程序？这种做法合适吗？

最近发现不少小伙伴都对Golang很感兴趣，所以今天继续给大家介绍Golang相关的知识，本文《自定义控制器是否应该在缓存同步之前响应 addfunc 事件处理程序？这种做法合适吗？》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

下面是我的片段

factory := informers.newfilteredsharedinformerfactory(clientset, 0, "", func(o *metav1.listoptions) {
    o.labelselector = "node-role.kubernetes.io/master="
})

nodeinformer := factory.core().v1().nodes().informer()

i.lister = factory.core().v1().nodes().lister()

nodeinformer.addeventhandler(
    cache.resourceeventhandlerfuncs{
        addfunc: func(obj interface{}) {
            i.updateips()
        },
        updatefunc: func(oldobj, newobj interface{}) {
            i.updateips()
        },
        deletefunc: func(obj interface{}) {
            i.updateips()
        },
    })

factory.start(ctx.done())

if !cache.waitforcachesync(ctx.done(), nodeinformer.hassynced) {
    runtime.handleerror(fmt.errorf("timed out waiting for caches to sync"))
    return
}

完整代码位于：https://github.com/tweakmy/fotofona/blob/master/nodeinformer.go

这是我运行单元测试时的结果：

$ go test -v -run TestInformer
   === RUN   TestInformer
   Update ip host [10.0.0.1]
   cache is synced
   --- PASS: TestInformer (3.10s)

这是预期的行为吗？ 如何在缓存同步后将其列出并在缓存同步后对事件处理程序做出反应。

解决方案

您所看到的是标准行为。当您等待同步发生时，会收到通知并执行相应的通知处理程序。

您的代码与大多数使用 informer API 的代码不同，因为处理直接在通知处理程序中进行。这听起来像是基于边缘的行为，而 Kubernetes 鼓励基于级别的行为。

编写 Kubernetes 控制器时的典型模式（这是您应该做的）是让通知处理程序不执行任何操作，只是将对通知对象的引用（通常是命名空间名称）排队到工作队列中，并拥有一个工作线程池（如果您使用 go，则为 goroutine）提取此类引用，使用它们从 Informer 的缓存中检索整个对象，然后进行实际处理。因此，通常要做的就是在启动工作程序之前同步通知者的缓存，以便工作程序不会在缓存同步之前开始处理。明确地说，updateIPs() 不应在通知处理程序代码中执行，而应在工作人员主体中执行。

this page 有一个独立的常见模式示例。更准确地说，请参阅 this code 以获取典型通知处理程序的示例，请参阅 this code 以获取如何在启动工作线程时完成同步的示例。

到这里，我们也就讲完了《自定义控制器是否应该在缓存同步之前响应 addfunc 事件处理程序？这种做法合适吗？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！