About

When you install Gloo Mesh Core, you can choose to set up a local, built-in Redis®* 1 instance by default.

About the built-in Redis instances

The following table describes the built-in Redis instances that are created for you when you enable the Helm field during the installation.

Helm nameRedis deployment nameNamespaceGloo component that uses RedisDescription
redisredisgloo-meshManagement server, agent, insights engine, UIThe default configuration path for the control plane that is still supported for ease of setup and upgrades. As of version 2.6, you can alternatively use the redisStore sections for snapshot and insights to configure separate Redis instances for these use cases.
redisStore.insightsgloo-redis-insightsgloo-meshInsights engine, UIInsights that provide information about your service mesh environment.
redisStore.snapshotgloo-redis-snapshotgloo-meshManagement server, agent, insights engine, UIInput and output snapshots of the configuration for all the resources in your environment.

Step 1: Enable built-in Redis

Through Helm, you can configure Redis to store the data for several Gloo Mesh Core components, as described in About Redis. After, Gloo deploys a Redis instance for each one based on the details that you configure.

When you install or upgrade Gloo Mesh Core, include the following Helm values to enable the deployment of a built-in Redis instance. The following subsections cover use cases for having a separate control plane and data plane (the preferred minimum configuration), sharing the same instance across all usages, or having separate instances for all usages.

Option 1: Shared instance for all usages

You have two options for a shared instance for both snapshot and insights usage:

  • redis: The redis section of the Helm chart is enabled by default unless you explicitly disable it. Gloo deploys a redis instance that the management server, insights engine, and UI are automatically configured to use. This configuration path is still supported for ease of setup and upgrades. You can point all the redisStore components to this Redis instance.
  • redisStore: Enable one of the redisStore components, such as snapshot. Then, point all the other sections to the enabled section. This configuration path is available as of Gloo Mesh Core version 2.6. You might want to use this approach to standardize the way that you write the Redis store configuration across the control plane and data plane components.
  
redis:
  deployment:
    # Enable the creation of the local Redis deployment and service.
    enabled: true
redisStore:
  insights:
    # Disable the creation of the local Redis deployment and service.
    deployment:
      enabled: false
      # Point the insights component to the service of the default Redis instance.
      client:
        address: redis.gloo-mesh:6379
  snapshot:
    # Enable the creation of the local Redis deployment and service.
    deployment:
      enabled: false
      # Point the snapshot component to the service of the default Redis instance.
      client:
        address: redis.gloo-mesh:6379
  
  
redis:
  deployment:
    # Disable the creation of the local Redis deployment and service,
    # so that you can use the redisStore configuration path instead.
    enabled: false
redisStore:
  insights:
    # Disable the creation of the local Redis deployment and service.
    deployment:
      enabled: false
      # Point the insights component to the service of the snapshot Redis instance.
      client:
        address: gloo-redis-snapshot.gloo-mesh:6379
  snapshot:
    # Enable the creation of the local Redis deployment and service.
    deployment:
      enabled: true

Option 2: Separate instances for all usages

Enable each built-in Redis instance separately. Note that you must also disable the default redis configuration section so that the control plane is not set up to use the legacy redis deployment.

  
redisStore:
  insights:
    # Enable the creation of the local Redis deployment and service.
    deployment:
      enabled: true
  
  
redis:
  deployment:
    # Disable the creation of the local Redis deployment and service,
    # so that you can use the redisStore configuration path instead.
    enabled: false
  
  
redisStore:
  snapshot:
    # Enable the creation of the local Redis deployment and service.
    deployment:
      enabled: true

Step 2: Add persistent storage

For more highly available setups, configure persistent storage for the built-in Redis instance. For more information, see Persistent storage.

In the deployment.persistence section for each stanza of the redisStore, configure the settings to use persistence for the built-in Redis instance that backs the Gloo Mesh Core components.

  
  deployment:  
    enabled: true
    persistence:
      enabled: true
      persistentVolume:
        existingClaim: false
        name: gloo-mesh-redis
        storageClass: ""
        accessModes:
        - ReadWriteOnce
        size: "1Gi"
      aof:
        appendfsync: everysec
        enabled: false    
      rdb:
        saveSnapshot: "60 1000"
Review the following table to understand this configuration.
SettingDescription
deploymentThe section to configure the deployment details of the built-in Redis instance. For information about options other than persistence, review the Helm reference docs.
persistenceThe section to configure persistent storage for the local Redis instance so that data persists across pod restarts. Note that data does not persist across node or zonal failures. To set up persistence for such scenarios, you can bring your own Redis instance.
enabledSet to true so that the built-in Redis stores data in a Kubernetes persistent volume (PV). The default value is false.
persistentVolumeThe section to configure the details of the PVC that binds to the PV to back your local Redis instance.
existingClaimTo use an existing PVC, set this value to true and leave the remaining fields in the persistentVolume section blank. The default value is false so that you can configure a PVC that can dynamically provision a PV.
nameThe name of the PVC for the Redis deployment to mount as a volume. The default value is gloo-mesh-redis.
storageClassThe storage class of the PVC. If you leave this value blank, as in the example, then the default storage class is used. To disable dynamic provisioning, set this value to "-". If you disable dynamic provisioning, note that you must manually create the PV that binds to the PVC through static provisioning. To list available storage classes in your cluster, run kubectl get storageclasses. For more info, see the Kubernetes docs.
accessModeThe access modes of the PVC. Possible values are ReadWriteOnce, ReadOnlyMany, ReadWriteMany, or ReadWriteOncePod. For more info, see the Kubernetes docs.
sizeThe size of storage capacity that the PVC requests. For more info, see the Kubernetes docs. Storage capacity requests depend on the size of your environment, but the following example values provide a rough guideline:
  • 1Gi for a small environment (3 clusters, < 1,000 services)
  • 2Gi to 5Gi for a medium environment (10 clusters, < 4,000 services)
  • 10Gi or larger for a large environment (> 10 clusters, > 5,000 services)
aofThe section to configure Redis with Append Only File (AOF) persistence mode. AOF logs every write operation for a more complete recovery option, but has trade-offs in resource usage which can impact performance vs. RDB. For more info, see the Redis docs.
appendfsyncConfigure how often data is saved from the in-memory database to the disk. Options are ’everysec’, ‘always’, or ’no’. The example uses the default value, ’everysec'.
enabledSet to true to use AOF (AOF) persistence mode. In this example, the value is set to false, so AOF is not used.
rdbThe section to configure Redis with Redis Database (RDB) persistence mode. RDB provides a point-in-time snapshot for a disaster recovery backup, but has trade-offs in the completeness of data vs. AOF. For more info, see the Redis docs. In the example, the rdb section is present, so the mode is enabled.
saveSnapshotConfigure how often an RDB snapshot is created. The format is ‘N M’, where N is the number of seconds and M is the minimum number of changes in the dataset. For example, enter ‘60 1000’ to take a snapshot every 60 seconds when at least 1000 keys are changed since the last snapshot.

Step 3: Configure API key details for the developer portal

If you use the developer portal, configure details related to storing API keys in the Redis instance for the external auth service. By default, the configuration that you set for redisStore.extAuthService is also used by the portal server. This way, the portal server can write API keys that protect the APIs exposed in the developer portal, and the external auth service can read the same API keys to authenticate requests.

  • redisStore.extAuthService.client.secretKey: Replace with a random string to use to hash the API keys that are stored in Redis. The example uses "ThisIsSecret".
  
redisStore:
  extAuthService:
    client:
      secretKey: "ThisIsSecret"

Step 4: Configure more details

Further configure the default Redis values. For specific fields and more information, check the Helm reference for each component of the redisStore section.

Common configuration sections include:

  • Client connection details, such as redirects, retries, and max connections.
  • Deployment details, such as to modify the Kubernetes deployment’s resource limits and requests for the built-in Redis instance.
  • Deployment sidecar details, if you want to run the Redis deployment as a sidecar to an existing Redis instance instead of its own.
  • Deployment image details, particularly if you store the Solo-provided images in your own private registry and create an image pull secret for an air-gapped installation.
  • Persistence details, as described in the previous section.

Step 5: Verify the connection

To review the data that is stored in Redis, you can connect to the local Redis instance. If you bring your own Redis, you must use those connection values. For more information, see your Redis provider docs, such as Amazon ElastiCache or Google Cloud Memorystore.

Choose between using the Redis CLI or RedisInsights.

Redis CLI

You can use the Redis CLI that is built into your deployment to review the data in your database.

  1. Install Redis in your cluster so that you can use the redis-cli to connect to your Redis instance.

    When you install Gloo Mesh Core with the default settings, Redis is installed in the cluster for you. You can skip this step.

    To connect to your own local Redis instance, make sure to get its details, such as my-redis in a redis namespace, as well as any authentication details.

    To connect your own external Redis in a cloud instance, such as AWS ElastiCache:

    1. Deploy the Redis CLI, such as with the following simple deployment. For more information, see the Redis docs.

        kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cli
  labels:
    app: redis-cli
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis-cli
  template:
    metadata:
      labels:
        app: redis-cli
    spec:
      containers:
      - name: redis-cli
        image: redis:latest
        command: ["sleep", "infinity"]  # Keeps the container running indefinitely
EOF

    2. Verify that you can access the Redis pod by logging into the pod.

        kubectl exec -it deploy/redis-cli -- /bin/sh

    3. Optional: For TLS connections that use a public CA, such as for AWS ElastiCache, make sure that the Redis CA certificates are up to date.

         apt-get install ca-certificates

    4. Verify that the CA certificates are installed.

        ls /etc/ssl/certs

      Example truncated output:

        002c0b4f.0
02265526.0
...
Amazon_Root_CA_1.pem
Amazon_Root_CA_2.pem
Amazon_Root_CA_3.pem
Amazon_Root_CA_4.pem
...

  2. From your terminal, log in to the Redis pod and open a Redis CLI shell.

    You can open a Redis CLI shell session by logging in to the Redis instance in the gloo-mesh namespace, such as gloo-mesh-redis which backs the Gloo management server and UI.

      kubectl exec -n gloo-mesh deploy/gloo-mesh-redis -it -- redis-cli

    You can open a Redis CLI shell session by logging in to the Redis instance in the add-ons namespace, such as redis in the gloo-mesh namespace, which backs the rate limiter, external auth, or portal server add-ons.

      kubectl exec -n gloo-mesh deploy/redis -it -- redis-cli

    You can open a Redis CLI shell session by logging into the Redis pod with the details that you got in the previous step. Include the --tls flag if your Redis instance enforces a TLS connection. Include the -a flag with your password if your Redis instance enforces auth.

      kubectl exec -n redis deploy/my-redis -it -- redis-cli --tls -a 'my-password'

    You can open a Redis CLI shell session by logging into the redis-cli pod that you deployed in the previous step. Update the host with your cloud instance details. Include the --tls flag if your Redis instance enforces a TLS connection. Include the -a flag with your password if your Redis instance enforces auth.

      kubectl exec -n default deploy/redis-cli -it -- redis-cli -h master.<my-redis>.abcdefg.use2.cache.amazonaws.com --tls -a 'my-password' -p 6379

  3. Run Redis CLI commands, such as monitor or keys. For more information, see the Redis docs.

    Example response of data populated by the management server:

      keys *
1) "$CLUSTER_NAME~apps~v1~Deployment"
2) "reports#$CLUSTER_NAME#httpbin#$CLUSTER_NAME"
3) "$CLUSTER_NAME~install.istio.io~v1alpha1~IstioOperator"
4) "reports#$CLUSTER_NAME#gloo-mesh#globalcccfde00-e4a9-4867-b6c0-5df8601f6e1e"
5) "$CLUSTER_NAME~admissionregistration.k8s.io~v1~MutatingWebhookConfiguration"
6) "reports#idx"
7) "reports#$CLUSTER_NAME#store#$CLUSTER_NAME"
8) "gloo.mesh.key.set"

    Example response of rate limit counters:

      monitor
OK
1681223733.198361 [0 10.xxx.x.x:xxxxx] "INCRBY" "tree|solo.io|generic_key^gloo-mesh.rl-server-config-gloo-mesh-$CLUSTER_NAME-rate-limiter|generic_key^counter|1718236800" "1"

    Example response of API keys for the external auth service and portal server add-ons. Note that the API key name and value are hashed based on the apiKeyStorage.secretKey that you configured when setting up the add-ons.

      keys *
1) "1bbe3f25-5a2a-4797-8ac0-d59c7480377a"
2) "abcmHk2Iwcy3VL+NNswyrs3B4YIEx39BG84jzwcoWB8="

get "1bbe3f25-5a2a-4797-8ac0-d59c7480377a"
"xksmHk2Iwcy3VL+NNswyrs3B4YIEx39BG84jzwcoWB8="

get "abcmHk2Iwcy3VL+NNswyrs3B4YIEx39BG84jzwcoWB8="
"{\"api_key\":\"abcmHk2Iwcy3VL+NNswyrs3B4YIEx39BG84jzwcoWB8=\",\"labels\":[\"first.last@example.com\"],\"metadata\":{\"config_id\":\"gloo-mesh.api-key-auth-default-cluster-name-mgt-ext-auth-service\",\"created-ts-unix\":\"1718742070\",\"name\":\"gold-api-key-name\",\"usagePlan\":\"gold\",\"username\":\"first.last@example.com\"},\"uuid\":\"1bbe3f25-5a2a-4797-8ac0-d59c7480377a\"}"

RedisInsights

RedisInsights is a desktop application that you can install for UI- and CLI-based interactions. For more information, see the Redis docs.

  1. Install RedisInsights. The steps vary depending on where you want to install the app.
  2. Enable port forwarding on the Redis deployment. Update the namespace and deployment to match the Redis instance in your cluster.
      kubectl port-forward -n gloo-mesh deploy/gloo-mesh-redis 6379
  3. Launch the RedisInsights app.
  4. Click + Add Redis Database and enter in your localhost and port details, which by default are 127.0.0.1:6379.
  5. Click the database that you just added.
  6. Use the UI or CLI to explore the data. For example, you can click the Browser tab (the key icon) and toggle the Key view to explore all of the keys in the database instance, as shown in the following screenshot.

RedisInsights view of all keys in the database
RedisInsights view of all keys in the database

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