Redis Enterprise Kubernetes 版发行说明 6.2.18-3（2022 年 11 月）

添加了对其他发行版的支持，以及功能改进和错误修复。

概述

Redis Enterprise K8s 6.2.18-3 支持 Redis Enterprise Software 版本 6.2.18，并包括功能改进和错误修复。

下面介绍了关键的 bug 修复、新功能和已知限制。

图像

此版本包括以下容器映像：

• Redis 企业版：redislabs/redis:6.2.18-58或redislabs/redis:6.2.18-58.rhel8-openshift（或redislabs/redis:6.2.18-58.rhel7-openshift如果从 RHEL 7 升级）
• 作员：redislabs/operator:6.2.18-3
• 服务索具：redislabs/k8s-controller:6.2.18-3或redislabs/services-manager:6.2.18-3（在 Red Hat 注册表中）

新功能

• 支持 Auto Tiering （RED-78613）

功能改进

• 这podSecurityPolicyName字段输入RedisEnterpriseClusterresources 现在在 Kubernetes 版本 1.24 或更早版本中已弃用，在 1.25 及更高版本中无效。建议客户改用PodSecurityAdmission或实施 Pod 安全性的替代方法 （RED-81921）。

• 除了以前和现在受支持的 Tanzu Kubernetes Grid Integration Edition （TKGI） 之外，还增加了对 VMware Tanzu Kubernetes Grid （TKG） 的支持 （RED-65630）。

• 添加了对通过 Redis Enterprise 集群 API 进行 PEM 加密的支持 （RED-78613）。

• 强化了安全上下文约束，以与 OpenShift 4.11 的标准保持一致 （RED-83215）。

• 更改了日志收集器默认值，以避免收集非 Redis Enterprise 日志和项目 （RED-83216）。

• 允许配置 Redis Enterprise 集群 （REC） 服务类型 （RED-84644）。

Bug 修复

• 使用 NGINX Ingress Controller 时允许任何 Ingress 类名注释。这不再需要完全nginx（红色 79205）。
• 修复了 Windows 上对命名空间参数的日志收集器处理 （RED-83532）。
• 修复了使用路由从外部访问集群时在 OpenShift 上更新凭证的问题（RED-73251、RED-75329）。

API 变更

以下字段已添加到 Redis Enterprise 集群 （REC） API 中：

• 添加.services.apiService.type以允许配置 API 服务类型。
• 䍬.redisOnFlashSpec默认情况下可用。
• 䍬.ocspConfiguration默认情况下，可用于配置 OCSP 装订。
• 䍬.encryptPkeys默认情况下可用于配置 PEM 加密。

以下字段已添加到 Redis Enterprise 数据库 （REDB） API 中：

• .isRoF和.rofRamSize添加了以支持 Auto Tiering 功能。

兼容性说明

下表显示了此版本发布时支持的发行版。有关当前支持的发行版列表，请参阅支持的 Kubernetes 发行版。

* 此版本中添加的支持

升级前

请注意，此版本中包含的以下更改会影响升级过程。升级前请仔细阅读。

支持的升级路径

如果您使用的是 Operator 版本 6.2.8-15 或更早版本，则无法直接升级到 Operator 版本 6.2.12 到 6.4.2-5。您必须先升级到 Operator 版本 6.2.10-45，然后才能升级到 6.2.12 和 6.4.2-5 之间的 Operator 版本。但是，支持直接升级到 Operator 版本 6.4.2-6。

OpenShift 版本 6.2.12 或更低版本

由于 SCC 中的更改，在运行版本 6.2.12 或更早版本的 OpenShift 集群上升级到版本 6.2.18 或更高版本，其中node:1不是主节点，则升级可能会卡住。

有关防止此问题的更多信息和步骤，请参阅升级 Redis Enterprise 集群 （REC）。

Operator 版本 6.4.2-6 包含此问题的修复。

大型集群

在具有 9 个以上 REC 节点的集群上，在某些情况下，Kubernetes 升级可能会导致 Redis 集群无响应。6.4.2-5 版本中提供了修复。在升级 Kubernetes 集群之前，请将 Operator 版本升级到 6.4.2-5 或更高版本。

已知限制

大型集群

在具有 9 个以上 REC 节点的集群上，在某些情况下，Kubernetes 升级可能会导致 Redis 集群无响应。6.4.2-5 版本中提供了修复。在升级 Kubernetes 集群之前，请将 Operator 版本升级到 6.4.2-5 或更高版本。（红色-93025）

• 较长的集群名称会导致路由被拒绝 （RED-25871）

  超过 20 个字符的集群名称将导致路由配置被拒绝，因为域名的主机部分将超过 63 个字符。解决方法是将集群名称限制为 20 个字符或更少。

• 更新无效后，不会报告群集 CR （REC） 错误 （RED-25542）

  如果依次更新了两个或多个无效的 CR 资源，则不会报集群 CR 规格错误。

• 无法访问的集群的状态为 running （RED-32805）

  当集群处于 unreachable 状态时，状态仍为running而不是作为错误报告。

• 故障时就绪探针不正确 （RED-39300）

  STS Readiness 探测在运行时不会将节点标记为 “not ready”rladmin status节点故障时。

• 内部 DNS 和 Kubernetes DNS 可能存在冲突 （RED-37462）

  集群之间可能存在 DNS 冲突mdns_server和 K8s DNS。这仅影响集群节点内 Kubernetes DNS 名称的 DNS 解析。

• 5.4.10 对 5.4.6 产生负面影响 （RED-37233）

  基于 Kubernetes 的 5.4.10 部署似乎会对共享 Kubernetes 集群的现有 5.4.6 部署产生负面影响。

• 报告节点 CPU 使用率而不是 Pod CPU 使用率 （RED-36884）

  在 Kubernetes 中，我们报告的节点 CPU 使用率是托管 REC Pod 的 Kubernetes 工作节点的使用率。

• 在基于 OLM 的部署中，集群必须命名为 “rec” （RED-39825）

  在 OLM 部署的 Operator 中，如果名称不是 “rec”，则集群部署将失败。通过 OLM 部署 Operator 时，安全上下文约束 （scc） 将绑定到特定的服务账户名称（即“rec”）。解决方法是将集群命名为 “rec”。

• REC 集群无法在时钟不同步的 Kubernetes 集群上启动 （RED-47254）

  当 REC 集群部署在时钟不同步的 Kubernetes 集群上时，REC 集群无法正常启动。解决方法是使用 NTP 同步底层 K8s 节点。

• 删除部署了 REC 的 OpenShift 项目可能会挂起 （RED-47192）

  当 REC 集群部署在项目（命名空间）中并具有 REDB 资源时，必须先删除 REDB 资源，然后才能删除 REC。因此，在删除 REDB 资源之前，项目删除将挂起。解决方法是先删除 REDB 资源，然后再删除 REC。之后，您可以删除该项目。

• Hashicorp Vault 集成 - 不支持 Gesher （RED-55080）

  目前没有解决方法。

• REC 可能会在初始启动时报告错误状态 （RED-61707）

  目前除了忽略这些错误外，没有其他解决方法。

• 在规范中使用十进制值时出现 PVC 大小问题 （RED-62132）

  此问题的解决方法是确保对 PVC 大小使用整数值。

• 遵循旧版快速入门指南会导致由于无法识别的内存字段名称而导致创建 REDB 时出现问题 （RED-69515）

  解决方法是使用在线提供的快速入门文档的较新（当前）修订版。

• autoUpgrade在以下情况下，设置为 true 可能会导致 BDB 意外升级redisUpgradePolicy设置为 true （RED-72351）

  如果您的部署受到影响，请联系支持人员。

安全

有关与 CVE 相关的修复列表，请参阅 Redis Enterprise 6.2.18-58 发行说明。