songjian
2021 年3 月 24 日 07:51
1
为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
【问题描述】
对于informer的理解，查到的文档有点云里雾里了，现在我看到的是咱们应该使用的是shareinformer，如果tidb operator的controller和我的管控平台的服务都利用类似，tidbClusterInformer := deps.InformerFactory.Pingcap().V1alpha1().TidbClusters()这种方法生成informer的话，apiserver那边的变更会推送到同一个informer上？还是两个服务各自会有各自的informer，apiserver的变更会推送到各自的informer上？如果是1，两个服务是两个消费者，都会消费队列的内容？这样的话，应该是对operator的正常运行造成了破坏吧？
songjian
2021 年3 月 24 日 07:54
2
其实也是有点不太理解，informer，lister，和clientset在这里面都扮演了那些角色。。。。
songjian
2021 年3 月 25 日 09:00
3
有了点新的理解，informer这个东西应该是本地缓存一份实例状态的，然后lister是取这些缓存的。当发生k8s的addfunc，updatefunc，deletefunc的时候，会发送变更实例的namespace/cluster_name为key发送到一个k8s包提供的限速queue里，然后worker再去消费这个queue，拿到变更实例，去通过sync完成变更。。。operator应该是这个过程
关于operator的原理可以看看这里的博客 https://pingcap.com/blog-cn/tidb-operator-source-code-2/ .
在 TiDB Operator 上做管控平台, 是否可以考虑对 TiDB Operator 发请求, 通过创建 TiDBCluster CR 之类的操作完成.
songjian
2021 年3 月 26 日 03:31
5
thx.嗯，实际上管控就是创建，删除，上报状态之类的简单工作。其他的还是由operator来进行，感觉这样划分的话可以避免重复造轮子。
对, 需要在 operator 实现的功能可以参与到我们的社区一起来开发, 可以提一些 issue, 其他的工作在上层简单映射一下就好啦
songjian
2021 年3 月 26 日 03:36
7
ok，我也是有这个想法，感觉摸索这个的过程中，对operator大致的原理也快摸明白了，我再摸索一段时间，等差不多了看看能不能贡献点代码啥的
1 个赞
songjian
2021 年3 月 26 日 07:40
8
对了，我今天试验了一下，发现一直在收到updatefunc的消息，我用kubectl get event看不到有啥事件在这段时间发生，能看到的就是resourceversion一直在变。。。这个难道是因为我部署的tidbcluster有啥问题么？我看tidb-operator里的现象和我写的东西差不多。都是设置的30s一次去resync informer，然后这个过程中会受到两三个update事件，我尝试在update里面提取出来了resourceversion，发现的确是这个变化了，其他的应该都没有变，这样的情况也会引起update事件么？感觉这样的话，tidb operator的性能可能会因为频繁的sync有影响。
好像不一定会记录 event 吧, 频繁 sync 是一个已知问题, https://github.com/pingcap/tidb-operator/issues/3080 , 另外 repo 的 readme 下面有 slack channel, 欢迎来 slack 交流
