perhaps i’m missing the forest for the trees, it would be great if you could help me out with an alternative or verify that i understood things correctly:
I want to establish a connection to a resource outside of the mesh, say, an oracle database on port 1521.
So i created a serviceEntry like this, and it works fine.
spec: hosts: - mydatabase-1.company.com location: MESH_EXTERNAL ports: - number: 1521 name: tcp protocol: TCP resolution: DNS
Some time later i want to connect to another database instance that uses the same port, but it’s a different hostname. It’s TCP Traffic too.
spec: hosts: - mydatabase-2.company.com location: MESH_EXTERNAL ports: - number: 1521 name: tcp protocol: TCP resolution: DNS
The result then is chaos, as Istio/Envoy uses only the port to identify the routing for TCP traffic if no addresses are explicitly set, according to the describtion of the addresses parameter in (https://istio.io/latest/docs/reference/config/networking/service-entry/#ServiceEntry).
It even routes traffic to the wrong database based on the sidecar access logs, even though the application is configured on the correct hostname. Ugh!
Now, according to the documentation i need to identify unique CIDRs or IPs for each of those DBs and list these in the addresses parameter in order to avoid this issue.
That seems to work.
But what if one can’t do this? What if they’re different instances within the same CIDR block, or those might change? This seems to defeat the purpose of using DNS, at least partially. That seems like a very severe limitation to me.
How would you solve this, are there mechanisms within istio/envoy themselves to work around this issue that do not require changes to the infrastructure outside of it?
Thanks a lot in advance!