You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has become clear that Kubernetes leader election does not scale when Spegel is run in large clusters. Every Spegel pod will have to constantly communicate with the API server to contend over being the leader or update leader timestamp. It does not seem like leader election was intended to be used by a daemonsets, which is understandable.
The new solution should use a headless service to find other Spegel peers. To make sure that the same peers are connected to we will sort the list of IPs found, and select the top n records to connect to. This should remove any risk of a split network where peers create two separate clusters.
It turns out that it is possible to connect to a libp2p peer without knowing its ID by looking at the returned error. The Rust implementation of libp2p already allows this. While not optimal I do not see a way to distribute the public key as part of the DNS record at the moment.
The text was updated successfully, but these errors were encountered:
Describe the problem to be solved
It has become clear that Kubernetes leader election does not scale when Spegel is run in large clusters. Every Spegel pod will have to constantly communicate with the API server to contend over being the leader or update leader timestamp. It does not seem like leader election was intended to be used by a daemonsets, which is understandable.
This issue will fix #663 and may also solve #619
Proposed solution to the problem
The new solution should use a headless service to find other Spegel peers. To make sure that the same peers are connected to we will sort the list of IPs found, and select the top n records to connect to. This should remove any risk of a split network where peers create two separate clusters.
It turns out that it is possible to connect to a libp2p peer without knowing its ID by looking at the returned error. The Rust implementation of libp2p already allows this. While not optimal I do not see a way to distribute the public key as part of the DNS record at the moment.
The text was updated successfully, but these errors were encountered: