Redis deployment strategies

This article provides assistance and recommendations for three different Redis deployment topologies, including short descriptions and brief reference and installation information. We also share our findings and pitfalls as additional remarks.

Simple Redis deployment

Redis in standalone topology mode may be used when high availability is not required. It is quick and easy to implement with a single exposed service - ideal for development and testing. In this mode, Redis Sentinel is deactivated.

After installing Redis, you need to configure the CR RedisProvider. The following example assumes that redis is deployed in the Namespace redis and theredis-masterservice is listening on port 6379.

 
Example
apiVersion: microgateway.airlock.com/v1alpha1 
kind: RedisProvider 
metadata: 
  name: example-backend 
spec: 
  mode: 
    standalone: 
      host: redis-master.redis.svc.cluster.local 
      port: 6379

Redis Sentinel

A Redis Sentinel is a high-availability system designed to help manage Redis instances when not using Redis Cluster. The topology architecture consists of Redis instances with Redis Sentinel mode activated in the configuration option. A group of Redis Sentinel instances work together to achieve automatic failover for master and replica instances. Redis Sentinel acts as a source of authority for clients, allowing your Airlock Microgateway to address the current master.

Redis Sentinel performs three tasks:

  1. It monitors to check if your master and slave Sentinel instances are working as expected.
  2. It notifies other programs or the administrator via an API when something is wrong with the monitored instances.
  3. It manages automatic failover on master failure. In this case, Redis Sentinel automatically promotes one of the slaves to become master, then makes the other additional slaves use the new master.

After installing Redis, you need to configure the CR RedisProvider. The following example assumes that redis is deployed in the Namespace redis and the redis-sentinel-headless service is listening on port 26379. The DNS records allow your Airlock Microgateway to address other Sentinel nodes if one node fails (e.g., unreachable IP).

 
Example
apiVersion: microgateway.airlock.com/v1alpha1 
kind: RedisProvider 
metadata: 
  name: example-backend 
spec: 
  mode: 
    sentinel: 
      masterName: redis-master 
      nodes: 
        - host: redis-sentinel-headless.redis.svc.cluster.local 
          port: 26379

Redis Cluster with sharding

A Redis Cluster is a horizontally scaling, high-availability deployment strategy. Similar to Redis Sentinel, this topology provides failover, monitoring, etc. The difference is the sharding capability, which allows almost linear capacity scaling.

After installation, you need to configure the CR RedisProvider. The following example assumes that redis is deployed in the Namespace redis and the redis-master service is listening on port 6379.

 
Example
apiVersion: microgateway.airlock.com/v1alpha1
kind: RedisProvider
metadata:
  name: example-backend
spec:
  mode:
    cluster:
      nodes:
        - host: redis-cluster-headless.redis.svc.cluster.local
          port: 6379

Unsupported Redis Sentinel and Cluster mode configuration

The following configuration attempts to disable verification of the server certificate, while simultaneously requiring client authentication via a client certificate. This configuration is not supported in Sentinel and Cluster mode.

 
Example
  tls:
    certificateVerification:
      disabled: {}
    clientCertificate:
      secretRef:
        name: client-certificate