使用 OpenShift CLI 升级 Redis Enterprise

此任务介绍如何通过 OpenShift CLI 升级 Redis Enterprise 集群。

适用于 Kubernetes 的 Redis Enterprise

Redis 在 Kubernetes 部署中为软件升级实施滚动更新。升级过程包括更新三个组件：

  1. 升级 Redis Enterprise operator
  2. 升级 Redis Enterprise 集群 （REC）
  3. 升级 Redis Enterprise 数据库 （REDB）

先决条件

以下步骤可确保您拥有升级到 7.8.2-6 或更高版本所需的所有组件的最低版本。如果没有这些最低版本，升级将冻结并需要手动恢复。

请参阅 故障排除 部分，了解有关恢复失败升级的详细信息。

Kubernetes 版本

检查支持的 Kubernetes 发行版，确保您的 Kubernetes 发行版受支持。如果没有，请在升级 Redis Operator 之前升级您的 Kubernetes 发行版。

Redis 运算符版本

在升级到 7.8.2-6 或更高版本之前，您的 Redis Enterprise 集群必须运行版本 7.4.2-2 或更高版本。有关详细步骤，请参阅 7.4 升级。

Redis 数据库版本

在升级集群版本之前，您的 Redis 数据库必须运行版本 7.2 或更高版本。有关详细步骤，请参阅升级数据库。您可以在红spec.redisVersion田.

RHEL9 兼容模块

升级到 Redis作员版本 7.8.2-6 及更高版本涉及将 Redis Enterprise 节点从 Ubuntu 18 或 RHEL8 迁移到 RHEL9。如果您的数据库使用模块，则需要手动安装与 RHEL9 兼容的模块。

要查看已安装的模块，请运行：

curl -k -u <rec_username>:<rec_password> -X GET https://localhost:9443/v1/modules | jq -r 'map([.module_name, .semantic_version, (.platforms | keys)]) | .[] | .[0] as $name | .[1] as $version | .[2][] | $name + "-" + $version + "-" + .' | sort

To see which modules are currently in use, run:

curl -k -u <rec_username>:<rec_password> -X GET https://localhost:9443/v1/bdbs | jq -r '.[].module_list | map(.module_name + "-" + .semantic_version) | .[]'

See Upgrade modules for details on how to upgrade modules with the rladmin tool.

Valid license

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

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.

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 custom resource definition (CRD) in the previous version, merge them with the updated declarations in the new version files.

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.

Note:

Versions 6.4.2 and later uses a new ValidatingWebhookConfiguration resource to replace redb-admission. To use newer releases, delete the old webhook resource and apply the new file.

  1. Delete the existing ValidatingWebhookConfiguration on the Kubernetes cluster (named redb-admission).

     ```sh
 kubectl delete ValidatingWebhookConfiguration redb-admission
 ```

  2. Apply the resource from the new file.

     ```sh
 kubectl apply -f deploy/admission/webhook.yaml
 ```

  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
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
Warning:
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.

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 Redis Enterprise Cluster

Warning:

Verify your license is valid before upgrading. Invalid licenses will cause the upgrade to fail.

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

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.

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

Edit redisEnterpriseImageSpec

  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>

Upgrade databases

After the cluster is upgraded, you can upgrade your databases. Specify your new database version in the spec.redisVersion field for your REDB and REAADB custom resources. Supported database versions include "7.2" and "7.4" (note this value is a string).

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.

Troubleshooting

If you start an upgrade without meeting the prerequisites, the operator will freeze the upgrade. Check the operator logs for the source of the error. The REDB reconsilliation doesn't work during an upgrade, so you need to apply a manual fix with the Redis Software API (examples below). The updates will also need to be added to the REDB custom resource.

Invalid module version

If the operator logs show an event related to an unsupported module, download the updated module locally, and install it using the v2/modules API endpoint.

curl -sfk -u <rec_username>:<rec_password> -X POST -F 'module=@<full path to your module>' https://localhost:9443/v2/modules

After updating the modules with the Redis Software API, update the REDB custom resource to reflect the change.

Invalid database version

If the operator logs show an event related to an incompatible database version, upgrade the database using the Redis Software API.

curl -sfk -u <rec_username>:<rec_password> -X POST -H "Content-Type: application/json" -d '{"redis_version": <target redis version>}' https://localhost:9443/v1/bdbs/<BDB UID>/upgrade

After updating the database with the Redis Software API, update the REDB custom resource to reflect the change.

RATE THIS PAGE
Back to top ↑