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/lifecycle_policy.mdx b/docs/en/lifecycle_policy.mdx index c706928..f4b5aae 100644 --- a/docs/en/lifecycle_policy.mdx +++ b/docs/en/lifecycle_policy.mdx @@ -12,18 +12,28 @@ title: Lifecycle Policy Below is the lifecycle schedule for released versions of the Alauda Cache Service for Redis OSS: -| Version | Release Date | End of Support | -|:--------|:-------------|:---------------| -| v4.1.x | 2025-08-22 | 2027-08-30 | +| Version | Release Date | End of Full Support | End of Maintenance | +|:--------|:-------------|:--------------------|:-------------------| +| v5.0.x | 2026-04-28 | 2027-04-30 | 2028-04-30 | +| v4.1.x | 2025-08-22 | 2026-08-30 | 2027-08-30 | ## Release Policy -* A new patch version of Alauda Cache Service for Redis OSS is released as needed to address bugs and security vulnerabilities. -* Minor version releases are driven by significant updates to the underlying Redis server, the implementation of new features, or emerging security requirements. +* A new patch version of Alauda Cache Service for Redis OSS is released as needed to address bugs and security vulnerabilities. Patch releases do not introduce new features. +* Minor and major version releases are driven by significant updates to the underlying Redis server, the implementation of new features, or emerging security requirements. + +## Support Phases + +Each minor version progresses through two support phases over its lifecycle: + +* **Full Support (Year 1)**: From the release date until the end of full support. The version receives all bug fixes and security patches via patch releases on the same minor line. +* **Maintenance (Year 2)**: From the end of full support until the end of maintenance. The version receives only critical bug fixes and security patches; non-critical fixes are not backported. + +After the end of maintenance, the version is no longer supported. Customers should plan to upgrade to a supported version before this date. ## Maintenance Policy -During a version's maintenance period, Alauda provides the following services: +During a version's supported lifecycle, Alauda provides the following services: * **Upstream Patching**: We actively track official Redis patch releases and promptly deliver critical bug fixes and security vulnerability patches. * **Security Updates**: We release security updates for the service operator on-demand to address vulnerabilities and ensure stability. diff --git a/docs/en/release_notes.mdx b/docs/en/release_notes.mdx index 02bf583..37c88e3 100644 --- a/docs/en/release_notes.mdx +++ b/docs/en/release_notes.mdx @@ -6,14 +6,52 @@ i18n: title: Release Notes --- +# Release Notes + ## Compatibility and support matrix The following table shows the compatibility and support matrix between the Alauda Cache Service for Redis OSS and ACP versions. -| Alauda Cache Service for Redis OSS Version | Redis Versions | ACP Version | -|:-------------------------------------------|------------------------|:------------| -| v4.1.0 | 5.0.14, 6.0.20, 7.2.10 | v4.1 | -| v4.0.x | 5.0.14, 6.0.20, 7.2.x | v4.0 | +| Alauda Cache Service for Redis OSS Version | Redis 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.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 | + +## v5.0.1 + +### Fixed Issues + +{/* release-notes-for-bugs?template=mw-redis-v5.0.1-fixed&project=Middleware */} + +### Known Issues + +{/* release-notes-for-bugs?template=mw-redis-v5.0.1-known&project=Middleware */} + +### Security Fixes + +{/* release-notes-for-bugs?template=mw-redis-v5.0.1-security&project=Middleware */} + +## v5.0.0 + +### New and Optimized Features + +#### Redis 8.4 Support + +Added support for Redis 8.4 (8.4.2), enabling users to provision and manage instances on the latest Redis Server release alongside the existing 6.0 and 7.2 series. + +#### Expanded APIs for Redis Modules + +The Alauda Cache Service for Redis OSS APIs have been expanded to support Redis modules, allowing users to configure and manage modules on Redis instances. + +### Fixed Issues + +{/* release-notes-for-bugs?template=mw-redis-v5.0-fixed&project=Middleware */} + +### Known Issues + +{/* release-notes-for-bugs?template=mw-redis-v5.0-known&project=Middleware */} ## v4.1.0 @@ -68,4 +106,3 @@ When using LoadBalancer, ensure that the cluster has available external address ### Known Issues {/* release-notes-for-bugs?template=mw-redis-v4.0-known&project=Middleware */} - diff --git a/docs/en/upgrade.mdx b/docs/en/upgrade.mdx index 6e0fa60..4c2a1f3 100644 --- a/docs/en/upgrade.mdx +++ b/docs/en/upgrade.mdx @@ -8,62 +8,96 @@ title: Upgrade # Upgrade -This document provides technical guidance for upgrading Alauda Cache Service for Redis OSS, including version compatibility, upgrade paths, and operational procedures. +The Alauda Cache Service for Redis OSS is engineered to provide service continuity and data security across all supported versions. This guide details version compatibility and outlines the recommended upgrade paths to facilitate a seamless transition for your environment. + + +Prior to upgrading a production environment, it is highly recommended to validate the upgrade process within a development or staging environment. This preliminary step helps identify and mitigate potential compatibility issues, including hardware-related conflicts, before they can affect production services. + ## Version Compatibility Principles -Alauda Cache Service for Redis OSS follows semantic versioning with the following compatibility guarantees: +The Alauda Cache Service for Redis OSS adheres to semantic versioning principles, providing the following compatibility guarantees: -* **Patch versions** (x.y.**z**) within the same minor version are fully backward and forward compatible -* **Minor versions** (x.**y**.z) within the same major version maintain API and feature compatibility -* **Major versions** (**x**.y.z) may introduce breaking changes and require specific upgrade procedures +* **Patch versions** (x.y.**z**) are fully backward and forward compatible within the same minor version series. +* **Minor versions** (x.**y**.z) maintain API and feature compatibility within the same major version. +* **Major versions** (**x**.y.z) may introduce breaking changes that require specific upgrade procedures. ## Prerequisites -Before initiating any upgrade operation, verify the following conditions: +Before initiating an upgrade, ensure that the following prerequisites are met: -1. **Version Compatibility**: Current version must be within supported upgrade paths -2. **Component Health**: All Redis instances must report Ready status -3. **Resource Availability**: Cluster must have sufficient CPU, memory, and storage resources -4. **Backup**: Ensure recent backups of critical data and configuration +1. **Version Compatibility**: The current version must be on a supported upgrade path. +2. **Component Health**: All Redis instances must report a `Ready` status. +3. **Resource Availability**: The cluster must possess adequate CPU, memory, and storage resources to accommodate the upgrade. +4. **Backup**: Recent backups of all critical data and configurations must be available. ## Supported Upgrade Paths -The following upgrade matrix details tested version combinations and their dependencies: +The following matrix outlines the tested version combinations and their respective dependencies: -| Alauda Cache Service for Redis OSS Version | Redis Server Versions | ACP Version | Kubernetes Versions | -|:-------------------------------------------|:---------------------------|:------------|:--------------------------| -| v4.1.0 | 5.0.14, 6.0.20, 7.2.10 | v4.1.0 | 1.29, 1.30, 1.31, 1.32 | -| v4.0.x | 5.0.14, 6.0.20, 7.2.x | v4.0.x | 1.28, 1.29, 1.30, 1.31 | +| 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.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 | -## Upgrade Strategies + +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. + -### Minor Version Upgrade + +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. -* **Approach**: Any minor version can be upgraded to a newer minor version (e.g., 4.0.x → 4.2.x). -* **Benefits**: Minimizes risk and ensures smooth transition between versions - -### Patch Version Upgrade +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. -* **Compatibility**: Fully compatible within the same minor version series -* **Example**: Upgrade from `4.1.0` to `4.1.1` for bug fixes and security patches +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. + -### Major Version Upgrade +## Upgrade Strategies -* **Requirement**: Must upgrade to the earliest available minor release of the target major version first -* **Procedure**: Follow specific major version upgrade documentation for detailed steps -* **Considerations**: May require configuration changes and feature compatibility review +### Minor Version Upgrade -## Upgrade Execution +* **Approach**: Direct upgrades are supported from any minor version to a newer release within the same major version (e.g., `4.0.x` → `4.1.0`). +* **Benefits**: This approach minimizes operational risk and facilitates a seamless transition between versions. -Alauda Cache Service for Redis OSS supports two upgrade execution modes: +### Patch Version Upgrade -* **Automatic**: System automatically detects and applies new versions when available -* **Manual**: Requires explicit administrator approval before initiating upgrade procedures +* **Compatibility**: Patch versions are fully compatible within the same minor version series. +* **Example**: Upgrading within the same minor series (e.g., `x.y.0` → `x.y.1`) applies the latest bug fixes and security patches. -### Operational Considerations +### Major Version Upgrade -* **Downtime**: Plan for minimal service interruption during upgrade operations -* **Rollback**: Ensure rollback procedures are understood and tested -* **Monitoring**: Closely monitor system metrics and logs during upgrade process -* **Validation**: Perform post-upgrade validation of all critical functionality +* **Requirement**: When upgrading across major versions (e.g., `4.1.0` → `5.0.0`), upgrade directly to the latest available release of the target major version. +* **Procedure**: Follow the upgrade steps below to upgrade the operator, then upgrade individual instances per the [Instance Upgrade Guide](./how_to/30-upgrade.mdx). +* **Considerations**: Major upgrades may necessitate configuration modifications and a comprehensive review of feature compatibility. + +## Upgrade Steps + +1. Download the target version of the `Alauda Cache Service for Redis OSS` plugin from AlaudaCloud to a node that has access to your ACP cluster. +2. Utilize the `violet` package management tool to upload the plugin to the target cluster. For detailed instructions, refer to the documentation. +3. Upgrades follow the strategy configured in the Subscription: + * `Automatic Upgrade`: The plugin upgrades automatically upon upload. + * `Manual Upgrade`: + + + ```bash + # Check for available upgrades + $ kubectl -n redis-system get subscriptions.operators.coreos.com redis-operator -o go-template='{{ printf "Installed: %s\n Current: %s" .status.installedCSV .status.currentCSV }}' + + # If an upgrade is available, find the corresponding InstallPlan for the Subscription + $ kubectl -n redis-system get subscriptions.operators.coreos.com redis-operator -o jsonpath='{.status.installplan.name}' + + # Approve the InstallPlan to proceed with the upgrade + $ kubectl -n redis-system patch --type='json' -p='[{"op":"replace","path":"/spec/approved","value":true}]' + ``` + + + - Log in to the web console and switch to the Administrator view. + - Navigate to **Marketplace** > **OperatorHub** > **Alauda Cache Service for Redis OSS detail page**. + - Click the **Confirm** link in the **New Version Detected** notification, then click the **Confirm** button in the subsequent dialog to approve the update. + - If the **New Version Detected** notification does not appear, no upgrade is available. + + + For more detailed instructions on upgrading the plugin, refer to the documentation. +4. To upgrade the Redis instance itself, please refer to the [Instance Upgrade Guide](./how_to/30-upgrade.mdx). diff --git a/doom.config.yml b/doom.config.yml index 312fcf6..069e46e 100644 --- a/doom.config.yml +++ b/doom.config.yml @@ -21,3 +21,13 @@ releaseNotes: project = MiddleWare AND type = Bug AND ReleaseNotesStatus = Publish AND Feature in ("MiddleWare - Redis") AND fixVersion = Redis-v4.1.0 mw-redis-v4.1-known: | project = MiddleWare AND type = Bug AND ReleaseNotesStatus = Publish AND Feature = "MiddleWare - Redis" AND affectedVersion in (Redis-v4.1.0) AND fixVersion is EMPTY + mw-redis-v5.0-fixed: | + project = MiddleWare AND type = Bug AND ReleaseNotesStatus = Publish AND Feature in ("MiddleWare - Redis") AND fixVersion = Redis-v5.0.0 + mw-redis-v5.0-known: | + project = MiddleWare AND type = Bug AND ReleaseNotesStatus = Publish AND Feature = "MiddleWare - Redis" AND affectedVersion in (Redis-v5.0.0) AND fixVersion is EMPTY + mw-redis-v5.0.1-fixed: | + status in (Done, Resolved) AND (labels not in (安全问题) OR labels is EMPTY) AND project = MIDDLEWARE AND Feature = "MiddleWare - Redis" AND fixVersion = Redis-v5.0.1 AND ReleaseNotesStatus = Publish + mw-redis-v5.0.1-known: | + project = MiddleWare AND type = Bug AND ReleaseNotesStatus = Publish AND Feature = "MiddleWare - Redis" AND affectedVersion in (Redis-v5.0.1) AND fixVersion is EMPTY + mw-redis-v5.0.1-security: | + project = MIDDLEWARE AND (issuetype = Vulnerability OR labels in (安全问题)) AND fixVersion = Redis-v5.0.1 AND ReleaseNotesStatus = Publish diff --git a/sites.yaml b/sites.yaml index 56d69a8..512cd06 100644 --- a/sites.yaml +++ b/sites.yaml @@ -1,3 +1,3 @@ - name: acp base: /container_platform - version: "4.0" + version: "5.0"