Workspaces for gateway tenancy

In this scenario, you have one ingress gateway proxy 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 virtual gateway resource configures 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 ingress gateway proxy per namespace or cluster. Creating separate gateway proxies 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 gateway proxies. 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 virtual gateway in the workspace to manage all of the ingress gateway proxies. 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 ingress gateways for the different namespaces or clusters within your workspace. One virtual gateway might be used to configure all of the ingress gateway proxies 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.