Platform architecture
Review the Gloo Platform architecture to learn about the core, optional, and managed components that you can install and the networking traffic flow across the components.
In previous sections, you learned about service meshes, Istio, and the Gloo Platform licensed products that help you manage your environment. Now, you can learn more about the Gloo Platform components that you install to manage your environment, and how those components communicate with each other. After, you can dive deeper into the management server and agent relay architecture or check the default Kubernetes RBAC permissions of Gloo components.
Gloo Platform components
When you install Gloo Platform in your cluster environment, you can set up Gloo, optional addons, and Gloo-supported Istio components as described in the following diagram and tables.
Core Gloo Platform components
By default, Gloo Platform installs the following core components to manage your environment.
| Component | Products that use component | Description |
|---|---|---|
| Gloo agent | Gateway, Mesh, Network | The agents send snapshots of the Gloo resources from each workload cluster to the management server. |
| Gloo management server | Gateway, Mesh, Network | The management server maintains the desired state of your environment based on the configurations that you create. The server translates Gloo custom resources to the appropriate open source custom resources (such as Istio, Envoy, or Cilium). Then, the server pushes config changes to the agents to apply in the workload clusters. |
| Redis | Gateway, Mesh, Network | Redis®* 1 instances are used to store state data for several Gloo components, including the management server, and the state of the custom resources in each registered cluster. You can optionally bring your own Redis instance. If you see state reconciliation errors, you can try restarting Redis. |
Optional Gloo Platform addons
Install optional Gloo Platform addons to extend the capabilities, such as with rate limiting and external authentication servers.
| Component | Products that use component | Description |
|---|---|---|
| External auth server | Gateway, Mesh | Set up an external authentication and authorization to protect the workloads in your cluster. For example, you can set up basic, passthrough, API key, OAuth, OPA, or LDAP authentication. |
| Gloo UI | Gateway, Mesh, Network | With the UI, you can review the health and configuration of Gloo custom resources, including registered clusters, workspaces, networking, policies, 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. |
| OTel pipeline | Gateway, Mesh, Network | You can set up the Gloo OpenTelemetry (OTel) pipeline to collect metrics for your ingress gateway, service mesh, or Cilium CNI. |
| Portal | Gateway | With Gloo Portal, you can bundle and secure access to your APIs through a customizable developer portal. The portal supports the OpenAPI specification (OAS), also known as Swagger. Because the APIs must be available externally, Portal works only with Gateway. For more information, see the Developer portal guides in the Gloo Gateway documentation. |
| Prometheus | Gateway, Mesh, Network | The default Prometheus deployment scrapes metrics from the Gloo telemetry gateway. You can also bring your own instance. |
| Rate limit server | Gateway, Mesh | Control the rate of requests to destinations within the service mesh. |
| Redis | Gateway, Mesh, Network | Redis instances are used to store state data for several Gloo components. You can optionally bring your own Redis instance.
|
Gloo-supported Istio components
With Solo’s Istio Lifecycle Manager, you can also use Gloo Platform to 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. For more information, review the Istio Lifecycle Manager guide.
| Component | Products that use component | Description |
|---|---|---|
| Istiod | Gateway, Mesh | 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 | Gateway, Mesh | When you use Solo’s Istio Lifecycle Manager, an Istio operator is created to manage the other installed Istio components. |
| Ingress gateway | Gateway, Mesh | 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. |
| East-west gateway | Gateway, Mesh | Based on Envoy, the Istio east-west gateway is deployed in each workload cluster to manage traffic internal to the service mesh, even across clusters. |
| Workload proxy | Gateway, Mesh | 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. |
Networking architecture
Now that you know more about the Gloo core components, optional addons, and managed Istio components that help manage your environment, review how these components communicate with each other in the following diagram.
*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Solo.io, Inc. is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Solo.io. ↩︎