Architecture
Review how Gloo Network for Cilium components work together to extend observability and insights into your environment.
Component architecture
When you install Gloo Network for Cilium in your cluster environment, you get Gloo, other projects integrated with Gloo, and Gloo-supported Cilium components as described in the following tables.
Gloo components
By default, Gloo Network 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 Cilium setup and get recommendations to harden Cilium components in your cluster. |
| Gloo UI (dashboard) | With the UI, you can review the health and configuration of your environment, including registered clusters, Cilium, 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 gathers data on the status of Cilium, 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. |
Cilium components
When you deploy Cilium 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. |
Other projects
Gloo Network incorporates several other open source projects to extend its capabilities. 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 Network components, or to troubleshoot bottlenecks in your setup. |