Redis

Redis®* 1 is an open source, in-memory data structure store. For more information, see the Redis docs.

Gloo uses Redis as the backing database for many components. When you install Gloo, different Redis instances are deployed by default. You can also bring your own Redis instance. These Redis instances might be deployed locally to your cluster with Redis Enterprise, hosted in Redis Cloud, or provided by a Redis API Compatible Service such as AWS ElastiCache or Google Cloud Memorystore.

For more information, see the following resources:

  • The Backing databases guides for each Gloo component walk you through your options to configure Redis as a backing database for the various Gloo components. These guides include the following details:
    • An overview of what data gets stored for the Gloo component.
    • Instructions to configure different backing databases, including bring-your-own Redis.
    • Provider-specific considerations for configuring the instances that back that Gloo component.
  • Relay architecture, which explains how the management server, agent, and backing Redis database work together to maintain the desired state of your environment.
    • Size and memory system requirements, which suggest different Redis instance sizes based on the size of your environment and the Gloo management plane.

    Backing databases for each Gloo component

    You can configure the backing database for the following Gloo components:

    More details on stored data

    Review the following sections to learn more about what data is stored for the different uses of Redis to back up Gloo Mesh Enterprise components.

    Data stored in snapshots

    The Gloo snapshot that the agent sends to the management server is stored in the management server’s backing storage. For an example of how to check the data that gets stored, see Review data in Redis.

    • Discovered Kubernetes resources, such as Kubernetes services, deployments, replicasets, daemonsets, and statefulsets. The management server translates discovered resources into Istio resources and displays them in the Gloo UI. Note that you can use Istio discovery selectors to ignore certain Kubernetes resources. Ignored resources are not included in the snapshot that is sent from the agent to the management server.
    • Gloo custom resources that you create. The management server translates Gloo resources and displays them in the Gloo UI.
    • Istio resources, including:
      • Istio resources that, after initial server-agent setup, the management server automatically translates from your Gloo resources and writes back to the workload cluster. These resources are included in the snapshot to avoid accidentally deleting them from the workload cluster if an agent disconnects and reconnects, and to display them in the Gloo UI.
      • Any Istio resources that you manually created, so that they can be displayed in the Gloo UI.
    • Internal resources that are computed in memory by each agent and pushed to the management server without being persisted in the workload cluster. Internal resources include:
      • Gateway resources, which contain information about gateway endpoints in the cluster.
      • IssuedCertificate and CertificateRequest resources, which are used in internal multi-step workflows that involve both the agent and the management server.
    • External authentication information the UI, when enabled. This data includes user session information such as access and ID tokens.

    Data stored for insights

    If you enable the insights engine that is available in version 2.6 or later, Gloo Mesh Enterprise automatically analyzes your Istio setup to check for health issues. This insight information is stored in Redis for the Gloo UI to read and display to you in the dashboard.

    For more information, see Insights.

    Data stored for the external auth service

    The external auth service stores data to use to authenticate to destinations and routes that are protected by an external auth policy and enforced by an external auth server.

    Such data can include the following, depending on how you configure external auth.

    • API keys that you create (such as through the developer portal), either as plain text or hashed if you configure a secret key to hash the values.
    • Session data such as cookies.
    • OIDC distributed claims.

    For more information, see External authentication and authorization.

    Data stored for the developer portal

    The portal server stores the following data in the backing database. For an example of how to check the data that gets stored, see Review data in Redis.

    • API keys that end users can use to authenticate to destinations and routes that are protected by an external auth policy that the external auth server enforces.

    To use Gloo Portal, you must configure both the portal server and external auth service to use the same backing storage. Review the following diagram for more information.

    Portal and external auth shared backing database
    Portal and external auth shared backing database
    1. As the portal admin, you configure the backing storage database for both the external auth and portal servers.
    2. As an end user, you use the developer portal to generate an API key. Then, the Gloo portal server writes this API key to the shared backing storage database, such as Redis.
    3. As an end user, you include the API key in subsequent requests to the API products that you want to access. The Gloo ingress gateway receives your requests and checks the API’s route for external auth policies. The Gloo external auth server reads the API key value from the shared backing storage database, such as Redis. If the API key matches a valid value, then the Gloo gateway sends the request to the API product and you get back a successful response.

    For more information, see Verify that external auth works with API keys in a backing storage database in the Gloo Mesh Gateway Portal docs.

    Data stored for the rate limiter

    The rate limiter stores information for limiting requests in the backing Redis database, including the following information.

    • The generated unique key for the request.
    • The associated count against the rate limit.

    For more information, see Rate limiting.

    1. * 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. ↩︎