升级
本操作步骤涵盖 Alauda Cache Service E2 安装包和 Valkey Operator。它不会升级现有实例的 Valkey server 版本线。对于该更改,请参阅 升级 Valkey。
确切的安装包上传和升级命令取决于 Alauda Container Platform 的发行版。它不是由 valkey-operator 仓库定义的。请使用随交付的 2.0.0 发布包中提供的已批准 CLI 工作流;此产品没有 Web Console 操作步骤。
开始之前
- 确认源产品版本和目标产品版本在该发布版本的兼容性矩阵中构成受支持的升级路径。
- 确认所有受管理实例均为
Ready,且没有正在运行的扩缩容、重启、证书、配置或 server-version 操作。 - 完成并测试用于持久化数据的外部数据保护操作步骤。Operator 不提供集成备份或产品回滚。
- 记录所有
Valkey和User规格、已安装的自定义资源定义(CRD)、Operator 镜像和警告 Events。不要将 Secret 值导出到不安全的文件中。 - 确认目标发布版本仍然打包现有实例使用的每条 server 版本线。
记录当前状态
将实例规格与凭据分开保存:
请妥善保护这些文件,因为资源元数据和访问控制列表(ACL)规则可能包含环境信息,即使密码存储在 Secrets 中也是如此。
应用安装包升级
使用目标发布版本提供的已批准 CLI 安装包工作流。在批准之前,请检查拟议的 Operator 和 server 镜像更改。一次只执行一个 control-plane 升级,并且在 Operator Deployment 正在滚动更新时不要编辑由 operator 管理的子资源。
监控 Operator 时不要假设其 namespace:
如果交付的安装包使用 Operator Lifecycle Manager subscription 或其他包控制器,请使用该发布版本指定的 CLI 检查其状态。不要根据其他产品去猜测 Subscription 名称、namespace、channel 或批准策略。
验证结果
- 确认全部五个 CRD 均为
Established,且其已提供版本与目标发布版本一致。 - 确认 Operator Deployment 可用,且其容器使用预期的目标镜像。
- 确认每个
Valkey都恢复为Ready;检查任何未恢复实例的.status.message和 Events。 - 验证应用读写、ACL 身份验证、Cluster slot 覆盖或 Failover 主节点选择、TLS 和 exporter 指标。
- 确认
spec.version没有意外更改。
运行最终的 API 和实例检查:
故障边界
除非交付的发布版本明确规定了回滚,否则不要单独回滚 Operator 镜像或 CRD。较新的控制器可能已经写入了较旧控制器无法理解的 status 或子资源字段。请保留日志、Events、已记录的规格以及精确的 package-controller 状态,然后按照产品支持恢复计划执行。