Core concepts

In this document, we'll take a look at some of the core concepts that underpin Gloo Mesh. These concepts, like Virtual Meshes and Access Policies, are critical in understanding how Gloo Mesh can manage multiple service meshes and act as a unified control plane.

Virtual Meshes

To enable multi-cluster configuration, users will group multiple meshes together into an object called a VirtualMesh. The virtual mesh exposes configuration to facilitate cross-cluster communications.

For a virtual mesh to be considered valid, Gloo Mesh will first try to establish trust based on the trust model defined by the user – is there complete shared trust and a common root and identity? Or is there limited trust between clusters and traffic is gated by egress and ingress gateways? Gloo Mesh ships with an agent that helps facilitate cross-cluster certificate signing requests safely, to minimize the operational burden around managing certificates.

Once trust has been established, Gloo Mesh will start federating services so that they are accessible across clusters. Behind the scenes, Gloo Mesh will handle the networking – possibly through egress and ingress gateways, and possibly affected by user-defined traffic and access policies – and ensure requests to the service will resolve and be routed to the right destination. Networking configuration is pushed from Gloo Mesh to the managed service meshes that are part of the virtual mesh. Users can fine-tune which services are federated where by editing the virtual mesh.

Traffic and Access Policies

Gloo Mesh enables users to write simple configuration objects to the management plane to enact traffic and access policies between services. It was designed to be translated into the underlying mesh config, while abstracting away the mesh-specific complexity from the user.

A TrafficPolicy applies between a set of sources (workloads) and destinations, and is used to describe rules like “when A sends POST requests to B, add a header and set the timeout to 10 seconds”. Or “for every request to services on cluster C, increase the timeout and add retries”. As of this release, traffic policies support timeouts, retries, CORS, traffic shifting, header manipulation, fault injection, subset routing, weighted destinations, and more. Note that some meshes don’t support all of these features; Gloo Mesh will translate as best it can into the underlying mesh configuration, or report an error back to the user.

An AccessPolicy also applies between sources (this time representing identities) and destinations, and is used to finely control which services are allowed to communicate. On the virtual mesh, a user can specify a global policy to restrict access, and require users to specify access policies in order to enable communication to services.

With traffic and access policies, Gloo Mesh gives users a powerful language to dictate how services should communicate, even within complex multi-cluster, multi-mesh applications.

Custom resource translation

After installing and registering clusters with Gloo Mesh Enterprise, certain Kubernetes and Istio resources are automatically discovered and translated as custom resources in Gloo Meshes. Going forward, you can configure Gloo Mesh custom resources to automatically create the Istio resources that are needed to manage your service mesh environment.

Using the Gloo Mesh API helps you simplify your networking setup because you can write advanced configurations one time and apply the same configuration in multiple places and different contexts. For example, you can write a rate limit or authentication policy once. Then, you can apply this policy both to traffic that enters the cluster via Gloo Mesh Gateway (north-south), as well as to traffic across clusters via the Istio service mesh gateway (east-west).

The following figure outlines how Gloo Mesh custom resources are translated into Istio resources.

Note that many translations depend on fields that you configure in a Gloo Mesh resource. For example, a TrafficPolicy might create only a DestinationRule, or both a DestinationRule and VirtualService, depending on how you configure the policy. Additionally, multiple Gloo Mesh resources can configure the same or different Istio resources, depending on what you specify.

Figure of Gloo Mesh custom resource translation.

CLI Tooling

Gloo Mesh is tackling really hard problems related to multi-cluster networking and configuration, so to speed up your learning it comes with a command line tool called meshctl. This tool provides interactive commands to make it easier to author your first virtual mesh, register a cluster, or create a traffic or access policy. Once you’ve authored a config, it also has a describe command to help understand how your workloads and services are affected by your policies.

Next Steps

With a firm grounding in the core concepts, you're now ready to learn more about Gloo Mesh's architecture or dive into our Getting Started guide.