I’m trying to understand the right way to meet our multicluster requirements with Istio, and some guidance would be much appreciated. We are using separate Istio control planes in each cluster.
My understanding of the way Istio currently prefers you to route intercluster traffic is to use automatic service discovery to populate its service registry with mysvc.myns.svc.cluster.local entries for the remote services; if you want to distinguish services by which cluster they are in, you have to wedge a cluster identifier into the namespace or service name somewhere. This is grounded in the concept of namespace sameness being promoted by the MCS Kubernetes initiatives. The overall advantage is not having to write ServiceEntry per service since you have service discovery for free, and not having to identify the EW gateway by some domain name in the remote cluster in the ServiceEntry. Plus you are pushed towards writing code which transparently works well with locality based routing. It isn’t great for having cluster-local services which you want to explicitly address from another cluster, but by disambiguating at the namespace level, say, you can still get the service entry for free.
This is different to old versions of Istio docs and lots of material online, which tends to assume you will be constructing a ServiceEntry per remote service, and inventing something like a mysvc.global host for that. (This is also the case supported by Admiral, which seems to have very limited adoption, though it does have the nice feature of helping you construct DNS entries like mycluster.mysvc.global.)
One of the key questions for us is how to ensure that all intercluster traffic is routed through an egress gateway (a requirement arising from security policies external to Istio).
Now old versions of the docs explain this is going to require writing a ServiceEntry per remote service which names both the local egress gateway and the remote EW gateway. There is no analogous section in the current docs. How should I achieve the same result in current versions of Istio where it seems I’m supposed to not need to create all these extra Istio resources? Does this requirement actually mean I can’t use the inbuilt service discovery, and in fact do need to have an extra layer of automation in place to populate a separate ServiceEntry set for every remote service, pointing at it on every cluster? Or is there a nice clean way to configure this kind of routing globally?
Many thanks in advance!