Service mesh
Improve the routing and security for your apps by adding your apps to a service mesh and using an API Gateway to control incoming traffic to the service mesh.
The deployment patterns shown on this page require your apps to be in a service mesh that is managed by Gloo Mesh Enterprise. Gloo Mesh Enterprise is a multicluster and multimesh management plane that is based on hardened, open-source projects like Envoy and Istio. To implement these deployment patterns, you need a separate license for Gloo Mesh Enterprise. For more information, see About Gloo Mesh Enterprise.
What is a service mesh?
A service mesh is a dedicated infrastructure layer that you add your apps to. The service mesh provides central management for your cloud-native microservices architecture. This way, you can optimize your apps in areas like communication, routing, reliability, security, and observability.
For more information, see What is a service mesh?
What is Istio?
The open source project Istio is the leading service mesh implementation that offers powerful features to secure, control, connect, and monitor cloud-native, distributed applications. Istio is designed for workloads that run in one or more Kubernetes clusters, but you can also extend your service mesh to include virtual machines and other endpoints that are hosted outside your cluster.
For more information, see What is Istio?
Routing without Gloo Mesh Enterprise
To understand the benefits of using Gloo Mesh Gateway in combination with Gloo Mesh Enterprise, let’s take a look at how high availability for an app works if your apps are not part of a service mesh that is managed by Gloo Mesh Enterprise.
In this example, a global API Gateway is configured in a separate cluster that serves all traffic for an availability zone. An incoming request for app2.io
is load balanced between the clusters where app2
is deployed, and forwarded from the global API Gateway to the API Gateway of each cluster. The Gloo management plane controls the rollout of the API Gateway configuration across clusters to reduce management overhead and the risk of configuration drift.
If app2
now wants to send a request to app1
in the same cluster, the request is routed directly to app1
. However, if app1
in cluster 1 is not available, the request is routed back to cluster 1’s Gloo Mesh Gateway, and forwarded to the app1
instance in cluster 2. This setup requires additional network hops and increases network latency, response time, and infrastructure cost.
Intelligent routing with Gloo Mesh Enterprise
Now, let’s take a look at how Gloo Mesh Enterprise significantly improves this routing example. By adding your services to a service mesh, the services are automatically discovered across clusters and Gloo Mesh Enterprise is aware what services are deployed in which cluster. For apps that spread across clusters, you can define unique internal hostnames with Gloo Mesh Enterprise virtual destinations that apps in the service mesh use to send requests to another app.
To reach a multicluster endpoint, your apps inside the mesh simply send a request to the internal hostname, and Gloo Mesh Enterprise then routes the request to the desired destination. Your apps do not need to know where the target app is deployed within the mesh. Instead, Gloo Mesh Enterprise takes into account the context of the client request, such as the client location, where the target app is deployed within the mesh, and the routing rules that you defined to ensure that the request is routed in an efficient and secure manner.
By using locality-based routing, the request from app2
to app1
is first routed to the app1
instance in the same cluster. If this instance is not available, the request is then routed to the instance that is next closest. In addition, traffic between app2
and app1
is secured with mutual TLS (mTLS).
Combining Gloo Mesh Gateway and Gloo Mesh Enterprise enables the following benefits:
- Intelligent in-cluster and multicluster routing: With locality-based routing, requests are always routed to the app instance that is closest to the app that initiated the request reducing network latency and response time.
- Security into the service mesh and within: With an API Gateway, you can protect the apps in your clusters by setting up security measures, such as external authentication and authorization, outlier detection, or rate limiting. When combined with Gloo Mesh Enterprise, you can enforce mutual TLS (mTLS) connections from the API Gateway to your apps. This setup significantly reduces the surface of vulnerability and the risk of malicious attacks.
- Central management with Gloo: Instead of manually managing API Gateways, routes, policies, and destinations across clusters, you can use the Gloo management and data plane to roll out configurations across clusters. That way, you can reduce the management overhead for the resources in your cluster and avoid configuration drift.
- UI and monitoring: To gain insight into the Gloo Mesh Gateway and Gloo Mesh Enterprise resources and the network traffic between your apps, you can use the Gloo UI and leverage the built-in Prometheus server for metrics.