Architecture

A Gloo Mesh setup consists of one management cluster that the Gloo Mesh Enterprise management components are installed in, and one or more workload clusters that run services meshes which are registered with and managed by the management cluster. The management cluster serves as the management plane, and the workload clusters serve as the data plane.

As shown in the following figure, you can think of Gloo Mesh as a management plane for multiple service mesh control planes. When a workload cluster is registered with Gloo Mesh, the management plane can begin managing that cluster by discovering workloads, pushing out configurations, unifying the trust model, scraping metrics, and more.

Figure: Gloo Mesh Enterprise provides multicluster, multimesh management to any Kubernetes platform for simple Istio service discovery, traffic shaping, secured app traffic like external auth, failover, locality-aware load balancing, and more.

Components

Gloo Mesh Enterprise consists of a relay server for the management plane and relay agents for each workload cluster in the data plane.

Relay server on the management cluster

When you install Gloo Mesh Enterprise in the management cluster, a deployment named enterprise-networking runs the relay server. The relay server is exposed by the enterprise-networking service on a default port of 9900/TCP. The management cluster requires a configured ingress point that allows workload clusters to communicate with the relay server, which can be achieved through an ingress gateway such as Istio or Gloo Edge, or by setting the enterprise-networking service type to LoadBalancer.

Relay agents on workload clusters

When you register workload clusters to be managed by Gloo Mesh Enterprise, a deployment named enterprise-agent is created on each cluster to run the relay agent. The relay agent is exposed by the enterprise-agent service on the default ports of 9988 and 9977. Because all communication is outbound from the workload clusters to the management cluster, no ingress point must be configured for the relay agent.

Agent-server communication

Communication between the management and data planes is initiated by relay agents, which run in the workload clusters, to the relay server, which runs in the management cluster. The following figures outline the general flow of how the relay agents and server communicate to keep your multimesh ennvironment up to date.

Step 1: Relay server and workload cluster agent registration

A workload cluster is registered with the Gloo Mesh management plane. The relay agent in the workload cluster establishes two-way, mTLS-secured gRPC communication with the relay server in the management cluster.

Figure: Relay server and workload cluster agent registration.

Step 2: Istio mesh discovery

The relay agent in the workload cluster sends a snapshot of its state to the relay server. The mesh discovery components of the management plane translate the snapshot into custom resources, which form a complete view of the meshes and mesh entities across all workload clusters.

Figure: Istio mesh discovery.

Step 3: Gloo Mesh resources to manage Istio meshes across clusters

As users apply Gloo Mesh resources to the Gloo Mesh management plane, the mesh networking components of the management plane translate these resources into mesh specific configuration updates for each workload cluster. Then, the relay server pushes the updates to the relay agents in the workload cluster and the agents apply the updates to the workload cluster.

Figure: Gloo Mesh resources to manage Istio meshes across clusters.

More details about agent-server communication

Now that you reviewed the overall flow of how Gloo Mesh's relay architecture works, learn more about how Gloo Mesh secures communication, translates mesh resources, and reconciles configuration updates.

Secure communication

To validate authenticity during registration time of a workload cluster, the relay agent uses simple TLS to transmit a token value, which is defined in relay-identity-token-secret on the workload cluster, to the relay server. The token must match the value stored in relay-identity-token-secret on the management cluster, which is created during deployment of the relay server. When the token is validated, the relay server generates a TLS certificate for the relay agent. All future communication from relay agents to the server, which uses the gRPC protocol, is secured by using mTLS provided by this certificate.

Note that you can use self-signed certificates or certificates from your PKI to secure server-agent communication. For more information, see the certificate management strategies for proof-of-concept or production.

Mesh discovery

Each relay agent performs mesh discovery for the cluster that it is deployed to. The relay agent constructs a snapshot of the actual state of discovered entities, such as service meshes and services, in the workload cluster. Currently, Gloo Mesh discovers and manages Istio service meshes.

The agent then pushes this snapshot of the workload cluster state to the relay server. When the relay server receives a snapshot, the discovered entities in the snapshot are translated into custom resources by the following mesh discovery components.

These custom resources provide the relay server with the complete state of the service meshes, workloads, and destinations across the multicluster, multimesh environment. When you make cross-mesh configuration changes, the relay server uses this state to create configuration updates for the workload clusters.

Mesh networking

While the mesh discovery components discover the state of resources in workload clusters, the mesh networking components federate individual service meshes across workload clusters. The VirtualMesh concept enables the federation of multiple service meshes into a single managed construct.

The following mesh networking components configure mesh-level and service-level settings across multiple service meshes.

Configuration updates and state reconciliation

The relay server watches for user-provided configuration updates in the management cluster. For example, you might create a TrafficPolicy or AccessPolicy for Gloo Mesh. Using the information that was gathered by mesh discovery components about the individual mesh control planes, workloads, and destinations across workload clusters, the mesh networking components automatically translate your provided Gloo Mesh resources into resources that are specific to each workload mesh. For example, if a relay agent reports that its cluster runs an Istio service, the relay server translates your Gloo Mesh resources into VirtualService, DestinationRule, and AuthorizationPolicy Istio resources.

The relay server then reconciles this declared state with the actual state of the workload clusters, and creates configuration updates. The relay agents in workload clusters pull these updates in real time and apply them to the control planes of each service mesh. Note that many service mesh proxies, like Envoy, rely on a polling mechanism between the control plane and the proxy instances. Therefore, any changes pushed from Gloo Mesh are contingent on the polling cycle within a workload cluster's service mesh for the mesh proxy instances.