Overview of gateway concepts
Gloo Mesh Gateway is an abstraction built on top of Istio's ingress gateway model. It can be used as a way to simplify the configuration of ingress traffic rules while retaining seamless integration with your service mesh. It also adds powerful multi-cluster, multi-mesh capabilities to your gateway.
Basic Gateway features are available with a standard Gloo Mesh Enterprise license. To use advanced gateway features, purchase a Gloo Mesh Gateway license. When you install Gloo Mesh, use this gateway license instead of a standard Gloo Mesh Enterprise license.
|Feature||Gloo Mesh Gateway license||Gloo Mesh Enterprise standard license||Istio ingress|
|Proxy external traffic to mesh workloads||✅||✅||✅|
|Cross-origin resource sharing (CORS)||✅||✅||✅|
|Retries, redirects, timeouts, and fault injection||✅||✅||✅|
|API developer portal||✅||✅||❌|
|Automatic service and API discovery||✅||✅||❌|
|Advanced rate limiting||✅||❌||❌|
|Advanced security including WAF and DLP||✅||❌||❌|
|Advanced external authentication for OIDC, OPA, API keys, and LDAP||✅||❌||❌|
|Request and response SOAP transformation||✅||❌||❌|
|Advanced traffic routing and shaping, such as direct responses and route delegation||✅||❌||❌|
There are many ways to set up ingress gateways into your service mesh, particularly when you scale up to multiple clusters and multiple meshes. Below we have a few examples of what this could look like.
Single cluster architectures
If you favor simplicity over complexity, you can issue a single root CA and a single intermediate CA to issue certificates for both Istio and relay agents.
In this setup, one ingress gateway routes traffic to the services in one cluster.
If security is your top concern, you can create separate root CAs for separate intermediate CAs. This setup ensures that the communication between the Gloo Mesh relay server and agents does not share a common root of trust with the communication of your service mesh applications.
In this setup, multiple ingress gateways are deployed to one cluster. The services which these gateways route traffic to can overlap.
Gloo Mesh Gateway Custom Resources
In order to make all of the above scenarios easier to configure, we have introduced three new Custom Resources (CRs):
Each of these resources will live in the Management Cluster, although they may be used to configure ingress resources in any cluster managed by Gloo Mesh. These resources are installed as part of Gloo Mesh Enterprise, and no additional settings are required to start using Gateway features.
A VirtualGateway resource will define the Envoy listeners, i.e. the protocols and ports to listen on. It will also define which Envoy filters are attached, by allowing users to specify a FilterChain (or multiple FilterChains). It attaches to existing ingress gateway workloads via a workload selector, and specifies one or more VirtualHost configurations to configure routing rules. A single VirtualGateway can apply to multiple ingress gateway deployments across all meshes and clusters contained within a VirtualMesh. Attached Gateways will be listed in the status of the VirtualGateway. In order to perform cross-mesh routing, the Gateway Mesh and Destination Mesh must be contained in a single VirtualMesh with federation enabled.
VirtualHosts are selected by a VirtualGateway. A single VirtualHost can be selected by multiple VirtualGateways. VirtualHosts are responsible for configuring top level settings, such as domains. In addition, a VirtualHost can set route options that apply to all child routes, which will be inherited as a default unless explicitly overridden at the route level. A VirtualHost contains a list of Routes, which can contain various matchers and actions.
A RouteTable is effectively a list of Routes. It exists only to be delegated to from VirtualHosts, or other RouteTables. This allows users to separate configuration and ownership across the organization. For example an app-level team may want to configure all of the low-level endpoints that are sent to their service, but may not have control over which domains they can serve traffic on, or what the authorization policies are. Routes configured in RouteTables will by default inherit any options configured by their parent delegating resource (RouteTable or VirtualHost), for example, timeout or retry settings.
Routes can be configured on a VirtualHost, and/or a RouteTable. Routes consist of options, matchers, and an action. Options are a way to specify route policies in-line, for example a retry policy or a timeout. Matchers are how the routing logic determines which route is selected. It could match on a path, http method, or header, for example. Routes can have one of four actions:
Used to send traffic directly to one of three destination types:
- A Kubernetes service, the most commonly used option. Notably, this is a service in a specific cluster.
- A VirtualDestination, useful for locality based failover.
- A static destination, useful for routing to services outside of your service mesh.
Redirect actions are used to redirect certain requests to alternate paths. Commonly used to configure eg HTTP 301 responses.
Direct Response Action
Direct response action can be used to directly return a specified body and HTTP status from the proxy, without forwarding the request upstream at all. If necessary, headers can be specified usign the Header Modification feature in the enclosing route.
Delegate action will pass the routing responsibility to a RouteTable. This can be very useful when the number of routes configured on a given gateway starts to become large, and multiple teams need to make route edits.
On this page we talked about the Gloo Mesh resources used to configure Gloo Mesh Gateway, as well as several network topology options commonly used when deploying it. You can check out our Getting Started Guide to see some specific examples and try out these concepts for yourself!