Gloo Mesh Architecture
This document details the architecture of Gloo Mesh using the standard deployment model. The deployment model informs how Gloo Mesh is deployed and operated. Gloo Mesh Enterprise provides an alternative relay model which differs from the standard deployment model by adopting a distributed pull architecture.
Components
The components that comprise Gloo Mesh can be categorized as mesh-discovery
and mesh-networking
components. These components work together to discover meshes, destinations, and unify them using a VirtualMesh
. These components will write all of the necessary service-mesh-specific resources to the various clusters/meshes under management. For example, Gloo Mesh would write all of the ServiceEntry
, VirtualService
and DestinationRule
resources if managing Istio. Let's take a closer look at the components.
Mesh Discovery
A cluster is registered using the CLI meshctl cluster register
command. During registration, Gloo Mesh authenticates to the target cluster using the user-provided kubeconfig credentials, creates a ServiceAccount
on that cluster for Gloo Mesh and builds a kubeconfig granting access to the target cluster which is stored as a secret
on the management-plane cluster. This kubeconfig is then used by Gloo Mesh for all communication to that target cluster. For instance, discovery uses this kubeconfig to connect to the target cluster and start discovery.
The discovery process is initiated by Gloo Mesh running on the management plane cluster, pulling and translating information from the registered target clusters. Discovery of a target cluster is performed when the cluster is first registered and then periodically to discover and translate any newly added meshes, workloads, and destinations.
The first task of discovery is to create an Input Snapshot
and begin the translation of the service meshes and services on the cluster to create an Output Snapshot
that creates custom resources to the management plane cluster.
MeshTranslator
looks for installed service mesh control planes and then will add them to the Output Snapshot
for a Mesh
resource to be written to the management plane cluster, linked to the KubernetesCluster
resource that was written during cluster registration. Currently, Gloo Mesh discovers and manages both Istio and Open Service Mesh meshes, with plans to support more in the near future.
WorkloadTranslator
then looks for workloads that are associated with the mesh, such as a deployment that has created a pod injected with the sidecar proxy for that mesh. It adds them to the Output Snapshot
which will write a Workload
resource to the management plane cluster representing this workload.
Finally, DestinationTranslator
looks for services exposing the workloads of a mesh and adds them to the Output Snapshot
which then writes a Destination
resource to the management plane cluster.
At this point, the management plane has a complete view of the meshes, workloads, and destinations across your multi-cluster, multi-mesh environment.
Mesh Networking
While the mesh-discovery
components discover the resources in registered clusters, the mesh-networking
components make decisions about federating clusters and meshes. The VirtualMesh
concept enables the federation of multiple meshes into a single managed construct. As part of the VirtualMesh
resource, you will define a federation model and trust model to use.
Mesh-networking
is what performs translation at the mesh level for the group of meshes within the VirtualMesh. There are two components that comprise mesh-networking
, VirtualMeshTranslator
and DestinationTranslator
. The VirtualMeshTranslator
handles translation of settings at the mesh level, mapping mesh configuration defined by the VirtualMesh to individual meshes. The DestinationTranslator
handles translation at the service layer to manage the mapping of services to workloads and destinations. For example, with Istio, Gloo Mesh will create the appropriate ServiceEntry
and DestinationRule
resources to enable cross-cluster/mesh communication.
The FederationTranslator
, FailoverTranslator
, and mTLSTranslator
are grouped within the VirtualMeshTranslator
to handle mesh level configuration and networking.
FederationTranslator
handles global DNS resolution and routing for services in remote clusters for each federated destination.FailoverTranslator
re-routes traffic to targets in remote clusters when local targets are unhealthy.mTLSTranslator
controls mesh-level settings for performing mTLS, including issuing & rotating root certificates used by each mesh.
The DestinationTranslator
handles the translation and policy configuration at the Destination
(service) level.
TrafficPolicyTranslator
creates theVirtualService
andDestinationRule
for routing.AccessPolicyTranslator
creates theAuthorizationPolicy
for access control.
If users create a TrafficPolicy
or AccessPolicy
for Gloo Mesh, the mesh-networking
component will automatically translate those to the underlying mesh-specific resources. Again, for Istio, this would be VirtualService
, DestinationRule
, and AuthorizationPolicy
resources.
As opposed to the pull model of the mesh-discovery
components, the mesh-networking
components of Gloo Mesh push changes down to the managed service meshes in each registered cluster. The configuration used by the control plane of each service mesh will be updated in real-time as changes are pushed from Gloo Mesh. 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 will be contingent on the polling cycle for the service mesh proxy instances.
Next Steps
The best way to understand how Gloo Mesh functions is by deploying it yourself and trying some of the features. We recommend diving in with the Installation guide.