Service Visibility: Internal services exposed by nodeport instead of ClusterIP
Closed this issue · 3 comments
All services that are not specifically intended for external consumption are exposed as nodeports instead of clusterIP.
portfolio-service and stock-quote-service for instance are examples of services that should not be exposed via nodePort. (This might be good for testing, but not so good for example of service visibility.)
Yes, I agree. They originally were exposed via Ingress too, but I took that out a while ago. As you guessed, I left in the node ports to simplify testing. But yeah, really they shouldn't be exposed at all.
Note that portfolio needs to be exposed via Ingress, so that the tradr UI will work. That pod basically gets the stuff loaded up into the browser's JavaScript engine, which then makes direct calls to portfolio straight from the browser, so Ingress is needed there. Node ports don't work, because then the browser gets fussy about cross-origin calls, if you try to hit a different host:port than what served up the html page. But Ingress (or OpenShift's Routes) addresses this, by making tradr and portfolio available on the same host:port.
Also, I only recently learned that you can do a kubectl edit (I usually set my KUBE_EDITOR env var to nano on my Mac, because I don't like the default of vi) on the service, to on-the-fly switch a service over to exposing a node port (or to change anything at all, in any Kube object, really - like the default number of replicas for a deployment). So that adds more reason to strip out the node ports on the non-front-door microservices - you can always flip it back on easily to do direct testing, by dynamically editing the yaml defining the service.
Fixed in chart version 0.1.1. Now only the microservices accessed directly from the browser (trader, tradr, looper, and portfolio) have a node port exposed. The backend microservices now do not.