Skip to content

Redis

Redis is an in-memory key-value store, normally used as a cache or a session store rather than as a system of record. On AWS you would reach for ElastiCache.

Redis is provisioned differently from the other two databases here. PostgreSQL gives you a server per project and MariaDB is shared, but Redis is not shared at all: creating one starts a Redis server of its own inside your project, with its own disk.

Prerequisites

  • A project you can create resources in

The step-by-step guide and the console walkthrough cover the operations. The rest of this page explains how it fits together.

How it fits together

Three objects come out of one create, and the ordering between them matters.

flowchart TB
    subgraph P["your project"]
        direction TB
        SEC["Secret<br/>redis-&lt;instance&gt;<br/>generated password"]
        R["Redis<br/>&lt;instance&gt;"]
        POD["pod &lt;instance&gt;-0"]
        PVC["PersistentVolumeClaim<br/>survives a restart"]
        SVCA["Service &lt;instance&gt;<br/>connect here :6379"]
        SVCB["&lt;instance&gt;-headless"]
        SVCC["&lt;instance&gt;-additional"]
        R -->|redisSecret| SEC
        R --> POD
        POD --> PVC
        R --- SVCA
        R --- SVCB
        R --- SVCC
    end
    APP["your workload"] -->|password from| SEC
    APP -->|connects| SVCA

The Secret is created first and the server points at it. If the Secret is missing the server starts and fails, which is why the create does them in that order.

The password is generated, not chosen

Submitting the form generates a password in your browser, stores it in a Secret named redis-<instance>, and points the server at it. You never type it and it is never shown.

Read it from the Secret when an application needs it, and reference the Secret from your workload rather than copying the value into a manifest.

v1beta2 moved the password out of the spec

Older examples set the password inline in the Redis spec. That is v1beta1. On v1beta2 it comes from a Secret, and an inline password will not apply against this schema.

There is no health status

The Redis operator does not write a status onto the object. The list page therefore has no health column, and an instance appearing there means the object exists - not that the server is running.

To confirm it is up, look for the pod:

oc get pods -n <project> -l app=<instance>

A pod stuck Pending is normally the disk; a pod that starts and restarts is normally the Secret.

What the form does not expose

The image, CPU and memory limits, the storage class and the service type are fixed. A self-service tenant has no reason to tune them, and a wrong storage class silently fails to bind a disk rather than reporting an error.

The service type is ClusterIP, so nothing outside the project can reach the instance.

Deleting the instance leaves the Secret and the disk behind

They are separate objects and do not go with it. The disk keeps costing you until you remove the claim - see Delete.