Kubernetes client-go：watch.Interface vs. cache.NewInformer vs. cache.NewSharedIndexInformer？

Question

我需要我的 Go 应用程序来监控Kubernetes 集群中的一些资源并对它们的变化做出反应。基于大量的文章和例子，我似乎找到了一些方法；然而，我对 Kubernetes 比较陌生，而且它们的描述对我来说太复杂了，以至于我仍然无法理解它们之间的区别——因此，知道使用哪个，所以我不要出现一些意外的行为......具体来说：

1. watch.Interface.ResultChan()- （通过收购如rest.Request.Watch()） -这似乎已经让我对变化做出反应发生在一个资源，通过提供Added/ Modified/Deleted事件;

2. cache.NewInformer()— 当我实现 a 时cache.ResourceEventHandler，我可以将它作为最后一个参数传递：

   cache.NewInformer(
           cache.NewListWatchFromClient(clientset.Batch().RESTClient(), "jobs", ...),
           &batchv1.Job{},
           0,
           myHandler)
   

   -那么，该myHandler对象将接收OnAdd()/ OnUpdate()/OnDelete()电话。

   对我来说，这似乎或多或少相当于ResultChan我在上面的 (1.) 中得到的；一个区别是，显然现在我得到了资源的“之前”状态作为奖励，而ResultChan我只会得到它的“之后”状态。

   此外，IIUC，这实际上是以某种方式建立在watch.Interface上面提到的（通过NewListWatchFromClient）的基础上——所以我想它带来了一些价值，和/或修复了原始watch.Interface?

3. cache.NewSharedInformer()并且cache.NewSharedIndexInformer()—— _{^{（呃，哇，现在这些都是一口……）}}我试图挖掘 godocs，但我觉得我不懂的术语完全超负荷，以至于我似乎无法掌握微妙之处（？）“常规”之间的差异NewInformer与NewSharedInformer对NewSharedIndexInformer...

有人可以帮助我理解Kubernetes client-go 包中上述 API 之间的区别吗？

Answer 1

这些方法在抽象级别上有所不同。如果更高级别的抽象适合您的需要，您应该使用它，因为许多较低级别的问题已为您解决。

Informers是比watch更高的抽象级别，它还包括listers。在大多数用例中，您应该使用任何类型的 Informer 而不是较低级别的抽象。Informer 内部由watcher、lister和in-memory cache 组成。

SharedInformers在您的 Informers 之间共享与 API 服务器和其他资源的连接。

SharedIndexInformers将索引添加到您的数据缓存，以防您使用更大的数据集。

建议使用 SharedInformers 而不是较低级别的抽象。从同一个SharedInformerFactory实例化新的SharedInformes。Kubernetes 手册示例中有一个示例

informerFactory := informers.NewSharedInformerFactory(clientset, time.Second*30)

podInformer := informerFactory.Core().V1().Pods()
serviceInformer := informerFactory.Core().V1().Services()

podInformer.Informer().AddEventHandler(
    // add your event handling 
)

// add event handling for serviceInformer

informerFactory.Start(wait.NeverStop)
informerFactory.WaitForCacheSync(wait.NeverStop)