I do not think APIServer as a registry is a good idea. In very large k8s cluster[such as 10,000 nodes as I see in my current company], the APIServer can not handle 5 list-all request in 1s from kubelet. If there are more requests from Application layer, it will panic or the app's request will be rejected.
Albumen Kevin <[email protected]> 于2021年5月8日周六 下午3:29写道： > Hi ecit.yande, > > Yep you are right. In this way, we can reduce the burden of k8s clusters. > > However, there is a question I think we should resolve first. That is why > we > use Kubernetes as a registry. In my mind, we try to adapt to Kubernetes > Native > Service and to adapt to Cloud Native instructions. That means Dubbo should > work as other Cloud Native instructions do. If we do not need to care about > this, why not directly use other registries, since we can sure that > Kubernetes > API server is not efficient enough like other registries. > > > Albumen > > > On Thu, Apr 29, 2021 at 12:02 PM 闫 强 <[email protected]> wrote: > > > Hi Albumen, > > In my option, provider interact with k8s is more stable than > > consumers. The premise of this conclusion is the number of providers is > > less than that of consumers. When provider do updates only the same > > application providers receive the notify not consumers. On the other > hand, > > a consumer application may need interact with many different providers, > > this further increases the burden of k8s clusters. > > > > 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用 > > > > 发件人: Albumen Kevin<mailto:[email protected]> > > 发送时间: 2021年4月29日 9:57 > > 收件人: [email protected]<mailto:[email protected]> > > 主题: Re: [Discuss] A new way for service discovery in k8s > > > > 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. > > > > > > > >
