为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
TIDB-operator:1.1.10
TIDB:4.0.8
【问题描述】
hello,all.我在做一些调研，现在遇到一个问题，就是想知道一个tidb operator理论上可以管理多少组tidb集群或者是多少组tidb相关的pod？
我看到了这里，https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/deploy-multiple-tidb-operator
但缺少上述问题的一些指标，所以想咨询一下，thx
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
operator 是在 k8s 中为了管理有状态的服务的组件。
从理论上来说，通过 operator 管理的集群应该是没有极限的。
但是实际情况下，还是会有成本和性能的问题。
可以看一下 operator 的概念。
thx.
我这边有一些小的理解，如果有问题的话请随时纠正。
上面提到的理论上没有极限，是因为controller使用informer只对变化的内容进行对应的sync操作，而对无变化的不进行操作，所以理论上没有极限么？
性能的问题是指，如果由于大面积故障导致处理informer中变化增多，我看tidb operator的代码好像是用N个worker去消费informer生成消息队列。是在这种情况下会有性能问题么？
controller 的理解是对的。
抛开 tidb operator，我个人的理解，只要是 master - node/worker 这样的结构，就会产生 rpc 或者要心跳。那么这个集群环境肯定是有边界的。但可能这个边界足够大。
ok，我大概理解了，多谢多谢
hello,我今天试验了一下，试着用了operator informer来接收add，update，delete事件。现在有个比较迷惑的地方。。。我这边的程序和operator那边一直都在收到updatefunc的消息，我用kubectl get event看不到有啥事件在这段时间发生，能看到的就是resourceversion一直在变。两边设置的30s一次去resync informer，然后这个过程后会收到两三个update事件，我尝试在update里面提取出来了resourceversion，发现的确是这个变化了，其他的应该都没有变，这样的情况也会引起update事件么？感觉这样的话，tidb operator的性能可能会因为频繁的对所有tidb集群sync有影响。
也就是比较迷惑，在没有操作的情况下，是什么触发了update事件。。。按照频率的话，看着像是类似心跳之类的东西
https://github.com/pingcap/tidb-operator/issues/3080 We already have an issue to trace this, would you like to help debug this? 是在slack里的问题吗？
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。