<p>We are trying to migrate our microservices architecture to K8s and Istio. We will have two k8s different clusters. One per frontend applications and the another for backend apps. Our initial idea is to configure each cluster as a separated Istio Mesh. </p>

<p>My doubt is; </p>

<p>Can we keep the locality-aware routing between clusters when a frontend app do a request against a backend app? </p>

<p>I have read it is possible when you have one mesh distributed among K8s clusters but I'm not sure if this feature keeps working when a mesh federation architecture is implemented.</p>

<p>Thanks!</p>

Mariano Mirabelli
<p>There is a functionality with something like that with istio multicluster configuration.</p>

<p>Depending on Your requirements there can be different types of multicluster models.</p>

<p>According to <a href="https://istio.io/docs/ops/deployment/deployment-models/" rel="nofollow noreferrer">istio</a> documentation: </p>

<blockquote>
  <p>When configuring a production deployment of Istio, you need to answer a number of questions. Will the mesh be confined to a single cluster or distributed across multiple clusters? Will all the services be located in a single fully connected network, or will gateways be required to connect services across multiple networks? Is there a single control plane, potentially shared across clusters, or are there multiple control planes deployed to ensure high availability (HA)? If there is more than one cluster being deployed, and more specifically in isolated networks, are they going to be connected into a single multicluster service mesh or will they be federated into a multi-mesh deployment?</p>
  
  <p>All of these questions, among others, represent independent dimensions of configuration for an Istio deployment.</p>
  
  <ol>
  <li>single or multiple cluster</li>
  <li>single or multiple network</li>
  <li>single or multiple control plane</li>
  <li>single or multiple mesh</li>
  </ol>
  
  <p>All combinations are possible, although some are more common than others and some are clearly not very interesting (for example, multiple mesh in a single cluster).</p>
</blockquote>

<hr>

<p>As for <a href="https://istio.io/docs/ops/deployment/deployment-models/#mesh-models" rel="nofollow noreferrer">mesh</a> functionality:</p>

<blockquote>
  <h3>Single mesh<a href="https://istio.io/docs/ops/deployment/deployment-models/#single-mesh" rel="nofollow noreferrer"></a></h3>
  
  <p>The simplest Istio deployment is a single mesh. Within a mesh, service names are unique. For example, only one service can have the name  <code>mysvc</code>  in the  <code>foo</code>  namespace. Additionally, workload instances share a common identity since service account names are unique within a namespace, just like service names.</p>
  
  <p>A single mesh can span  <a href="https://istio.io/docs/ops/deployment/deployment-models/#cluster-models" rel="nofollow noreferrer">one or more clusters</a>  and  <a href="https://istio.io/docs/ops/deployment/deployment-models/#network-models" rel="nofollow noreferrer">one or more networks</a>. Within a mesh,  <a href="https://istio.io/docs/ops/deployment/deployment-models/#namespace-tenancy" rel="nofollow noreferrer">namespaces</a>  are used for  <a href="https://istio.io/docs/ops/deployment/deployment-models/#tenancy-models" rel="nofollow noreferrer">tenancy</a>.</p>
  
  <h3>Multiple meshes<a href="https://istio.io/docs/ops/deployment/deployment-models/#multiple-meshes" rel="nofollow noreferrer"></a></h3>
  
  <p>Multiple mesh deployments result from  mesh federation.</p>
  
  <p>Multiple meshes afford the following capabilities beyond that of a single mesh:</p>
  
  <ul>
  <li>Organizational boundaries: lines of business</li>
  <li>Service name or namespace reuse: multiple distinct uses of the  <code>default</code>  namespace</li>
  <li>Stronger isolation: isolating test workloads from production workloads</li>
  </ul>
  
  <p>You can enable inter-mesh communication with  mesh federation. When federating, each mesh can expose a set of services and identities, which all participating meshes can recognize.</p>
  
  <p>To avoid service naming collisions, you can give each mesh a globally unique  <strong>mesh ID</strong>, to ensure that the fully qualified domain name (FQDN) for each service is distinct.</p>
  
  <p>When federating two meshes that do not share the same  trust domain, you must  federate  identity  and  <strong>trust bundles</strong>  between them. See the section on  <a href="https://istio.io/docs/ops/deployment/deployment-models/#trust-between-meshes" rel="nofollow noreferrer">Multiple Trust Domains</a>  for an overview.</p>
</blockquote>

<hr>

<p>So I suggest applying multicluster model to Your needs. The simplest solution is usually the best. Single mesh multicluster does allow for naming locality for Your multicluster environment.</p>

<hr>

<p>There is also <a href="https://istio.io/blog/2020/multi-cluster-mesh-automation/" rel="nofollow noreferrer">advanced</a> example of multicluster istio with use of <a href="https://github.com/istio-ecosystem/admiral" rel="nofollow noreferrer">Admiral</a> which allows to have custom naming possibilities.</p>

<p>Hope it helps.</p>
