Redis Labs implements rolling updates for software upgrades in Kubernetes deployments.

Upgrading Redis Enterprise in Operator

  1. Clone this repository, which contains the deployment files:
git clone

Example response:

Cloning into 'redis-enterprise-k8s-docs'...
remote: Enumerating objects: 37, done.
remote: Counting objects: 100% (37/37), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 168 (delta 19), reused 9 (delta 7), pack-reused 131
Receiving objects: 100% (168/168), 45.32 KiB | 7.55 MiB/s, done.
Resolving deltas: 100% (94/94), done.
  1. Apply the [bundle.yaml] file ( - (or openshift.bundle.yaml file if running OpenShift)

    Note -
    If you are not pulling images from Docker Hub, update the operator Image spec to point to your private repository. If you have made changes to the role, role binding, rbac or crd in the previous version you must merge them with the updated declarations in the new version files.
  2. After the Operator and Services Rigger upgrades are complete:

    1. Run kubectl edit rec in the namespace your Redis Enterprise Cluster is deployed in.
    2. Replace the image: declaration under redisEnterpriseImageSpec with the new version tag provided in the release documentation.

    For example, in Operator release 5.4.10-8 the tag is redislabs/redis:5.4.10-22 for the Ubuntu-based Redis Enterprise image.

    1. Save the changes. If your default text editor is vim then enter <ESC>:wq to save the file.

The rolling upgrade of the cluster nodes' statefulSet starts.

To see the status of the current rolling upgrade, run:

kubectl rollout status sts

How Does the Upgrade Work?

Rolling updates allow you to update deployments with zero downtime by incrementally updating Redis Enterprise Cluster instances in the pods with new instances.

These diagrams show how a rolling update works:

  • Each hexagon represents a node
  • Each box represents a pod


The pods are updated one by one in the diagram, starting from left to right. Each pod is updated after the last one completes successfully.




The pods in the StatefulSet are updated in reverse ordinal order. The Kubernetes controller terminates each pod and waits for it to transition to Running and then to Ready. The it updates the next pod until all pods are updated and the upgrade process is completed.