Hi ecit.yande, Such a solution is likely to combine current Kubernetes and DNS registry solutions.
Benefit from Service Discovery model, registries which want to assimilate into Cloud Native instructions can work with it. This means we can simply write rarely information to the registry or even no need to write ( like the DNS registry ). For Kubernetes registry, providers just need to write its revision ( a MD5 string, used to point out the provider's version ), and consumers can use Kubernetes Native Service to perceive providers. For DNS registry, providers even no need to write anything to the registry, and consumers will establish connections to providers to fetch theirs revision. One thing needs to be sure is that a single provider cannot perceive other providers without using registry. So, it is not easy for a single provider to interact as a registry. If using registry to perceive others, was this necessary? What do you think? Albumen On Sun, Apr 25, 2021 at 1:16 PM 闫 强 <[email protected]> wrote: > Hi all, > > I will describe a new way for sevice discovery. I hope the experts will > point out where this scheme is feasible. > > General speaking, the provider can be registry, service discovery in > consumer can simple call provider method from k8s service just as meta > service. > > How can a provider become registry? > Provider can Interact with k8s, monitor endpoint changes. Doing so, the > interaction with k8s moving from consumer to provider.The interact with k8s > from application will be more stable. > > What happened when consumer call list provider method from k8s service? > The k8s service represents for cluster of provider and it will be > responsibility for loadbalance. >
