Yes, I totally agree with you, so we can consider the first option first.
Best Wishes！ CalvinKirs, Apache DolphinScheduler PMC On 06/22/2021 19:11，Shiwen Cheng<[email protected]> wrote： The 1st solution will be better. As for whether to use Service[1], we need further research. Take dubbo-go as an example. Because some features of Service do not meet its requirements, it is not implemented based on Service[1]. We can compare various mainstream implementation solutions. As for 2nd solution, it lacks watch ability and it will put pressure on dns. At the same time, users may use custom dns, which will bring potential incompatibility risks, and we need to do extra work to maintain [1]https://kubernetes.io/docs/concepts/services-networking/service/ Shiwen Cheng / 程世文 DolphinScheduler Committer Mobile: (+86)15201523580 E-mail: [email protected] wenjun ruan <[email protected]> 于2021年6月16日周三 下午10:56写道： Thanks, I will try. Thanks, Wenjun Ruan CalvinKirs <[email protected]> 于2021年6月16日周三 上午11:08写道： Here are some official documents that can be viewed [1]https://kubernetes.io/docs/concepts/services-networking/service/ Best Wishes！ CalvinKirs, Apache DolphinScheduler PMC On 06/16/2021 10:58，CalvinKirs<[email protected]> wrote： Hi, wenjun Yes, our registration data is currently controlled, so there won't be much of a problem here. Would you like to improve this program? Best Wishes！ CalvinKirs, Apache DolphinScheduler PMC On 06/15/2021 22:18，wenjun ruan<[email protected]> wrote： I think the first plan is great. It seems that both Istio and dubbo-go use API-Server to implement the registry center in Kubernetes. The request invocation is transparent to the user, and the api is not exposed to users. I think the risk is acceptable. Thanks, Wenjun Ruan CalvinKirs <[email protected]> 于2021年6月10日周四 下午5:31写道： Kubernetes is the world's most popular container service platform. In a Kubernetes cluster, DolphinScheduler applications are often deployed in a way that requires a third-party registry for node registration. But if we can use Kubernetes to implement node registration, we can reduce the cost of operation and maintenance greatly. Therefore, I would like to discuss this FUTURE together. There are two ways to interface with Kubernetes, one is to get information in the form of Kubernetes API Client, the core of Kubernetes control plane is API Server, which provides HTTP API for users, different parts of the cluster and external components of the cluster to communicate with each other. For DolphinScheduler, it is possible to communicate with the Kubernetes control plane by using the Kubernetes API Client, It is important to note that having the application itself interact directly with the Kubernetes management platform API is inherently a security risk that could bring down the entire Kubernetes cluster if not properly configured. Kubernetes DNS is a mechanism provided by Kubernetes to obtain Kubernetes Service information by means of DNS queries, and the node information of the service can be obtained by ordinary DNS requests. This solution avoids direct interaction with Kubernetes APIs and security issues, but since DNS does not have a notification mechanism like API Watch, it can only use polling to determine service changes, and there is still a certain amount of DNS network query pressure in the cluster when there is no application change. What other ideas, or better points, does everyone have about this? Best Wishes！ CalvinKirs, Apache DolphinScheduler PMC
