我需要我的Go应用程序来监控Kubernetes集群中的一些资源,并对它们的变化做出React。基于大量的文章和示例,我似乎找到了几种方法来做到这一点;然而,我对Kubernetes相对较新,并且它们的描述对我来说太复杂了,以至于我仍然无法掌握它们之间的区别-因此,要知道使用哪一个,所以我不会得到一些意想不到的行为......具体来说:
watch.Interface.ResultChan()
-(通过例如rest.Request.Watch()
获取)-这似乎已经让我通过提供Added
/Modified
/Deleted
事件来对资源发生的更改做出React;cache.NewInformer()
-当我实现一个cache.ResourceEventHandler
时,我可以将它作为最后一个参数传入:
cache.NewInformer(
cache.NewListWatchFromClient(clientset.Batch().RESTClient(), "jobs", ...),
&batchv1.Job{},
0,
myHandler)
- 然后,
myHandler
对象将接收OnAdd()
/OnUpdate()
/OnDelete()
调用。
对我来说,这似乎或多或少相当于我在上面的(1.)中得到的ResultChan
;一个区别是,显然现在我得到的是资源的“之前”状态作为奖励,而使用ResultChan
,我只能得到它的“之后”状态。
此外,IIUC,这实际上是建立在上面提到的watch.Interface
(通过NewListWatchFromClient
)-所以我猜它带来了一些价值,和/或修复了一些(什么?)原始watch.Interface
的缺陷?
cache.NewSharedInformer()
和cache.NewSharedIndexInformer()
-(哇,现在 * 那些 * 是一个口...)我试图通过godocs挖掘,但我觉得完全超载的术语,我不明白,这样我似乎无法掌握微妙的(?)之间的差异“常规”NewInformer
与NewSharedInformer
与NewSharedIndexInformer
...😞
有没有人可以帮助我理解Kubernetes client-go包中上述API之间的差异?
1条答案
按热度按时间rkue9o1l1#
这些方法在抽象级别上有所不同。如果更高级别的抽象适合您的需要,您应该使用它,因为许多较低级别的问题可以为您解决。
Informers是比 watch 更高级别的抽象,还包括 * lister *。在大多数用例中,您应该使用任何类型的Informer,而不是较低级别的抽象。Informer内部由 watcher、lister 和 in-memory cache 组成。
SharedInformers在您的Informers之间共享与API服务器的连接和其他资源。
SharedIndexInformers为您的数据缓存添加索引,以备您处理较大的数据集。
建议使用SharedInformers,不要使用较低级别的抽象,从同一个SharedInformerFactory示例化新的SharedInformes,Kubernetes Handbook example中有一个例子