From eee4bc21c2dda85b156f7e7797735f6a1c71a5fa Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Tue, 7 Jul 2026 14:12:06 +0100 Subject: [PATCH 1/4] DOC-6816 Document smart client handoffs (SCH) for Redis Enterprise on Kubernetes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a networking page for enabling SCH on a K8s REC, plus supporting edits to the SCH overview, the networking index, and the REST API cluster-object reference. The enablement steps, the MONITOR-handshake verification, and the two notification flags come from David Maier's Slack/Google doc rather than any released reference. The load-bearing surprise: oss_cluster_client_maint_notifications does not appear in the release notes or the REST API cluster object docs, so I documented it from the source doc and added the reference row myself. Enablement is via the REST API on purpose (a temporary workaround) because the REC cluster spec does not yet expose these settings. The page is deliberately scoped to the same-pod-network / IP-based / no-TLS case; the external/TLS/name-based scenario is a TODO in the source doc, not an oversight. Learned: SCH-for-K8s config sourced from David's doc; the key OSS flag is undocumented upstream Gaps: oss_cluster_client_maint_notifications absent from release notes and REST API reference before this change; unconfirmed whether standalone on 8.0.2-17 accepts it, or whether OSS mode needs both flags — needs eng sign-off Recheck: when the REC cluster spec exposes SCH settings, replace the REST API enablement workaround Directive: external/TLS/name-based SCH is intentionally deferred (source doc TODO) — do not treat its absence as a gap Ticket: DOC-6816 Co-Authored-By: Claude Opus 4.8 (1M context) --- content/develop/clients/sch.md | 2 +- .../operate/kubernetes/networking/_index.md | 6 ++ .../networking/smart-client-handoffs.md | 92 +++++++++++++++++++ .../rest-api/objects/cluster/_index.md | 1 + 4 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 content/operate/kubernetes/networking/smart-client-handoffs.md diff --git a/content/develop/clients/sch.md b/content/develop/clients/sch.md index a8e50de420..0ea5064ab5 100644 --- a/content/develop/clients/sch.md +++ b/content/develop/clients/sch.md @@ -117,7 +117,7 @@ the specific upgrade method you use, as detailed in the table below. ### Redis Enterprise for Kubernetes -SCH is not currently supported for [Kubernetes]({{< relref "/operate/kubernetes" >}}) clusters. +SCH is supported for [Redis Enterprise for Kubernetes]({{< relref "/operate/kubernetes" >}}) when your application and the Redis Enterprise cluster run within the same Kubernetes pod network. As with Redis Software, you enable SCH using the REST API. See [Enable smart client handoffs (SCH)]({{< relref "/operate/kubernetes/networking/smart-client-handoffs" >}}) for instructions. ### Redis Open Source diff --git a/content/operate/kubernetes/networking/_index.md b/content/operate/kubernetes/networking/_index.md index 34e9b806d0..2f932ce6f0 100644 --- a/content/operate/kubernetes/networking/_index.md +++ b/content/operate/kubernetes/networking/_index.md @@ -48,6 +48,12 @@ This feature only supports automatic Ingress creation for Active-Active database See [Enable cluster-aware clients (OSS Cluster API)]({{< relref "/operate/kubernetes/networking/cluster-aware-clients" >}}) for configuration details. +## Smart client handoffs + +[Smart client handoffs]({{< relref "/operate/kubernetes/networking/smart-client-handoffs" >}}) (SCH) let the cluster notify clients about planned maintenance so they can reconnect gracefully during upgrades. SCH is supported when your application and the Redis Enterprise cluster run within the same Kubernetes pod network. + +See [Enable smart client handoffs (SCH)]({{< relref "/operate/kubernetes/networking/smart-client-handoffs" >}}) for configuration details. + ## REC domain name The RedisEnterpriseCluster does not support custom domain names. Domain names for the REC are in the following format: `..svc.cluster.local`. diff --git a/content/operate/kubernetes/networking/smart-client-handoffs.md b/content/operate/kubernetes/networking/smart-client-handoffs.md new file mode 100644 index 0000000000..b877c47d39 --- /dev/null +++ b/content/operate/kubernetes/networking/smart-client-handoffs.md @@ -0,0 +1,92 @@ +--- +Title: Enable smart client handoffs (SCH) +alwaysopen: false +categories: +- docs +- operate +- kubernetes +description: Enable smart client handoffs (SCH) to avoid client disruptions during Redis Enterprise cluster maintenance and upgrades on Kubernetes. +linkTitle: Smart client handoffs +weight: 98 +--- + +[Smart client handoffs]({{< relref "/develop/clients/sch" >}}) (SCH) let a Redis Enterprise cluster notify clients about planned maintenance shortly before it happens, so clients can reconnect or otherwise respond gracefully without significant interruptions in service. SCH is primarily useful during server software or hardware upgrades, where it provides *relaxed timeouts* and transparent *pre-handoffs* to new endpoints. See [Smart client handoffs]({{< relref "/develop/clients/sch" >}}) for a full description of the feature. + +This page describes how to enable SCH for a Redis Enterprise cluster (REC) running on Kubernetes when your application and the cluster run within the same Kubernetes pod network, using IP-based access without TLS. External access over TLS with name-based addressing is not yet covered. + +## Prerequisites + +You need a RedisEnterpriseCluster (REC) running a version of Redis Enterprise Software that supports SCH: + +- Redis Enterprise Software 8.0.2-17 or later for standalone (Enterprise cluster mode) connections. +- Redis Enterprise Software 8.0.16-29 or later for [OSS Cluster API]({{< relref "/operate/rs/databases/configure/oss-cluster-api" >}}) connections. + +In your application code, you need a client library that supports SCH (see [SCH support in Redis client libraries]({{< relref "/develop/clients/sch#sch-support-in-redis-client-libraries" >}}) for +more information). + +## Get the cluster credentials + +The cluster's admin username and password are stored in a Kubernetes secret named after your cluster. Retrieve and decode them so you can authenticate REST API requests: + +```sh +kubectl get secret -o jsonpath='{.data.username}' | base64 --decode +kubectl get secret -o jsonpath='{.data.password}' | base64 --decode +``` + +## Enable SCH + +Use the [`/v1/cluster`]({{< relref "/operate/rs/references/rest-api/requests/cluster#put-cluster" >}}) REST API request to enable SCH for both Enterprise cluster mode and OSS Cluster API mode. Set `client_maint_notifications` and `oss_cluster_client_maint_notifications` to `true`. + +The following example uses [`curl`](https://curl.se/) and addresses the cluster REST API on port `9443` of the REC service (for example, `rec` in a cluster named `rec`): + +```sh +curl -k -X PUT -H "accept: application/json" \ + -H "content-type: application/json" \ + -u ":" \ + -d '{ "client_maint_notifications": true, "oss_cluster_client_maint_notifications": true }' \ + https://:9443/v1/cluster +``` + +The REST API service uses a `ClusterIP` and is reachable only from within the Kubernetes pod network. Run the command from a pod in the cluster, or use [`kubectl port-forward`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#port-forward) to forward a local port to the service and address `https://localhost:9443/v1/cluster` instead: + +```sh +kubectl port-forward service/ 9443:9443 +``` + +## Verify the handshake + +When a client connects with SCH enabled, the server sends a `CLIENT MAINT_NOTIFICATIONS` handshake command. You can observe it with the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. + +For a standalone (Enterprise cluster mode) client, the handshake includes the moving-endpoint type: + +``` +CLIENT MAINT_NOTIFICATIONS ON moving-endpoint-type internal-ip +``` + +The `moving-endpoint-type internal-ip` value means the server pushes the internal (pod) IP changes up to the client. In Enterprise cluster mode, the server can push `FAILING_OVER`, `FAILED_OVER`, `MIGRATING`, `MIGRATED`, and `MOVING` messages to the client. + +For a client using the OSS Cluster API, the handshake does not include the moving-endpoint type: + +``` +CLIENT MAINT_NOTIFICATIONS ON +``` + +The handshake differs because OSS Cluster API mode aligns with the configuration that determines the output of [`CLUSTER SHARDS`]({{< relref "/commands/cluster-shards" >}}), which contains the internal node IP addresses by default. In this mode, the server pushes `SMIGRATING` and `SMIGRATED` messages to the client. The `SMIGRATED` message carries information about topology changes, including the updated internal IP addresses. + +## Validate SCH during an upgrade + +To confirm that SCH reduces disruption during maintenance, [upgrade the Redis Enterprise cluster]({{< relref "/operate/kubernetes/upgrade" >}}), which adds and removes nodes as the operator performs a rolling upgrade of the pods. + +1. Make sure both the source and target Redis Enterprise Software versions support SCH. +1. Enable SCH as described above. +1. Connect your clients and set their log level to `DEBUG`. +1. Start the upgrade and watch the client debug output: + - For a standalone (Enterprise cluster mode) client, look for the `MOVING` messages that redirect the client to the new endpoint. + - For an OSS Cluster API client, look for the `SMIGRATED` messages that carry the updated cluster topology. + +## Related topics + +- [Smart client handoffs]({{< relref "/develop/clients/sch" >}}) - Feature overview and client library support +- [Enable cluster-aware clients (OSS Cluster API)]({{< relref "/operate/kubernetes/networking/cluster-aware-clients" >}}) - Route requests directly with cluster-aware clients +- [Database connectivity]({{< relref "/operate/kubernetes/networking/database-connectivity" >}}) - In-cluster and external database access +- [Upgrade Redis Enterprise for Kubernetes]({{< relref "/operate/kubernetes/upgrade" >}}) - Cluster and database upgrade procedures diff --git a/content/operate/rs/references/rest-api/objects/cluster/_index.md b/content/operate/rs/references/rest-api/objects/cluster/_index.md index 3844aab776..7f8a99e701 100644 --- a/content/operate/rs/references/rest-api/objects/cluster/_index.md +++ b/content/operate/rs/references/rest-api/objects/cluster/_index.md @@ -68,6 +68,7 @@ An API object that represents the cluster. | multi_commands_opt | **"disabled"**
"batch"
"force_disabled" | Determines the default `multi_commands_opt` setting for databases in the cluster. If set to `batch`, it reduces the overhead of transaction management by batching multiple commands into a single transaction.
Values:
**disabled**: Turns off the optimization for all databases except those that override it on the [bdb level]({{}}). Default value.
**batch**: Enables the optimization on all databases except those that override it on the [bdb level]({{}}).
**force_disabled**: Disables the optimization for all databases, even those that override it on the [bdb level]({{}}). | | name | string | Cluster's fully qualified domain name (read-only) | | options_method_forbidden | boolean (default: false) | Make OPTIONS http method forbidden over CNM HTTPS port. | +| oss_cluster_client_maint_notifications | boolean (default: false) | Toggles sending client maintenance notifications about shard movements to clients connected through the [OSS Cluster API]({{}}) | | password_complexity | boolean (default: false) | Enforce password complexity policy | | password_expiration_duration | integer (default: 0) | The number of days a password is valid until the user is required to replace it | | password_min_length | integer, (range: 8-256) (default: 8) | The minimum length required for a password. | From 2d736de434a194f43ed2642e1aa25de4edc35e09 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Mon, 20 Jul 2026 15:09:27 +0100 Subject: [PATCH 2/4] DOC-6816 Reframe SCH verification around confirmed client-side evidence The CAE "SCH on Kubernetes - Status of Record" page shows the MONITOR handshake capture was never actually done: the expected handshake strings were inferred from client-side rebind/DEBUG logs (Lettuce INTERNAL_IP, redis-py notification logs), not observed server-side via MONITOR. Reframe the verify section to lead with the confirmed client-log evidence and present the MONITOR handshake as expected behaviour, with MONITOR demoted to a secondary server-side option. Learned: MONITOR handshake was never captured in K8s SCH testing; only client-side DEBUG/rebind evidence exists Gaps: exact MONITOR handshake strings remain unconfirmed server-side (per CAE status-of-record, 2026-07-18) Ticket: DOC-6816 Co-Authored-By: Claude Opus 4.8 (1M context) --- .../kubernetes/networking/smart-client-handoffs.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/operate/kubernetes/networking/smart-client-handoffs.md b/content/operate/kubernetes/networking/smart-client-handoffs.md index b877c47d39..a4495b2cb6 100644 --- a/content/operate/kubernetes/networking/smart-client-handoffs.md +++ b/content/operate/kubernetes/networking/smart-client-handoffs.md @@ -53,9 +53,11 @@ The REST API service uses a `ClusterIP` and is reachable only from within the Ku kubectl port-forward service/ 9443:9443 ``` -## Verify the handshake +## Verify SCH is active -When a client connects with SCH enabled, the server sends a `CLIENT MAINT_NOTIFICATIONS` handshake command. You can observe it with the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. +The most reliable way to confirm that SCH is active is to inspect your client's logs. With SCH enabled and the client's log level set to `DEBUG`, a supporting client reports the maintenance notifications it receives from the server. For example, a Lettuce client reports its moving-endpoint address type as `INTERNAL_IP`, and a redis-py client logs the notification messages directly. + +When a client connects with SCH enabled, the server negotiates a `CLIENT MAINT_NOTIFICATIONS` handshake. The expected handshake depends on the connection mode. For a standalone (Enterprise cluster mode) client, the handshake includes the moving-endpoint type: @@ -73,6 +75,8 @@ CLIENT MAINT_NOTIFICATIONS ON The handshake differs because OSS Cluster API mode aligns with the configuration that determines the output of [`CLUSTER SHARDS`]({{< relref "/commands/cluster-shards" >}}), which contains the internal node IP addresses by default. In this mode, the server pushes `SMIGRATING` and `SMIGRATED` messages to the client. The `SMIGRATED` message carries information about topology changes, including the updated internal IP addresses. +You can also observe the handshake server-side with the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. + ## Validate SCH during an upgrade To confirm that SCH reduces disruption during maintenance, [upgrade the Redis Enterprise cluster]({{< relref "/operate/kubernetes/upgrade" >}}), which adds and removes nodes as the operator performs a rolling upgrade of the pods. From e4914715fbc13172141f834d5a4d9feac55e2075 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Thu, 15 Oct 2026 15:00:53 -0500 Subject: [PATCH 3/4] Enable K8s SCH with the REC CRD field instead of the REST API --- content/develop/clients/sch.md | 2 +- .../networking/smart-client-handoffs.md | 64 +++++++++++++------ 2 files changed, 45 insertions(+), 21 deletions(-) diff --git a/content/develop/clients/sch.md b/content/develop/clients/sch.md index e09af2904c..6e060464f4 100644 --- a/content/develop/clients/sch.md +++ b/content/develop/clients/sch.md @@ -122,7 +122,7 @@ the specific upgrade method you use, as detailed in the table below. ### Redis Enterprise for Kubernetes -SCH is supported for [Redis Enterprise for Kubernetes](/content/operate/kubernetes/_index.md) when your application and the Redis Enterprise cluster run within the same Kubernetes pod network. As with Redis Software, you enable SCH using the REST API. See [Enable smart client handoffs (SCH)](/content/operate/kubernetes/networking/smart-client-handoffs.md) for instructions. +SCH is supported for [Redis Software for Kubernetes](/content/operate/kubernetes/_index.md) when your application and the cluster run within the same Kubernetes pod network. You enable it with the `clientMaintenanceNotifications` field of the RedisEnterpriseCluster (REC) custom resource. See [Enable smart client handoffs (SCH)](/content/operate/kubernetes/networking/smart-client-handoffs.md) for instructions. ### Redis Open Source diff --git a/content/operate/kubernetes/networking/smart-client-handoffs.md b/content/operate/kubernetes/networking/smart-client-handoffs.md index a4495b2cb6..7c9eb46644 100644 --- a/content/operate/kubernetes/networking/smart-client-handoffs.md +++ b/content/operate/kubernetes/networking/smart-client-handoffs.md @@ -21,37 +21,61 @@ You need a RedisEnterpriseCluster (REC) running a version of Redis Enterprise So - Redis Enterprise Software 8.0.2-17 or later for standalone (Enterprise cluster mode) connections. - Redis Enterprise Software 8.0.16-29 or later for [OSS Cluster API]({{< relref "/operate/rs/databases/configure/oss-cluster-api" >}}) connections. +You also need Redis Software for Kubernetes 8.2.2-TBD or later. + In your application code, you need a client library that supports SCH (see [SCH support in Redis client libraries]({{< relref "/develop/clients/sch#sch-support-in-redis-client-libraries" >}}) for more information). -## Get the cluster credentials +## Enable SCH -The cluster's admin username and password are stored in a Kubernetes secret named after your cluster. Retrieve and decode them so you can authenticate REST API requests: +Enable SCH with the `clientMaintenanceNotifications` section of the RedisEnterpriseCluster (REC) custom resource. Each database connection mode has its own setting, and both default to `false`: -```sh -kubectl get secret -o jsonpath='{.data.username}' | base64 --decode -kubectl get secret -o jsonpath='{.data.password}' | base64 --decode -``` +| Field | Applies to | +| --- | --- | +| `proxyMode.enabled` | Databases that don't use the OSS Cluster API | +| `ossMode.enabled` | Databases that use the [OSS Cluster API](/content/operate/rs/databases/configure/oss-cluster-api.md) | -## Enable SCH +1. Edit the REC: -Use the [`/v1/cluster`]({{< relref "/operate/rs/references/rest-api/requests/cluster#put-cluster" >}}) REST API request to enable SCH for both Enterprise cluster mode and OSS Cluster API mode. Set `client_maint_notifications` and `oss_cluster_client_maint_notifications` to `true`. + ```sh + kubectl edit rec + ``` -The following example uses [`curl`](https://curl.se/) and addresses the cluster REST API on port `9443` of the REC service (for example, `rec` in a cluster named `rec`): +1. Add the `clientMaintenanceNotifications` section to the `spec` section. Enable the modes your databases use: -```sh -curl -k -X PUT -H "accept: application/json" \ - -H "content-type: application/json" \ - -u ":" \ - -d '{ "client_maint_notifications": true, "oss_cluster_client_maint_notifications": true }' \ - https://:9443/v1/cluster -``` + ```yaml + spec: + clientMaintenanceNotifications: + proxyMode: + enabled: true + ossMode: + enabled: true + ``` -The REST API service uses a `ClusterIP` and is reachable only from within the Kubernetes pod network. Run the command from a pod in the cluster, or use [`kubectl port-forward`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#port-forward) to forward a local port to the service and address `https://localhost:9443/v1/cluster` instead: +1. Save your changes. The operator applies the settings to the cluster. -```sh -kubectl port-forward service/ 9443:9443 -``` +### How the operator manages SCH settings + +After you set either `enabled` field for the first time, the operator manages that setting: + +- The operator keeps the cluster setting matched to the REC. It overwrites changes made any other way, such as through the REST API. +- If you remove the field from the REC, the operator turns the setting off. +- If the cluster's Redis Software version doesn't support the setting, the operator skips it until you upgrade the cluster. + +## Connect your clients + +Connect your application to the database's Kubernetes service, for example `..svc.cluster.local`. Don't connect directly to pod IP addresses. See [Database connectivity](/content/operate/kubernetes/networking/database-connectivity.md) for the services the operator creates. + +For databases that don't use the OSS Cluster API, what SCH provides depends on whether your application pods can reach the Redis Software pods' IP addresses. That depends on your Kubernetes cluster's security configuration. + +| Application pods can reach Redis Software pod IPs | Endpoint type | What SCH provides | +| --- | --- | --- | +| Yes | `internal-ip` | Connection handoffs and relaxed timeouts. During maintenance, the server sends the client the new endpoint's pod IP address, and the client moves its connection there. | +| No | `none` | Relaxed timeouts during shard failovers and migrations. The server tells the client to reconnect to the endpoint it already uses, so clients still see a disconnect when an endpoint moves. | + +Without TLS, the client library requests `internal-ip` automatically. If your application pods can't reach the pod IP addresses, set the endpoint type to `none` in your client library's SCH configuration. See [SCH support in Redis client libraries](/content/develop/clients/sch.md#sch-support-in-redis-client-libraries). + +With `none`, a client might reconnect twice when an endpoint moves. ## Verify SCH is active From f412d94e2382c75d2caf5fa4fd1b866d28e223e3 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Thu, 15 Oct 2026 15:29:49 -0500 Subject: [PATCH 4/4] Rename to Redis Software and cut unverified MONITOR check --- .../networking/smart-client-handoffs.md | 20 +++++++++---------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/content/operate/kubernetes/networking/smart-client-handoffs.md b/content/operate/kubernetes/networking/smart-client-handoffs.md index 7c9eb46644..d1a5caa2d6 100644 --- a/content/operate/kubernetes/networking/smart-client-handoffs.md +++ b/content/operate/kubernetes/networking/smart-client-handoffs.md @@ -5,21 +5,21 @@ categories: - docs - operate - kubernetes -description: Enable smart client handoffs (SCH) to avoid client disruptions during Redis Enterprise cluster maintenance and upgrades on Kubernetes. +description: Enable smart client handoffs (SCH) to avoid client disruptions during cluster maintenance and upgrades on Redis Software for Kubernetes. linkTitle: Smart client handoffs weight: 98 --- -[Smart client handoffs]({{< relref "/develop/clients/sch" >}}) (SCH) let a Redis Enterprise cluster notify clients about planned maintenance shortly before it happens, so clients can reconnect or otherwise respond gracefully without significant interruptions in service. SCH is primarily useful during server software or hardware upgrades, where it provides *relaxed timeouts* and transparent *pre-handoffs* to new endpoints. See [Smart client handoffs]({{< relref "/develop/clients/sch" >}}) for a full description of the feature. +[Smart client handoffs]({{< relref "/develop/clients/sch" >}}) (SCH) let the cluster notify clients about planned maintenance shortly before it happens, so clients can reconnect or otherwise respond gracefully without significant interruptions in service. SCH is primarily useful during server software or hardware upgrades, where it provides *relaxed timeouts* and transparent *pre-handoffs* to new endpoints. See [Smart client handoffs]({{< relref "/develop/clients/sch" >}}) for a full description of the feature. -This page describes how to enable SCH for a Redis Enterprise cluster (REC) running on Kubernetes when your application and the cluster run within the same Kubernetes pod network, using IP-based access without TLS. External access over TLS with name-based addressing is not yet covered. +This page describes how to enable SCH on Redis Software for Kubernetes when your application and the cluster run within the same Kubernetes pod network, using IP-based access without TLS. External access over TLS with name-based addressing is not yet covered. ## Prerequisites -You need a RedisEnterpriseCluster (REC) running a version of Redis Enterprise Software that supports SCH: +You need a RedisEnterpriseCluster (REC) running a version of Redis Software that supports SCH: -- Redis Enterprise Software 8.0.2-17 or later for standalone (Enterprise cluster mode) connections. -- Redis Enterprise Software 8.0.16-29 or later for [OSS Cluster API]({{< relref "/operate/rs/databases/configure/oss-cluster-api" >}}) connections. +- Redis Software 8.0.2-17 or later for standalone (Enterprise cluster mode) connections. +- Redis Software 8.0.16-29 or later for [OSS Cluster API]({{< relref "/operate/rs/databases/configure/oss-cluster-api" >}}) connections. You also need Redis Software for Kubernetes 8.2.2-TBD or later. @@ -99,13 +99,11 @@ CLIENT MAINT_NOTIFICATIONS ON The handshake differs because OSS Cluster API mode aligns with the configuration that determines the output of [`CLUSTER SHARDS`]({{< relref "/commands/cluster-shards" >}}), which contains the internal node IP addresses by default. In this mode, the server pushes `SMIGRATING` and `SMIGRATED` messages to the client. The `SMIGRATED` message carries information about topology changes, including the updated internal IP addresses. -You can also observe the handshake server-side with the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. - ## Validate SCH during an upgrade -To confirm that SCH reduces disruption during maintenance, [upgrade the Redis Enterprise cluster]({{< relref "/operate/kubernetes/upgrade" >}}), which adds and removes nodes as the operator performs a rolling upgrade of the pods. +To confirm that SCH reduces disruption during maintenance, [upgrade the cluster]({{< relref "/operate/kubernetes/upgrade" >}}), which adds and removes nodes as the operator performs a rolling upgrade of the pods. -1. Make sure both the source and target Redis Enterprise Software versions support SCH. +1. Make sure both the source and target Redis Software versions support SCH. 1. Enable SCH as described above. 1. Connect your clients and set their log level to `DEBUG`. 1. Start the upgrade and watch the client debug output: @@ -117,4 +115,4 @@ To confirm that SCH reduces disruption during maintenance, [upgrade the Redis En - [Smart client handoffs]({{< relref "/develop/clients/sch" >}}) - Feature overview and client library support - [Enable cluster-aware clients (OSS Cluster API)]({{< relref "/operate/kubernetes/networking/cluster-aware-clients" >}}) - Route requests directly with cluster-aware clients - [Database connectivity]({{< relref "/operate/kubernetes/networking/database-connectivity" >}}) - In-cluster and external database access -- [Upgrade Redis Enterprise for Kubernetes]({{< relref "/operate/kubernetes/upgrade" >}}) - Cluster and database upgrade procedures +- [Upgrade Redis Software for Kubernetes]({{< relref "/operate/kubernetes/upgrade" >}}) - Cluster and database upgrade procedures