Redis Enterprise for Kubernetes 发行说明 7.2.4-7(2023 年 10 月)
这是一个次要维护版本,对 Kubernetes 产品进行了一些增强/修复,并提供了更新的 Redis Enterprise 容器版本。
适用于 Kubernetes 的 Redis Enterprise |
---|
突出
这是一个次要维护版本,对 Kubernetes 产品进行了一些增强/修复,并提供了更新的 Redis Enterprise 容器版本。
以下是显著的变化:
- 使用基于 RHEL 7 的映像且已使用此版本 7.2 的客户可以在升级时迁移到基于 RHEL 8 的映像。
- 以前,您无法将集群迁移到较新的作系统版本。
- 所有客户都应计划迁移到基于 RHEL 8 的映像。Redis Enterprise 的下一个主要版本将不支持 RHEL 7。
- 此过程需要特定的先决条件和作。更新的指南正在开发中,很快就会推出。
- 将 VMware TKG 2.1 和 2.2 添加到支持的发行版表中。
此版本中的新增功能
增强
- 支持在升级期间从 RHEL7 镜像迁移到 RHEL8 (RED-106785)
- 支持 Redis 企业软件版本 7.2.4-64 (RED-108832)
已解决的问题
- 修复了使用非默认模块时的集群恢复流程(RED-107711、RED-106872)
版本变更
有关与 CVE 相关的修复列表,请参阅 Redis Enterprise 7.2.4-64 发行说明。
重大更改
此版本中包含的以下更改会影响升级过程。在升级到 7.2.4-7 之前,请仔细阅读。
验证 WebhookConfiguration
版本 6.4.2-4 及更高版本包括新的ValidatingWebhookConfiguration
资源将redb-admission
webhook 资源。要使用版本 6.4.2-4 或更高版本,请删除旧的 Webhook 资源并应用新文件。有关说明,请参阅升级 Redis 集群。
OpenShift SCC
版本 6.4.2-6 及更高版本包括新的 SCC (redis-enterprise-scc-v2
),您需要在升级之前绑定到您的服务账户。如果跳过此步骤,则运行版本 6.2.12 或更早版本升级到版本 6.2.18 或更高版本的 OpenShift 集群可能会卡住。有关说明,请参阅升级 Redis Enterprise 集群 (REC)。
即将进行的更改
- Redis Enterprise 的未来版本将取消对 RHEL7 的支持。我们建议迁移到 RHEL8。
支持的发行版
下表显示了此版本发布时支持的发行版。您还可以在 支持的 Kubernetes 发行版中找到此列表。
✅ 支持 – 此版本的 Redis Enterprise Software for Kubernetes 支持此发行版。
⚠️已弃用 – 此版本的 Redis Enterprise Software for Kubernetes 仍支持此发行版,但在未来版本中将删除支持。
❌ End of life (生命周期终止) – 对此发行版的支持已结束。
生产工作负载不支持下面未列出的任何发行版。
Kubernetes 版本 | 1.22 | 1.23 | 1.24 | 1.25 | 1.26 | 1.27 |
---|---|---|---|---|---|---|
社区 Kubernetes | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ |
亚马逊 EKS | ❌ | ⚠️ | ✅ | ✅ | ✅ | ✅ |
Azure AKS | ❌ | ❌ | ✅ | ✅ | ✅ | |
谷歌 GKE | ❌ | ⚠️ | ✅ | ✅ | ✅ | ✅ |
牧场主 2.6 | ❌ | ❌ | ⚠️ | |||
牧场主 2.7 | ⚠️ | ✅ | ✅ | |||
VMware TKG 1.6 版 | ⚠️ | ⚠️ | ||||
VMware TKG 2.1 | ⚠️ | ⚠️ | ✅ | |||
VMware TKG 2.2 | ✅ | ✅ | ✅ | |||
OpenShift 版本 | 4.9 | 4.10 | 4.11 | 4.12 | 4.13 | |
❌ | ⚠️ | ✅ | ✅ | ✅ | ||
VMware TKGI 版本 | 1.13 | 1.14 | 1.15 | 1.16 | ||
❌ | ⚠️ | ✅ | ✅ |
下载
- Redis 企业版:
redislabs/redis:7.2.4-64
- 作员:
redislabs/operator:7.2.4-7
- 服务索具:
redislabs/k8s-controller:7.2.4-7.
OpenShift 镜像
- Redis 企业版:
registry.connect.redhat.com/redislabs/redis-enterprise:7.2.4-64.rhel8-openshift
(或redislabs/redis-enterprise:7.2.4-64.rhel7-openshift
如果从 RHEL 7 升级) - 作员:
registry.connect.redhat.com/redislabs/redis-enterprise-operator:7.2.4-7
- 服务索具:
registry.connect.redhat.com/redislabs/services-manager:7.2.4-7
OLM 捆绑包
Redis Enterprise作员捆绑包 :v7.2.4-7
已知限制
以下限制特定于 Redis Enterprise for Kubernetes 产品。要查看受支持的 Redis Enterprise Software 版本的限制,请参阅 7.2.4 发行说明。
现有限制
-
使用 6.2.10-4 之前的版本创建的 REDB 将在集群升级时自动升级模块 (RED-106834)
-
修改主动-主动数据库的数据库后缀时,当 service-rigger 处于 terminating 状态时,services-rigger 将取消报销并在循环中创建入口或路由资源 (RED-107687)等到 services- rigger pod 完成以终止它。
-
REAADB 更改可能会失败,并显示“网关超时”错误,主要在 OpenShift 上 (RED-103048)重试该作。
-
当服务创建因服务已存在而失败时,会出现误导性错误
provided IP is already allocated
“ (RED-100669)手动删除服务。 -
创建 REC 期间的现有 OpenShift 路由可能会阻止 REC 启动 (RED-100668)手动删除路由。
-
直接在 Redis Enterprise 软件上创建两个同名数据库将导致服务被删除,并且数据库将不可用 (RED-99997)避免重复数据库名称。通过 K8s 创建数据库已进行验证以防止这种情况。
-
安装 Operator 捆绑包时会产生警告:
Warning: would violate PodSecurity "restricted: v1.24"
(红色-97381)忽略该警告。此问题在 Red Hat 官方文档中记录为良性。 -
RERC 资源必须具有唯一名称 (RED-96302)字符串 “rec-name”/“rec-namespace” 必须与主动-主动数据库中所有其他参与的集群不同。
-
准入不会阻止 REAADB
shardCount
超过许可证配额 (RED-96301)修复 REAADB 的问题并重新应用。 -
主动-主动控制器仅支持全局数据库选项。不支持特定于位置的配置 (RED-86490)
-
主动-主动安装程序删除可能会使服务或路由保持不被删除 (RED-77752)如果遇到此问题,请手动删除服务或路由。
-
autoUpgrade
设置为true
在以下情况下可能会导致意外的 BDB 升级redisUpgradePolicy
设置为true
(红色-72351)如果您的部署受到影响,请联系支持人员。 -
遵循前面的快速入门指南版本,由于内存字段名称无法识别,导致创建 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 部署的 Operator 中,如果名称不是 “rec”,则集群部署将失败。通过 OLM 部署 Operator 时,安全上下文约束 (scc) 将绑定到特定的服务账户名称(即“rec”)。解决方法是将集群命名为 “rec”。
-
故障时就绪探针不正确 (RED-39300)STS Readiness 探测在运行时不会将节点标记为 “not ready”
rladmin status
节点故障时。 -
内部 DNS 和 Kubernetes DNS 可能存在冲突 (RED-37462)集群之间可能存在 DNS 冲突
mdns_server
和 K8s DNS。这仅影响集群节点内 Kubernetes DNS 名称的 DNS 解析。 -
基于 K8s 的 5.4.10 集群似乎会对现有的 5.4.6 集群产生负面影响 (RED-37233)将集群升级到最新版本。
-
报告节点 CPU 使用率而不是 Pod CPU 使用率 (RED-36884)在 Kubernetes 中,报告的节点 CPU 使用率是托管 REC Pod 的 Kubernetes 工作节点的使用率。
-
无法访问的集群的状态为 running (RED-32805)当集群处于无法访问状态时,状态将保持
running
而不是触发错误。 -
较长的集群名称会导致路由被拒绝 (RED-25871)超过 20 个字符的集群名称将导致路由配置被拒绝,因为域名的主机部分超过 63 个字符。解决方法是将集群名称限制为 20 个字符或更少。
-
无效更新后,不会报告群集 CR (REC) 错误 (RED-25542)如果依次更新了两个或多个无效的 CR 资源,则不会报集群 CR 规格错误。