Hi, For Q1, as ServiceComb can work with or without k8s, it doesn't support to use DNS to resolve the instance. But you bring up an interesting topic here, with the DNS support, we could provide another kind of Load-balance here.
For Q2, ServiceComb Chassis can lookup the local network address for you. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, May 25, 2018 at 9:51 AM, Lance Ju <[email protected]> wrote: > Hi, gang! > I'm recently considering migrate my ServiceComb project into > Kubernetes. To minimize the complexity, I just first try the go-bmi > project( > https://github.com/ServiceComb-samples/go-bmi), which contains only 2 > services: the web-app service, which calls the calculator service. > > To let the web-app service know how to access calculator service, there > is an --advertiseAddress parameter in calculator's chassis.yaml, which is ' > 0.0.0.0:8080' by default in the local machine. But for k8s cluster, > services are usually accessed by DNS(commonly the service name plus the > namespace), but the go-chassis SDK would only allow CIDR format IP address > for the --advertiseAddress, then the calculator service cannot be > registered in the service center. > > So I got 2 questions: > 1. Does it make sense to allow only CIDR IP addresses when > registering services? Since the service center only store the 'accessible > address', which might also be a domain name or IPv6 address(or even Unix > socket under some particular situation). > 2. If I'm running ServiceComb projects under bare metals or VMs, should > I first know which address of the current service, then config it in > chassis.yaml? Or is it possible to let the chassis detect the address, > automatically? > > Looking forward to your replies. >
