Redis Enterprise for Kubernetes 7.4.2-12(2024 年 5 月)发行说明
这是 Redis Enterprise Software 7.4.2 新版本的功能版本。
亮点
此版本有许多增强功能,最值得注意的是对 REC 中持久卷扩展的支持。此外,模块处理中的一些重要更改支持新功能,这些功能是由底层 Redis Enterprise 在版本控制方面的更改引起的。
此版本中的新增功能
增强功能
- 支持 REC 中的持久卷扩展(RED-84018)
- 能够在 REDB 规范中指定 Redis 版本 (RED-103945)
- 更新了支持的发行版(RED-119711)
- 无需指定模块版本即可通过 REDB 启用模块 (RED-116082)
- 双栈配置支持(RED-121897)
已解决的问题
- 修复客户端证书循环更新的情况 (RED-121633)
- 修复了禁用 REDB 复制的问题 (RED-122721)
API 更改
| 慢性肾脏病 | 场地 | 改变 | 描述 |
|---|---|---|---|
| 记录 | spec.persistentSpec.enablePersistentVolumeResize | 添加 | 设置为“true”以允许在 REC 创建后更改 volumeSize(仅用于调整大小) |
| 记录 | status.persistenceStatus | 添加 | 指示持久卷扩展的状态 |
| 记录 | 规范.redisEnterpriseIPFamily | 添加 | 配置 Kubernetes 集群启用双栈网络时要使用的 IP 系列 |
| 可再生能源发展数据库 | 规范.moduleList[x].version | 改变 | 字段不再是必填项 |
| 可再生能源发展数据库 | spec.upgradeSpec | 添加 | 新字段允许配置模块升级设置 |
| 可再生能源发展数据库 | 规范.redis版本 | 改变 | 现在允许设置版本号(Major.Minor) |
版本变更
重大变更
此版本中包含的以下更改会影响升级过程。升级前请仔细阅读。
ValidatingWebhook配置
版本 6.4.2-4 及更高版本包含一个新ValidatingWebhookConfiguration资源来替换redb-admissionwebhook 资源。要使用版本 6.4.2-4 或更高版本,请删除旧的 webhook 资源并应用新文件。有关说明,请参阅升级 Redis 集群。
OpenShift SCC
版本 6.4.2-6 及更高版本包含一个新的 SCC ( redis-enterprise-scc-v2),您需要在升级之前将其绑定到您的服务账户。如果您跳过此步骤,运行版本 6.2.12 或更早版本的 OpenShift 集群升级到版本 6.2.18 或更高版本可能会卡住。有关说明,请参阅升级 Redis Enterprise 集群 (REC) 。
即将发生的变化
- 未来的 Redis Enterprise 镜像将仅基于 UBI9,不支持基于 Ubuntu 的镜像。
支持的发行版
下表显示了此版本发布时支持的发行版。您也可以在支持的 Kubernetes 发行版中找到此列表。
✅支持 – 此发行版支持适用于 Kubernetes 的 Redis Enterprise Software。
⚠️已弃用 – 此发行版仍支持适用于 Kubernetes 的 Redis Enterprise Software,但在未来版本中将不再支持该发行版。
❌终止生命——对该发行版的支持已终止。
任何未在下面列出的发行版均不支持生产工作负载。
| Kubernetes 版本 | 1.24 | 1.25 | 1.26 | 1.27 | 1.28 | 1.29 |
|---|---|---|---|---|---|---|
| 社区 Kubernetes | ⚠️ | ✅ | ✅ | ✅ | ||
| 亚马逊 EKS | ⚠️ | ✅ | ✅ | ✅ | ||
| Azure AKS | ⚠️ | ✅ | ✅ | ✅ | ||
| 谷歌 GKE | ⚠️ | ✅ | ✅ | ✅ | ✅ | |
| Rancher RKE2 | ❌ | ✅ | ✅ | ✅ | ||
| VMware TKG 2.2 | ⚠️ | ⚠️ | ||||
| VMware TKG 2.3 | ✅ | ✅ | ✅ | |||
| VMware TKG 2.4 | ✅ | ✅ | ✅ | |||
| OpenShift 版本 | 4.11 | 4.12 | 4.13 | 4.14 | 4.15 | |
| ⚠️ | ✅ | ✅ | ✅ | ✅ | ||
| VMware TKGI 版本 | 1.15 | 1.16 | 1.17 | 1.18 | ||
| ❌ | ✅ | ✅ | ✅ |
下载
- Redis 企业版:
redislabs/redis:7.4.2-129 - 操作员:
redislabs/operator:7.4.2-12 - 索具服务:
redislabs/k8s-controller:7.4.2-12
OpenShift 映像
- Redis 企业版:
registry.connect.redhat.com/redislabs/redis-enterprise:7.4.2-129.rhel8-openshift - 操作员:
registry.connect.redhat.com/redislabs/redis-enterprise-operator:7.4.2-12 - 索具服务:
registry.connect.redhat.com/redislabs/services-manager:7.4.2-12
OLM 捆绑包
Redis Enterprise 操作员包:v7.4.2-12.0
已知限制
新的限制
- 缺少准入端点的端点(罕见)(RED-119469)重新启动操作员舱。
现有的限制
-
REDB“redisVersion”字段不能用于 memcached 数据库(RED-119152)
-
修改 Active-Active 数据库的数据库后缀时,如果 service-rigger 处于终止状态,services-rigger 将循环删除并创建入口或路由资源 (RED-107687)等到 services rigger pod 完成后再终止它。
-
REAADB 更改可能会因“网关超时”错误而失败,主要是在 OpenShift 上(RED-103048)重试操作。
-
直接在 Redis Enterprise 软件上创建两个同名的数据库将导致服务被删除,并且数据库将不可用 (RED-99997)避免重复数据库名称。通过 K8s 创建数据库时会进行验证以防止这种情况发生。
-
安装操作员包时会产生警告:
Warning: would violate PodSecurity "restricted: v1.24"(RED-97381)请忽略该警告。Red Hat 官方文档将此问题记录为良性问题。 -
RERC 资源必须具有唯一的名称 (RED-96302)字符串“rec-name”/“rec-namespace”必须与 Active-Active 数据库中的所有其他参与集群不同。
-
入场不会阻止
shardCount超过许可配额的 REAADB(RED-96301)修复 REAADB 的问题并重新申请。 -
Active-Active 控制器仅支持全局数据库选项。不支持特定于位置的配置 (RED-86490)
-
主动-主动设置删除可能会使服务或路由保持未删除状态(RED-77752)如果遇到此问题,请手动删除服务或路由。
-
autoUpgrade设置为true可能会导致意外的 bdb 升级(RED-72351)如果您的部署redisUpgradePolicy受到true影响,请联系支持。 -
按照上一个快速入门指南版本会导致由于无法识别的内存字段名称而无法创建 REDB (RED-69515),解决方法是使用较新(当前)版本的 Deploy Redis Enterprise Software for Kubernetes。
-
在规范中使用十进制值时,PVC 大小会出现问题(RED-62132)确保使用整数值作为 PVC 大小。
-
REC 可能会在初始启动时报告错误状态(RED-61707)目前除了忽略错误之外没有其他解决方法。
-
Hashicorp Vault 集成 - 不支持 Gesher (RED-55080)此问题没有解决方法。Gesher 支持已被弃用。
-
REC 集群无法在时钟不同步的 Kubernetes 集群上启动 (RED-47254)当 REC 集群部署在没有同步时钟的 Kubernetes 集群上时,REC 集群无法正确启动。解决方法是使用 NTP 同步底层 K8s 节点。
-
删除已部署 REC 的 OpenShift 项目可能会挂起 (RED-47192)当 REC 集群部署在项目(命名空间)中并且具有 REDB 资源时,必须先删除 REDB 资源,然后才能删除 REC。因此,在删除 REDB 资源之前,项目删除将挂起。解决方法是先删除 REDB 资源,然后再删除 REC。然后,您可以删除项目。
-
在基于 OLM 的部署中,集群必须命名为“rec”(RED-39825)在 OLM 部署的操作员中,如果名称不是“rec”,则集群部署将失败。当通过 OLM 部署操作员时,安全上下文约束 (scc) 将绑定到特定的服务帐户名称(即“rec”)。解决方法是将集群命名为“rec”。
-
故障时就绪探测不正确 (RED-39300)在节点发生故障时运行时,STS 就绪探测不会将节点标记为“未就绪”
rladmin status。 -
内部 DNS 和 Kubernetes DNS 可能存在冲突 (RED-37462)集群
mdns_server和 K8s DNS 之间可能存在 DNS 冲突。这只会影响集群节点内部针对 Kubernetes DNS 名称的 DNS 解析。 -
基于 K8s 的 5.4.10 集群似乎会对现有的 5.4.6 集群产生负面影响(RED-37233)将集群升级到最新版本。
-
报告的是节点 CPU 使用率而不是 pod CPU 使用率 (RED-36884)在 Kubernetes 中,报告的节点 CPU 使用率是托管 REC pod 的 Kubernetes 工作节点的使用率。
-
无法访问的集群状态为正在运行 (RED-32805)当集群处于无法访问状态时,该状态保持不变
running,而不会触发错误。 -
集群名称过长会导致路由被拒绝 (RED-25871)集群名称长度超过 20 个字符会导致路由配置被拒绝,因为域名的主机部分超过 63 个字符。解决方法是将集群名称限制为 20 个字符或更少。
-
无效更新后不会报告集群 CR(REC)错误(RED-25542)如果按顺序更新两个或更多无效 CR 资源,则不会报告集群 CR 规范错误。