Upgrading a Redis Enterprise Cluster in Operator-based Architecture
Redis Labs implements rolling updates for software upgrades in Kubernetes deployments.
Upgrading Redis Enterprise in Operator
- Clone this repository, which contains the deployment files:
git clone https://github.com/RedisLabs/redis-enterprise-k8s-docs
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.
Apply the [bundle.yaml] file (https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/master/bundle.yaml) - (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.
After the Operator and Services Rigger upgrades are complete:
kubectl edit recin the namespace your Redis Enterprise Cluster is deployed in.
- Replace the
redisEnterpriseImageSpecwith 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-22for the Ubuntu-based Redis Enterprise image.
- Save the changes.
If your default text editor is vim then enter
<ESC>:wqto 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
The it updates the next pod until all pods are updated and the upgrade process is completed.