CODEWITHSUNDEEP
kubernetesservice-discovery
John
John

Reputation: 565

Service Discovery In Kubernetes

I am running two services inside of a small cluster for testing purposes. I have an nginx ingress controller, and then Service A which can be curl'ed directly, and then service B which is called from Service A.

I am able to get the call and communication from ingress-> A -> B working properly, if in service A when looking up B, I make an http call to B as follows: http://{ServiceB.serviceName}/... This does not required me to specify a port so long as the external port for Service B is defined on port 80 in its service definition.

However if I change the port of the service definition for Service B from 80 to anything else, in order to use it in service A, I now have to change the url which I use to call service B to http://{Serviceb.serviceName}:{Serviceb.portNumber}/. Basically, I have to add the port number now as well when looking it up. This requires that in Service A, now i have to know not only the name of Service B, as it is defined in the service definition of Service B, but now I have to know also the port as well.

Is there a better way of doing this, or is this currently the only approach ?

Upvotes: 0

Views: 603

Answers (1)

mdaniel
mdaniel

Reputation: 33231

However if I change the port of the service definition for Service B from 80 to anything else

Well, given that each Service has its own ClusterIP and therefore its own non-conflicting port, there's no immediate reason one would change a Service port -- one would change the Pod port to which the Service port points. Beyond that, if the Service port is consuming a targetPort: some-name rather than targetPort: 1234, then one would be further exempted from changing the Service port, because the Pod could just change the containerPort of the named Pod port and downstream things are none the wiser.

That said, if it really is important to change the numeric port of the Service, and those ports are named correctly, then you can take advantage of the SRV record support provided by kube-dns to decouple the app from a hard-coded port number. However, using a SRV record makes building the URL a three-step process (lookup records, assemble URL, request URL), which introduces more application code as well as more opportunities for failure.

Upvotes: 2

Related Questions