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.
The components that comprise Gloo Mesh can be categorized as
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
DestinationRule resources if managing Istio. Let's take a closer look at the components.
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.
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-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
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
DestinationRule resources to enable cross-cluster/mesh communication.
mTLSTranslator are grouped within the
VirtualMeshTranslator to handle mesh level configuration and networking.
FederationTranslatorhandles global DNS resolution and routing for services in remote clusters for each federated destination.
FailoverTranslatorre-routes traffic to targets in remote clusters when local targets are unhealthy.
mTLSTranslatorcontrols mesh-level settings for performing mTLS, including issuing & rotating root certificates used by each mesh.
DestinationTranslator handles the translation and policy configuration at the
Destination (service) level.
AuthorizationPolicyfor access control.
If users create a
AccessPolicy for Gloo Mesh, the
mesh-networking component will automatically translate those to the underlying mesh-specific resources. Again, for Istio, this would be
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.
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.