Upgrade Redis Enterprise with OpenShift CLI

This task describes how to upgrade a Redis Enterprise cluster via OpenShift CLI.

Redis implements rolling updates for software upgrades in Kubernetes deployments. The upgrade process includes updating three components:

1. Upgrade the Redis Enterprise operator
2. Upgrade the Redis Enterprise cluster (REC)
3. Upgrade Redis Enterprise databases (REDB)

Before upgrading

1. Check Supported Kubernetes distributions to make sure your Kubernetes distribution is supported.

2. Use oc get rec and verify the LICENSE STATE is valid on your REC before you start the upgrade process.

3. Verify you are upgrading from Redis Enterprise operator version 6.2.10-45 or later. If you are not, you must upgrade to 6.2.10-45 before upgrading to versions 6.2.18 or later.

4. When upgrading existing clusters running on RHEL7-based images, make sure to select a RHEL7-based image for the new version. See release notes for more info.

5. If you want to migrate from RHEL7-based images to RHEL8-based images, you'll need to upgrade to version 7.2.4-2 with a RHEL7-based image, then you'll be able to migrate to a RHEL8-based image when upgrading to 7.2.4-TBD.

Upgrade the operator

Download the bundle

Make sure you pull the correct version of the bundle. You can find the version tags by checking the operator releases on GitHub or by using the GitHub API.

For OpenShift environments, the name of the bundle is openshift.bundle.yaml, and so the curl command to run is:

curl --silent -O https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/openshift.bundle.yaml

If you need a different release, replace VERSION in the above with a specific release tag.

Apply the bundle

Apply the bundle to deploy the new operator binary. This will also apply any changes in the new release to custom resource definitions, roles, role binding, or operator service accounts.

If you are using OpenShift, run this instead:

oc apply -f openshift.bundle.yaml

After running this command, you should see a result similar to this:

role.rbac.authorization.k8s.io/redis-enterprise-operator configured
serviceaccount/redis-enterprise-operator configured
rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator configured
customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com configured
customresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com configured
deployment.apps/redis-enterprise-operator configured

Reapply the admission controller webhook

If you have the admission controller enabled, you need to manually reapply the ValidatingWebhookConfiguration.

1. Verify the admission-tls secret exists.

    kubectl get secret admission-tls
   

   The output should look similar to

    NAME            TYPE     DATA   AGE
    admission-tls   Opaque   2      2m43s
   

2. Save the certificate to a local environment variable.

   CERT=`kubectl get secret admission-tls -o jsonpath='{.data.cert}'`
   

3. Create a Kubernetes validating webhook, replacing <namespace> with the namespace where the REC was installed.

   The webhook.yaml template can be found in redis-enterprise-k8s-docs/admission

   sed 's/OPERATOR_NAMESPACE/<namespace>/g' webhook.yaml | kubectl create -f -
   

4. Create a patch file for the Kubernetes validating webhook.

   cat > modified-webhook.yaml <<EOF
   webhooks:
   - name: redisenterprise.admission.redislabs
     clientConfig:
       caBundle: $CERT
     admissionReviewVersions: ["v1beta1"]
   EOF
   

5. Patch the webhook with the certificate.

   kubectl patch ValidatingWebhookConfiguration \
     redis-enterprise-admission --patch "$(cat modified-webhook.yaml)"
   

Verify the operator is running

You can check your deployment to verify the operator is running in your namespace.

oc get deployment/redis-enterprise-operator

You should see a result similar to this:

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
redis-enterprise-operator   1/1     1            1           0m36s

Reapply the SCC

If you are using OpenShift, you will also need to manually reapply the security context constraints file (scc.yaml) and bind it to your service account.

oc apply -f openshift/scc.yaml

oc adm policy add-scc-to-user redis-enterprise-scc-v2 \
  system:serviceaccount:<my-project>:<rec-name>

If you are upgrading from operator version 6.4.2-6 or before, see the "after upgrading" section to delete the old SCC and role binding after all clusters are running 6.4.2-6 or later.

Upgrade the RedisEnterpriseCluster (REC)

The Redis Enterprise cluster (REC) can be updated automatically or manually. To trigger automatic upgrade of the REC after the operator upgrade completes, specify autoUpgradeRedisEnterprise: true in your REC spec. If you don't have automatic upgrade enabled, follow the below steps for the manual upgrade.

Before beginning the upgrade of the Redis Enterprise cluster, check the K8s operator release notes to find the Redis Enterprise image tag. For example, in Redis Enterprise K8s operator release 6.0.12-5, the Images section shows the Redis Enterprise tag is 6.0.12-57.

After the operator upgrade is complete, you can upgrade Redis Enterprise cluster (REC).

Edit redisEnterpriseImageSpec in the REC spec

1. Edit the REC custom resource YAML file.

   oc edit rec <your-rec.yaml>
   

2. Replace the versionTag: declaration under redisEnterpriseImageSpec with the new version tag.

   spec:
     redisEnterpriseImageSpec:
       imagePullPolicy:  IfNotPresent
       repository:       redislabs/redis
       versionTag:       <new-version-tag>
   

3. Save the changes to apply.

Reapply roles and role bindings

If your operator is monitoring multiple namespaces, you'll need to reapply your role and role bindings for each managed namespace. See Manage databases in multiple namespaces for more details.

Monitor the upgrade

You can view the state of the REC with oc get rec.

During the upgrade, the state should be Upgrade. When the upgrade is complete and the cluster is ready to use, the state will change to Running. If the state is InvalidUpgrade, there is an error (usually relating to configuration) in the upgrade.

$ oc get rec
NAME   NODES   VERSION      STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
rec    3       6.2.10-107   Upgrade   Valid         Valid           4              2022-07-16T13:59:00Z      92m

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

oc rollout status sts <REC_name>

After upgrading

For OpenShift users, operator version 6.4.2-6 introduced a new SCC (redis-enterprise-scc-v2). If any of your OpenShift RedisEnterpriseClusters are running versions earlier than 6.2.4-6, you need to keep both the new and old versions of the SCC.

If all of your clusters have been upgraded to operator version 6.4.2-6 or later, you can delete the old version of the SCC (redis-enterprise-scc) and remove the binding to your service account.

1. Delete the old version of the SCC

   oc delete scc redis-enterprise-scc
   

   The output should look similar to the following:

   securitycontextconstraints.security.openshift.io "redis-enterprise-scc" deleted
   

2. Remove the binding to your service account.

   oc adm policy remove-scc-from-user redis-enterprise-scc system:serviceaccount:<my-project>:<rec-name>
   

Upgrade databases

After the cluster is upgraded, you can upgrade your databases. The process for upgrading databases is the same for both Kubernetes and non-Kubernetes deployments. For more details on how to upgrade a database, see the Upgrade an existing Redis Enterprise Software deployment documentation.

Note that if your cluster redisUpgradePolicy or your database redisVersion are set to major, you won't be able to upgrade those databases to minor versions. See Redis upgrade policy for more details.