Support for fully qualified service name

[stampy88]

Hi,

I wanted to add support for fully qualified service names of the form:

<service>.<namespace>.svc.<base-cluster-domain-name>

So for example, alpaca.default.svc.cluster.local is the alpaca service in the default namespace.
Want to see if there was a good reason not to do this before putting a PR together.

Thanks!

[sercand]

When <base-cluster-domain-name> changes? Currently, kuberesolver has minimal Kubernetes client library to minimize code surface. If we add support for this, it needs to support all <base-cluster-domain-name> values, not just cluster.local. Also, kuberesolver doesn't use service IP to access pods, It gets the pod IP addresses from kubernetes API and gives it to gRPC.

[stampy88]

Hi @sercand, I am not suggesting that the <base-cluster-domain-name> should be used, only that it can be parsed to pick up the namespace and service name. The library would still use the GET api/v1/namespaces/{namespace}/endpoints/{name} as it does today. So the change would only be to know how to pull the namespace/service out of the fully qualified service name.

[sercand]

@stampy88 My concern is that, If we add support for alpaca.default.svc.cluster.local, people may assume that <base-cluster-domain-name> can be other values as well. We can add support for this by the way, but we should add documentation for this.

[stampy88]

OK, that sounds good. I'll get a PR going, including documentation, and you can give me your thoughts. Thanks!

[stampy88]

Here it is, @sercand: #39