Architecture
Review how Gloo Mesh Core components work together to extend observability and insights into your Istio environment.
Component architecture
When you install Gloo Mesh Core in your cluster environment, you get Gloo, other projects integrated with Gloo, and Gloo-supported Istio components as described in the following diagram and tables.
Gloo components
By default, Gloo Mesh Core includes the following components that Solo develops.
| Component | Description |
|---|---|
| Gloo agent | The agents send snapshots of the Gloo resources from each workload cluster to the management server. |
| Gloo management server | The management server maintains the desired state of your Gloo environment based on the configurations that you create and the information that is stored in Redis and Prometheus. |
| Gloo insights | The Gloo insights engine uses the logs from the Gloo analyzer and executes queries on Prometheus metrics to create Solo insights. You can use these insights to evaluate your Istio setup and get recommendations to harden Istio components in your cluster. |
| Gloo UI (dashboard) | With the UI, you can review the health and configuration of your environment, including registered clusters, Istio, certificates, app services, and more. You can even set up external authentication that is synchronized with Kubernetes role-based access control to manage how your users access the UI. |
| Gloo analyzer | The Gloo analyzer runs analyzers from Istio and Solo to gather data on the status of Istio, proxies, certificates, images, and other components. This information is stored as logs in Redis by using the Gloo telemetry pipeline and used by the Gloo insights engine to create Solo insights. |
Other projects
Gloo Mesh Core incorporates several other open source projects to extend its capabilties. Although Solo does not develop these projects, the projects are supported as part of regular Gloo usage. Depending on the project, you may or may not be able to use your own instance instead, but support and setup vary.
| Component | Description |
|---|---|
| OTel pipeline | You can set up the Gloo OpenTelemetry (OTel) pipeline (gateway and workload collectors) to collect telemetry data in your environment. |
| Prometheus | The default Prometheus deployment scrapes metrics from the Gloo telemetry gateway and collector agents, including custom solo_io_insights. You can also bring your own instance. |
| Redis | Redis is used for several Gloo components. You can optionally bring your own Redis instance.
|
| Grafana | Use pre-built Grafana dashboards to evaluate the health of Cilium and Gloo Mesh Core components, or to troubleshoot bottlenecks in your setup. |
Istio components
Gloo Mesh Core can optionally manage several open source Istio components. When you use Solo distributions of Istio, these Istio components are part of your Solo support. If you want to customize these installations, you might lose some of the managed benefits.
| Component | Description |
|---|---|
| Istiod | Istiod is the control plane for the Istio service mesh on each workload cluster. For multicluster environments, Gloo federates trust by using a unified root trust policy across clusters. |
| Operator | When you use the Solo’s Istio Lifecycle Manager, an Istio operator is created to manage the other installed Istio components. |
| Ingress and egress gateways | Based on Envoy, the Istio ingress gateway is deployed to manage traffic into and out of the service mesh. Depending on your security requirements, you might set up an ingress gateway per environment, per cluster, or in other ways. |
| Workload proxy | Based on Envoy, Istio workload proxies manage network communication between the workload and other microservices. You can choose between sidecar or ambient (sidecarless) mode setups. In sidecar mode, each workload has its own Istio sidecar proxy for more fine-grained control. In ambient mode, you set up ztunnel and waypoint proxies that decouple the proxy from the application for greater operational efficiency. You can deploy more waypoint proxies for more fine-grained traffic control. Note that ambient mode is not supported with Solo’s Istio Lifecycle Manager. |
Cilium components
When you deploy the Cilium CNI with a Solo image, the following components are deployed to your cluster.
| Component | Description |
|---|---|
| Cilium CNI plugin | Kubernetes invokes the CNI plugin when a pod is scheduled or terminated on a node to provide the necessary configuration of networking, load balancing, and network policies for the pod. |
| Cilium operator | The Cilium operator manages changes that must be made across all nodes in the cluster, rather than once for each node in the cluster. |
| Cilium agent | The Cilium agent runs on each node in the cluster to apply configuration that describes networking, service load balancing, visibility and monitoring requirements, and network policies. The Cilium agent listens for events from Kubernetes to know when containers or workloads are started and stopped, and manages the eBPF programs which the Linux kernel uses to control all network access in and out of those containers. |
Networking architecture
Now that you know more about the Gloo core components, integrated projects, and managed Istio components that help manage your environment, review how these components communicate with each other in the following diagram.
