You have many ways to set up ingress gateways into your service mesh, particularly when you scale up to multiple clusters and multiple meshes. Review the following examples for more information.
In this scenario, you have one ingress gateway for the workspace. The workspace might have only a few apps in a single cluster, or it might have apps spread across clusters.
Your Gloo Mesh virtual gateway resource configures the Istio ingress gateway so that you can use other Gloo Mesh features, such as rate limiting, external auth, and traffic policies. The gateway is aware of all the services within the workspace, no matter which namespace or cluster the service is in. Such separation offers better resiliency, availability, and security in case of an application failure.
For more mature single or multicluster setups, you might have one Istio ingress gateway per namespace or cluster. Creating separate ingress gateways can help isolate traffic for security purposes. For example, you might create separate Istio root CAs for separate intermediate CAs for mutual TLS across services. The services which these gateways route traffic to can overlap.
Another advantage to multiple ingresses is to help with high availability and location-aware routing. You can configure a network load balancer to route across the ingress gateways. When the traffic reaches a specific gateway, the gateway routes traffic to services that are local to its own cluster, before routing to other clusters if those services are unavailable locally for any reason.
In this scenario, you can create one Gloo Mesh virtual gateway in the workspace to manage all of the ingress gateways. This way, you can still ensure observability and consistent configuration for things such as ports, TLS for HTTPS traffic, and routes across clusters and namespaces.
In this scenario, you have multiple virtual gateways with the same workspace. For example, you might want different types of Istio ingress gateways for the different namespaces or clusters within your workspace. One virtual gateway might be used to configure all of the ingress gateways for namespaces that run on clusters in Region A, while another virtual gateway configures the ingress for namespaces that run on clusters in Region B.