I have a Problem with some legacy application. This application has (like so many of em) a server and a client side. We’re now deploying the server side in kubernetes. The application already has an architecture which fits at least OK to the architecture
Now for the problem: Each of the application containers registers services with a central service registry (also running as pod). It does so by adding an entry with the own host and port where services are exposed (and: it is NOT HTTP, but plain TCP for those services). Now if anyone requires a certain service, it visits this registry and retrieves the actual location of the service and contacts it. I know this mechanism does not really fit to how things should be in kubernetes, but I cannot rewrite a few M lines of code overnight . OK. So there are multiple problems:
- Since the service registers itself by providing it’s own hostname (kubernetes service name), all other parties need to be able to resolve this hostname (cluster internal pods will get this via KubeDNS/CoreDNS, right?). The problem here are cluster-external applications (clients): First they need to find the location of the registry, which itself is a kubernetes service as well (also type NodePort). I can get this to work by telling the client the IP/Port of any Node. But then the client fetches service information from the registry and cannot connect to any of the hosts mentioned in there, as there is not DNS. So what I need: a DNS service which resolves the service names to the IP of a Node (best would be the node the service is actually running on).
- Since the service registers itself by providing it’s own port, ports need to be identity mapped - thus I’m currently using NodePort services (this is OK for me right now, but if anyone has a better Idea, please tell me!).
Any Hints, Help, etc. would be greatly appreciated!