{
  "schema_version": 2,
  "id": "operate/kubernetes/upgrade/openshift-cli",
  "title": "Upgrade Redis Enterprise with OpenShift CLI",
  "url": "https://redis.io/docs/latest/operate/kubernetes/7.4.6/upgrade/openshift-cli/",
  "summary": "This task describes how to upgrade a Redis Enterprise cluster via OpenShift CLI.",
  "content": "\nRedis implements rolling updates for software upgrades in Kubernetes deployments. The upgrade process includes updating three components:\n\n  1. [Upgrade the Redis Enterprise operator](#upgrade-the-operator)\n  2. [Upgrade the Redis Enterprise cluster (REC)](#upgrade-the-redisenterprisecluster-rec)\n  3. [Upgrade Redis Enterprise databases (REDB)](#upgrade-databases)\n\n## Before upgrading\n\n1. Check [Supported Kubernetes distributions](https://redis.io/docs/latest/operate/kubernetes/reference/supported_k8s_distributions) to make sure your Kubernetes distribution is supported.\n\n2. Use `oc get rec` and verify the `LICENSE STATE` is valid on your REC before you start the upgrade process.\n\n3. 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.\n\n4. When upgrading existing clusters running on RHEL7-based images, make sure to select a RHEL7-based image for the new version. See [release notes](https://redis.io/docs/latest/operate/kubernetes/release-notes) for more info.\n\n5. 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 a later 7.2.4 build.\n\n## Upgrade the operator\n\n### Download the bundle\n\nMake sure you pull the correct version of the bundle. You can find the version tags\nby checking the [operator releases on GitHub](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases)\nor by [using the GitHub API](https://docs.github.com/en/rest/reference/repos#releases).\n\nFor OpenShift environments, the name of the bundle is `openshift.bundle.yaml`, and so the `curl` command to run is:\n\n```sh\ncurl --silent -O https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/openshift.bundle.yaml\n```\n\nIf you need a different release, replace `VERSION` in the above with a specific release tag.\n\n### Apply the bundle\n\nApply 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.\n\n\u003e [!NOTE]\n\u003e If you are not pulling images from Docker Hub, update the operator image spec to point to your private repository.\n\u003e If you have made changes to the role, role binding, RBAC, or custom resource definition (CRD) in the previous version, merge them with the updated declarations in the new version files.\n\nIf you are using OpenShift, run this instead:\n\n```sh\noc apply -f openshift.bundle.yaml\n```\n\nAfter running this command, you should see a result similar to this:\n\n```sh\nrole.rbac.authorization.k8s.io/redis-enterprise-operator configured\nserviceaccount/redis-enterprise-operator configured\nrolebinding.rbac.authorization.k8s.io/redis-enterprise-operator configured\ncustomresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com configured\ncustomresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com configured\ndeployment.apps/redis-enterprise-operator configured\n```\n\n### Reapply the admission controller webhook {#reapply-webhook}\n\nIf you have the admission controller enabled, you need to manually reapply the `ValidatingWebhookConfiguration`.\n\n\u003e [!NOTE]\n\u003e  [Versions 6.4.2 and later](https://redis.io/docs/latest/operate/kubernetes/release-notes/previous-releases/) uses a new `ValidatingWebhookConfiguration` resource to replace `redb-admission`. To use newer releases, delete the old webhook resource and apply the new file.\n\n1. Delete the existing `ValidatingWebhookConfiguration` on the Kubernetes cluster (named `redb-admission`).\n\n        ```sh\n        kubectl delete ValidatingWebhookConfiguration redb-admission\n        ```\n\n1. Apply the resource from the new file.\n\n        ```sh\n        kubectl apply -f deploy/admission/webhook.yaml\n        ```\n        \n\n1. Verify the `admission-tls` secret exists.\n\n    ```sh\n    kubectl get secret admission-tls\n    ```\n  \n    The output should look similar to\n  \n    ```sh\n    NAME            TYPE     DATA   AGE\n    admission-tls   Opaque   2      2m43s\n    ```\n\n1. Save the certificate to a local environment variable.\n\n    ```sh\n    CERT=`kubectl get secret admission-tls -o jsonpath='{.data.cert}'`\n    ```\n\n1. Create a Kubernetes validating webhook, replacing `\u003cnamespace\u003e` with the namespace where the REC was installed.\n\n    The `webhook.yaml` template can be found in [redis-enterprise-k8s-docs/admission](https://github.com/RedisLabs/redis-enterprise-k8s-docs/tree/master/admission)\n\n    ```sh\n    sed 's/OPERATOR_NAMESPACE/\u003cnamespace\u003e/g' webhook.yaml | kubectl create -f -\n    ```\n\n1. Create a patch file for the Kubernetes validating webhook.\n\n    ```sh\n    cat \u003e modified-webhook.yaml \u003c\u003cEOF\n    webhooks:\n    - name: redisenterprise.admission.redislabs\n      clientConfig:\n       caBundle: $CERT\n    EOF\n    ```\n\n1. Patch the webhook with the certificate.\n\n    ```sh\n    kubectl patch ValidatingWebhookConfiguration \\\n        redis-enterprise-admission --patch \"$(cat modified-webhook.yaml)\"\n    ```\n\n\n### Verify the operator is running\n\nYou can check your deployment to verify the operator is running in your namespace.\n\n```sh\noc get deployment/redis-enterprise-operator\n```\n\nYou should see a result similar to this:\n\n```sh\nNAME                        READY   UP-TO-DATE   AVAILABLE   AGE\nredis-enterprise-operator   1/1     1            1           0m36s\n```\n\n\u003e [!WARNING]\n\u003e  We recommend upgrading the REC as soon as possible after updating the operator. After the operator upgrade completes, the operator suspends the management of the REC and its associated REDBs, until the REC upgrade completes.\n\n### Reapply the SCC\n\nIf you are using OpenShift, you will also need to manually reapply the [security context constraints](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`](https://redis.io/docs/latest/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator)) and bind it to your service account.\n\n```sh\noc apply -f openshift/scc.yaml\n```\n\n```sh\noc adm policy add-scc-to-user redis-enterprise-scc-v2 \\\n  system:serviceaccount:\u003cmy-project\u003e:\u003crec-name\u003e\n```\n\nIf you are upgrading from operator version 6.4.2-6 or before, see the [\"after upgrading\"](#after-upgrading) section to delete the old SCC and role binding after all clusters are running 6.4.2-6 or later.\n\n## Upgrade the RedisEnterpriseCluster (REC)\n\n\n\u003e [!WARNING]\n\u003e Verify your license is valid before upgrading. Invalid licenses will cause the upgrade to fail.\n\u003e\n\u003e Use `oc get rec` and verify the `LICENSE STATE` is valid on your REC before you start the upgrade process.\n\nThe 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.\n\nBefore 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](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases/tag/v6.0.12-5), the `Images` section shows the Redis Enterprise tag is `6.0.12-57`.\n\nAfter the operator upgrade is complete, you can upgrade Redis Enterprise cluster (REC).\n\n### Edit `redisEnterpriseImageSpec` in the REC spec\n\n1. Edit the REC custom resource YAML file.\n\n    ```sh\n    oc edit rec \u003cyour-rec.yaml\u003e\n    ```\n\n1. Replace the `versionTag:` declaration under `redisEnterpriseImageSpec` with the new version tag.\n\n    ```YAML\n    spec:\n      redisEnterpriseImageSpec:\n        imagePullPolicy:  IfNotPresent\n        repository:       redislabs/redis\n        versionTag:       \u003cnew-version-tag\u003e\n    ```\n\n1. Save the changes to apply.\n\n### Reapply roles and role bindings\n\nIf your operator is monitoring multiple namespaces, you'll need to [reapply your role and role bindings](https://redis.io/docs/latest/operate/kubernetes/re-clusters/multi-namespace#create-role-and-role-binding-for-managed-namespaces) for each managed namespace. See [Manage databases in multiple namespaces](https://redis.io/docs/latest/operate/kubernetes/re-clusters/multi-namespace) for more details.\n\n### Monitor the upgrade\n\nYou can view the state of the REC with `oc get rec`.\n\n  During the upgrade, the state should be `Upgrade`.\n  When the upgrade is complete and the cluster is ready to use, the state will change to `Running`.\n  If the state is `InvalidUpgrade`, there is an error (usually relating to configuration) in the upgrade.\n\n```sh\n$ oc get rec\nNAME   NODES   VERSION      STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE\nrec    3       6.2.10-107   Upgrade   Valid         Valid           4              2022-07-16T13:59:00Z      92m\n```\n\nTo see the status of the current rolling upgrade, run:\n\n```sh\noc rollout status sts \u003cREC_name\u003e\n```\n\n## After upgrading\n\nFor 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.\n\nIf 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.\n\n1. Delete the old version of the SCC\n\n   ```sh\n   oc delete scc redis-enterprise-scc\n   ```\n\n   The output should look similar to the following:\n\n   ```sh\n   securitycontextconstraints.security.openshift.io \"redis-enterprise-scc\" deleted\n   ```\n\n1. Remove the binding to your service account.\n\n   ```sh\n   oc adm policy remove-scc-from-user redis-enterprise-scc system:serviceaccount:\u003cmy-project\u003e:\u003crec-name\u003e\n   ```\n\n\n## Upgrade databases\n\n\u003e [!WARNING]\n\u003e In version 7.2.4, old module versions and manually uploaded modules are not persisted. If databases are not upgraded after cluster upgrade, and require cluster recovery afterwards, you'll need to contact Redis support. This issue will be fixed in the next maintenance release by moving the stored location of the modules.\n\nAfter 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](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading/upgrade-database), see the [Upgrade an existing Redis Enterprise Software deployment](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading) documentation.\n\nNote that if your cluster [`redisUpgradePolicy`](https://redis.io/docs/latest/operate/kubernetes/reference/redis_enterprise_cluster_api#redisupgradepolicy) or your database [`redisVersion`](https://redis.io/docs/latest/operate/kubernetes/reference/redis_enterprise_database_api#redisversion) are set to `major`, you won't be able to upgrade those databases to minor versions. See [Redis upgrade policy](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading#redis-upgrade-policy) for more details.\n\n\n\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-10-21T09:46:20-07:00"
}