Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Watch for Multi-Cluster Resources #452

Open
Iceber opened this issue Nov 9, 2022 · 1 comment
Open

Watch for Multi-Cluster Resources #452

Iceber opened this issue Nov 9, 2022 · 1 comment
Labels
kind/feature New feature

Comments

@Iceber
Copy link
Member

Iceber commented Nov 9, 2022

We want to gather information about what users want from Watch capabilities

The current user wants to get change events for resources in multiple clusters and needs to use informer to list-watch the resources in each cluster.
The disadvantages of this are also relatively obvious.

  • First, as the number of multi-cluster components increases, if each component lists-watches every member cluster, the number of watch long connections will become uncontrollable and will put unknown pressure on the member apiserver.
  • In addition, we also need to consider that when using the traditional informer, resources need to be cached into memory, and this time, with the expansion of the number of clusters, the memory consumption will also become huge, and with the increase of multiple cluster components again aggravate the memory pressure on the control plane.

Clusterpedia plans to provide a watch capability that allows users to sense changes in resources across multiple clusters using the same principle as Informer, replacing < N Informers > => < N Member KubeAPIServer > with <1 informer> => <1 Clusterpedia APIServer> to get resource change events across N member clusters.
This avoids uncontrollable pressure on the Member APIServer by connecting to the clusterpedia.

Note: Of course the delay of events may be higher compared to connecting directly to the Member KubeAPIServer, but the Informer itself can be seen as an ultimately consistent design

In addition, with the Watch capability, Clusterpedia will also consider providing a new Informer in the same way as the native one, but instead of caching all the data in memory, we will only keep the metadata for user filtering and go to Clusterpedia when the user needs to get the full resource.


We have implemented Watch capability in memory storage and hope to provide a generic solution to provide Watch capability for most of the storage layers.

If you feel that the Watch capabilities of multiple clusters would be useful to you, comment on your usage scenarios and suggestions to drive the design and development of Watch features

We can also discuss the Watch implementation in Implementations of Watch that can be used for most storage layers

@Iceber Iceber added the kind/feature New feature label Nov 9, 2022
@clusterpedia-bot
Copy link

Hi @Iceber,
Thanks for opening an issue!
We will look into it as soon as possible.

Details

Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the gh-ci-bot repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature
Projects
None yet
Development

No branches or pull requests

2 participants