Service Discovery From Within the Kubernetes Cluster

It is probably not common to write your own code to perform service discovery from within the Kubernetes cluster. It is better to delegate that responsibility to an ingress controller or a load balancer. However, ever the adventurer, I stumbled onto the Java Kubernetes Client.

The project was an investigation into using Spinnaker as a CI/CD tool for a new micro-services architecture. My adventures of getting Spinnaker to run on Minikube have been documented as a three-article series on DZone and can be accessed from my profile page. 

Once I had Spinnaker up and running, I had to come up with something to deploy to impress my boss. I decided to try my hand at GraphQL. Coding the two micro-services was fun, and GraphQL exceeded my expectations in its ability to provide data at the correct granularity. However, one aspect tested my patience exceedingly: how would the Book microservice know where to find the Author microservice in the unpredictable world of container-managed service orchestration? As I did not want to install a load-balancer or external service discoverer just for this, I decided to try my hand at internal service discovery.

The project wiki describes the client as follows: "Kubernetes Java Client is a Java library to operate the Kubernetes cluster by accessing Kubernetes API. " I still have to investigate whether the API lives up to the promise, but it solved the task at hand: 

    public String determineK8sRootFromHttpTillPort(String svcName) throws IOException, ApiException {
        String result = null;
        System.out.println("Determining roor for " + svcName);
        ApiClient client = Config.defaultClient();
        Configuration.setDefaultApiClient(client);
        CoreV1Api api = new CoreV1Api(client);
        V1ServiceList listNamespacedService =
                api.listNamespacedService(
                        DEFAULT_NAME_SPACE,
                        null,
                        null,
                        null,
                        null,
                        null, // TODO use this for selections
                        Integer.MAX_VALUE,
                        null,
                        TIME_OUT_VALUE,
                        Boolean.FALSE);
        for (V1Service service : listNamespacedService.getItems()) {
            if (service.getMetadata().getName().equals(svcName)) {
                V1ServiceSpec spec = service.getSpec();
                String portNr = "#";

                result = "http://" + spec.getClusterIP() + ":" + spec.getPorts().get(0).getPort();
                System.out.println("Root determined " + result);
            }
        }

        return result;
    }

This is the Java equivalent of "kubectl get svc". Towards the bottom, one can see how the result is mined and combined towards the URL of the Kubernetes service, encapsulating all of the Author service pods behind it. The Book service can now determine its Author in the normal fashion. 

I would be very surprised if the Java Kubernetes Client does not live up to the promise quoted above.