diff --git a/docs/en/functions/10-create-instance.mdx b/docs/en/functions/10-create-instance.mdx index f4d9766..9c00dcb 100644 --- a/docs/en/functions/10-create-instance.mdx +++ b/docs/en/functions/10-create-instance.mdx @@ -5,15 +5,14 @@ sourceSHA: f9bfcbdca6540fe5c33b1d774fbf710c3808a2b3c37f3beb9c252bd5845b999e # Create Instance -Following Redis versions are fully supported: `5.0`, `6.0`, `7.2`; other versions are not supported by default. +Following Redis versions are fully supported: `6.0`, `7.2`, `8.4`; other versions are not supported by default. - When used in a production environment, it is recommended to prioritize the `7.2` version, followed by `6.0`. + When used in a production environment, it is recommended to prioritize the `7.2` or `8.4` version, followed by `6.0`. - 1. `7.2` is a version still maintained by the community, which fixes known issues in `6.0` and `5.0`. The `6.0` and `5.0` versions are no longer maintained by the community. - 2. `7.2` is fully compatible with `6.0` and `5.0`. - 3. `7.2` has further improved the ACL features. - 4. `5.0` is not recommended for use as it does not support advanced features like ACL and lacks user management capabilities; all business processes will share a single password, presenting potential security risks; also, changing the password requires restarting all nodes. + 1. `7.2` and `8.4` are still maintained by the community and fix known issues in `6.0`. The `6.0` version is no longer maintained by the community. + 2. `7.2` and `8.4` are fully compatible with `6.0`. + 3. `7.2` and `8.4` have further improved the ACL features. @@ -241,12 +240,12 @@ After the instance is created, you can use the following command to check the st ```bash $ kubectl -n default get redis NAME ARCH VERSION ACCESS STATUS MESSAGE BUNDLE VERSION AUTOUPGRADE AGE -c5 cluster 5.0 NodePort Ready 4.0.1 2m46s c6 cluster 6.0 Initializing 4.0.1 3m26s c7 cluster 7.2 NodePort Initializing 4.0.1 98s -s5 sentinel 5.0 Ready 4.0.1 3m10s +c8 cluster 8.4 NodePort Ready 4.0.1 2m46s s6 sentinel 6.0 Ready 4.0.1 25m s7 sentinel 7.2 NodePort Ready 4.0.1 2m15s +s8 sentinel 8.4 Ready 4.0.1 3m10s standalone standalone 6.0 Initializing 4.0.1 6s ``` @@ -256,7 +255,7 @@ The meanings of the output table fields are as follows: | :------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NAME | Instance name | | ARCH | This value corresponds to the architecture of Redis. This field indicates whether this CR resource manages a standalone, Sentinel, or Cluster mode of Redis. | -| VERSION | Currently supports only the 3 versions: `5.0`, `6.0`, `7.2` | +| VERSION | Currently supports only the 3 versions: `6.0`, `7.2`, `8.4` | | ACCESS | The access methods supported by the instance. | | STATUS | The current status of the instance, which may include the following states: | | MESSAGE | The reason for the instance being in its current status | diff --git a/docs/en/functions/20-user.mdx b/docs/en/functions/20-user.mdx index 3f4a814..b86a75f 100644 --- a/docs/en/functions/20-user.mdx +++ b/docs/en/functions/20-user.mdx @@ -8,7 +8,7 @@ sourceSHA: 598b38348adf2636d3464b37b2c05a0b9f6c876de00fa7783b93d1e6dc4a67df Implementing proper authentication and access control is essential for securing your Redis environment. This section covers password management and role-based access control configuration for Redis instances. - Redis 5.0 supports only basic password authentication with a single credential set, while Redis 6.0 and later versions implement a comprehensive Access Control List (ACL) system that supports multiple users with granular permissions. Redis 6.0+ maintains the default user for backward compatibility with legacy clients. + Redis 6.0 and later versions implement a comprehensive Access Control List (ACL) system that supports multiple users with granular permissions. Redis 6.0+ maintains the default user for backward compatibility with legacy clients. ## View Users @@ -67,10 +67,6 @@ The following procedures allow you to update user passwords for enhanced securit - - The following operations apply only to Redis 6.0 or later versions. For Redis 5.0, refer to the "Redis 5.0 CLI" tab. - - 1. Identify the target user from the RedisUser list. For this example, we'll update the password for the `default` user of instance `s6`. @@ -172,38 +168,6 @@ The following procedures allow you to update user passwords for enhanced securit After updating the password, the RedisUser resource will temporarily enter the `Pending` state while the change propagates to all Redis nodes. Once synchronized, the status will return to `Success`. - - Redis 5.0 does not support the ACL system and therefore does not use RedisUser resources. Instead, the password is managed through the `spec.passwordSecret` field in the Redis CR (see [Redis API Documentation](../apis/kubernetes_apis/redis/redis)). - - - Updating the password for a Redis 5.0 instance requires a complete instance restart, which may cause service interruption. Schedule this operation during maintenance windows or periods of low traffic. - - - 1. Create a Secret containing the new password: - - ```bash - $ kubectl -n default create secret generic new-redis-password --from-literal=password=admin@123456 - ``` - - 2. Update the Redis CR to reference the new Secret: - - ```bash - $ kubectl -n default patch redis s5 --type=merge --patch='{"spec": {"passwordSecret": "new-redis-password"}}' - ``` - - 3. Monitor the instance status during the update process: - - ```bash - $ kubectl -n default get redis -w - NAME ARCH VERSION ACCESS STATUS MESSAGE BUNDLE VERSION AUTOUPGRADE AGE - c6 cluster 6.0 Ready 4.0.1 false 125m - s5 sentinel 5.0 Initializing 4.0.1 false 8h - s6 sentinel 6.0 Ready 4.0.1 false 124m - ``` - - The instance will transition to `Ready` status once the password change is complete. - - 1. In the **User Management** tab, select the target user and click the expand button to view user details. 2. Click **Reset Password** in the action menu. diff --git a/docs/en/functions/30-parameter.mdx b/docs/en/functions/30-parameter.mdx index 02e6a54..8342a1e 100644 --- a/docs/en/functions/30-parameter.mdx +++ b/docs/en/functions/30-parameter.mdx @@ -7,7 +7,7 @@ sourceSHA: 308585571db88077bffd035151f6160f84c24c6ffd00a0ffdcf91d9a017b364b When creating a Redis instance, the system's default parameter template is applied. -Alauda Application Services provides specialized parameter templates for each Redis version (three templates for version 6.0+ and two for version 5.0) to accommodate different operational requirements. +Alauda Application Services provides specialized parameter templates for each Redis version (three templates for version 6.0 and later) to accommodate different operational requirements. | Parameter Template | Description | Considerations | | :---------------- | :---------- | :------------- | diff --git a/docs/en/how_to/30-upgrade.mdx b/docs/en/how_to/30-upgrade.mdx index 73f2336..511d03d 100644 --- a/docs/en/how_to/30-upgrade.mdx +++ b/docs/en/how_to/30-upgrade.mdx @@ -8,6 +8,12 @@ Redis patch version upgrades provide security fixes and stability improvements. When patch versions become available, prompt adoption is advised to ensure your Redis instances benefit from the latest security patches and feature enhancements. + +Upgrading the Alauda Cache Service for Redis OSS operator does **not** automatically upgrade the Redis version of existing instances; each instance's Redis version must be upgraded explicitly. + +ACP v4.3 requires Alauda Cache Service for Redis OSS v5.0.x, which no longer supports Redis `5.0`. If you are upgrading from an ACP version earlier than v4.3, upgrade every Redis `5.0` instance to a supported version (`6.0`, `7.2`, or `8.4`) and confirm that no Redis `5.0` instances remain **before** upgrading ACP to v4.3. See [Upgrade](../upgrade.mdx) for the operator and ACP upgrade flow. + + ## Configure Upgrade Strategy You can define how patch upgrades are applied to your Redis instances by configuring the upgrade policy. diff --git a/docs/en/intro.mdx b/docs/en/intro.mdx index d3c0c6f..78fc492 100644 --- a/docs/en/intro.mdx +++ b/docs/en/intro.mdx @@ -31,11 +31,11 @@ title: Introduction | Cluster | Massive Data/Horizontal Scaling | 2. **Version Support** - - Redis `5.0`, `6.0`, `7.2`. + - Redis `6.0`, `7.2`, `8.4`. 3. **Access Control and Security** - Supports TLS encryption. - - Integrates **Redis ACL** (Access Control List), supporting fine-grained user permission management (this feature is not supported in Redis 5.0). + - Integrates **Redis ACL** (Access Control List), supporting fine-grained user permission management. 4. **Network and Access Methods** - Supports service expose type of **NodePort** and **LoadBalancer**, with the ability to specify NodePort ports. diff --git a/docs/en/upgrade.mdx b/docs/en/upgrade.mdx index c83c946..4c2a1f3 100644 --- a/docs/en/upgrade.mdx +++ b/docs/en/upgrade.mdx @@ -37,12 +37,21 @@ The following matrix outlines the tested version combinations and their respecti | Alauda Cache Service for Redis OSS Version | Redis Server Versions | ACP Version | |:-------------------------------------------|:---------------------------|:-----------------| +| v5.0.1 | 6.0.21, 7.2.14, 8.4.3 | v4.1, v4.2, v4.3 | | v5.0.0 | 6.0.21, 7.2.12, 8.4.2 | v4.1, v4.2, v4.3 | -| v4.1.0 | 5.0.14, 6.0.20, 7.2.10 | v4.1 | +| v4.1.x | 5.0.14, 6.0.20, 7.2.10 | v4.1, v4.2 | | v4.0.x | 5.0.14, 6.0.20, 7.2.x | v4.0 | -Alauda Cache Service for Redis OSS v4.1.x and v4.0.x have not been tested on ACP v4.3. Before upgrading to ACP v4.3, please upgrade Alauda Cache Service for Redis OSS to v5.0.0 first. +Alauda Cache Service for Redis OSS v4.1.x and v4.0.x have not been tested on ACP v4.3. Before upgrading to ACP v4.3, please upgrade Alauda Cache Service for Redis OSS to v5.0.0 or later first. + + + +Upgrading the Alauda Cache Service for Redis OSS operator does **not** automatically upgrade the Redis version of existing instances; each instance's Redis version must be upgraded explicitly. + +Because ACP v4.3 requires Alauda Cache Service for Redis OSS v5.0.x, and v5.0.x no longer supports Redis `5.0`, you must first upgrade every Redis `5.0` instance to a supported version (`6.0`, `7.2`, or `8.4`) **before** upgrading from an ACP version earlier than v4.3 to v4.3. + +Confirm that no instance reports `5.0` in the `VERSION` column (for example, run `kubectl get redis -A`) before starting the ACP upgrade. Refer to the [Instance Upgrade Guide](./how_to/30-upgrade.mdx) for the upgrade procedure. ## Upgrade Strategies