I am experimenting with a service discovery scheme on Kubernetes. I have 20+ GRPC services that can be grouped and deployed as applications on Kubernetes. Each application serves several of these services with a common GRPC server. There is a service to publish this GRPC port, and I have labels on those services that identify which GRPC servers are running there.
For instance, I have APP1 application serving GRPC services a,b,c. There is a service in front of APP1 connected to the port 8000, with labels a,b,c. So when a component in the cluster needs to connect to service, say, "b", it looks up services that have the label "b", and connects to port 8000 of one of those. This way, I can group the GRPC services in different ways, deploy them, and they all find each other.
I started thinking about an alternative approach. Instead of having one service with labels for each app, I want to have multiple services (one for each GRPC service) for the same app:port with different names. So in this new scheme APP1 would have three services, a, b, and c, all connected to the same app:port. The clients would simply look up the name "b" to find the GRPC server "b".
The question is: do you see any potential problems with having multiple services with different names that are connected to the same port of the same app, exposing the same port? That is, addresses a:8000, b:8000, c:8000 all pointing to APP1:8000.
To be honest I don't see any problem as long as your application identifies internally that the client is trying to talk to either a:8000, b:8000, or c:8000. Essentially, you will find to just a single port 8000 in this case in the container. This would be analogous to different HTTP endpoints per service some like https://myendpoint:8000/a, https://myendpoint:8000/b, and https://myendpoint/c.
Note that 8000 would be the port in the container but Kubernetes will use a random port on the node to forward the traffic to 8000 in the container.