Redis Enterprise for Kubernetes 5.4.10-8 is now available. This release includes the latest version of Redis Enterprise (RS) version 5.4.10-22, and introduces new features & bug fixes.


This is a maintenance release providing support for the latest Redis Enterprise Software release 5.4.10 and includes multiple enhancements.

Follow these instructions for upgrading to the latest Kubernetes Operator release.

New Features

All-in-one deployment bundle and documentation enhancements

This release is the easiest to deploy yet, with a new quick start guide and an all-in-one file bundle for deploying the Redis Enterprise Operator. GitHub documentation was enhanced to cover advanced deployment scenarios with the complete reference to the custom resource specifications, guides, and examples.

Note -
Please pay special attention to the yaml file naming changes and new yaml files that have been created for this release. These are highlighted in the quick start guide.

Rack Awareness

Support for the [Redis Software Rack Awareness][/rs/concepts/high-availability/rack-zone-awareness/] feature was introduced to the Kubernetes deployment. It enables deploying nodes to different zones, in a multi-zone Kubernetes cluster. Databases that are rack-aware will have the cluster populate their master shard and slave shards in different nodes, across different zones or failure domains. This enables maintaining data persistence in case of zone failure.

OLM Support

The Redis Enterprise operator is now RedHat OpenShift certified and can be effortlessly configured and deployed in Kubernetes clusters supporting OLM, including OpenShift 4.x clusters, with just a few clicks. OLM based deployments do not require Kubernetes cluster administrator rights to deploy the operator.

Improve cluster nodes' pod scheduling resiliency

Redis Enterprise Cluster pod scheduling is hardened by implementing Kubernetes best practices and providing configuration recommendations to cluster operators. Scheduling resiliency minimizes the chance of cluster node pods eviction or failure to schedule. See the top 4 articles in the new Additonal Topics documentation section.

Update API version to stable

We've updated the Redis Enterprise Cluster custom resource API from alpha to stable to reflect the current state of maturity of our implementation.

Both versions of the API are supported by Kubernetes versions that support specifying multiple API versions.

For legacy Kubernetes versions, deployment files are available in the documentation repository that utilize the alpha version of the API.


  • This new release deprecates the Redis Enterprise Operator support for legacy Kubernetes version 1.8.

Known Limitations

Custom Resource Definition Changes

In order to comply with OLM best practices, a change was required to the Redis Enterprise Cluster Custom Resource Defintion (CRD) to introduce the status sub-resource. As a result of this change, any upgrade from an older release to this release requires a change to the CRD. Once the CRD is updated, all Redis Enterprise Clusters in the same K8s cluster must be updated to the latest release in order to continue operating properly.

Cluster Recovery

In some cases, pods do not terminate when the statefulSet is scaled down as part of the cluster recovery. If pods are stuck in terminating or crashLoopBack and do not terminate gracefully, cluster recovery can pause.

To work around this, delete the pods manually with:

kubectl delete pods <pod> --grace-period=0 --force

When the last pod is manually deleted, the recovery process resumes.