Redis deployment strategies and suggestions

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. We recommend Bitnami Helm charts for an easy start with Redis on Kubernetes.

• You can choose between two Redis Helm charts:
• Bitnami Redis Helm chart for standalone or master-replica topologies with the configuration option to enable Redis Sentinel.
• Bitnami Redis Cluster Helm chart for Redis Cluster topologies with sharding.

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.

• Bitnami information and Helm chart recources:
• Bitnami package for Redis
• Bitnami Redis Helm charts on Github

After installing the Redis Helm chart with architecture=standalone, you need to configure the CR RedisProvider. The following example assumes that redis is the name of the Helm chart release and the Namespace. The redis-master service is listening on port 6379.

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

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 Sentinal acts as a source of authority for clients, allowing your Airlock Microgateway to address the current master.

0. 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 Sentinal automatically promotes one of the slaves to become master, then makes the other additional slaves use the new master.
• Bitnami information and Helm chart recources:
• Bitnami package for Redis
• Bitnami Redis Helm charts on Github

After installing the Redis Helm chart with architecture=replication and sentinel.enabled=true, you need to configure the CR RedisProvider. The following example assumes that redis is the name of the Helm chart release and the Namespace. 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).

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

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.

• Bitnami information and Helm chart recources:
• Bitnami package for Redis Cluster
• Bitnami Redis Cluster Helm charts on Github

• As for the Redis Cluster Helm configuration, you need to obtain the following:
• In Kubernetes, IPs are not static. For TLS and SAN certificate validation in the Redis Cluster, the environment variables of the Redis Cluster Helm chart must, therefore, be configured with hostnames instead of IPs. For details, see the GitHub issue ticket about DNS hostnames to support TLS host certificate SAN validation.
• The following additional environment variables need to be set for our example configuration:


extraEnvVars:
    - name: REDIS_CLUSTER_ANNOUNCE_HOSTNAME
      value: "$(POD_NAME).redis-cluster-headless.redis.svc.cluster.local"
    - name: REDIS_CLUSTER_DYNAMIC_IPS
      value: "yes"
    - name: REDIS_CLUSTER_PREFERRED_ENDPOINT_TYPE
      value: "hostname" 

After installation, you need to configure the CR RedisProvider. The following example assumes that redis is the name of the Helm chart release and the Namespace. The redis-master service is listening on port 6379.

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

The following configuration combination is currently unsupported for Redis Cluster and Sential mode:

   tls:
    certificateVerification:
      custom: null
      disabled: {}

While TLS and client authentication are enabled in Redis with valid server and client certificates, the above CR RedisProvider configuration does not specify a server certificate. Also, it disables the certificate verification so that every certificate is trusted.

• API Reference:
• CR RedisProvider reference documentation
• CR SessionHandling reference documentation