Will refactoring cluster synchro part from in-tree to out-tree(pod) be better?

[qmloong]

ATT.

[Iceber]

Could you tell us more about in-tree and out-tree?

[qmloong]

Running a pod to do the work of the cluster-synchro part rather than a goroutine. I consider that as the number of pediacluster increases, the memory usage of the cluster synchro manager will grow up. If running a pod to do the syncing work, will the scalability of clusterpedia be better?

(Just a little idea

[Iceber]

When using the in-memory storage layer, we had to run the APIServer and
ClusterSynchroManager running in a pod, as they need to share memory

For other storage tiers, the default is to use different deployments to run them, and ClusterSynchroManager uses a leader election to run multiple replicas, and APIServer can be dynamically scaled according to demand

[Iceber]

The memory usage of ClusterSynchro is low when the specific storage layer implementation is not considered, because we modify the informer's cache store.

The default storage layer(internalstroage) consumes almost no memory, while the memory storage layer consumes memory.

[qmloong]

because we modify the informer's cache store.

OK, Thank you. I'll take a look at this change.