4.14 发行注记

阻塞列表不再会导致 pod 处于错误状态

在以前的版本中，由于网络问题或大量过载或具有大量尾部延迟激增的集群阻止列表。因此，Pods 会停留在 CreateContainerError，并带有信息 Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount/#ib_16384_0.dblwr: read-only file system。

在这个版本中，阻止列表不再会导致 pod 处于错误状态。

(BZ#2094320)

Ceph 现在识别由 Globalnet 分配的全局 IP

在以前的版本中，Ceph 无法识别 Globalnet 分配的全局 IP，因此无法使用 Globalnet 在具有重叠服务 CIDR 的集群间配置灾难恢复解决方案。这个问题已被解决，现在灾难恢复解决方案在服务 CIDR 重叠时可以正常工作。

(BZ#2104971)

当工作负载通过或重新定位到对等集群时，PeerReady 状态不再被设置为 true，直到从中清理或重新定位的集群为止

在以前的版本中，在启动灾难恢复(DR)操作后，当工作负载故障转移或重新定位到对等集群时，PeerReady 条件会在持续时间内最初设置为 true。把它设置为 false 后，直到从其中清理或重新定位到集群被清理或重新定位到集群以进行将来的操作。查看 DRPlacementControl 状态条件的用户可能已将这个中间 PeerReady 状态识别为对等状态，以便采取行动并执行。这会导致操作待处理或失败，并可能需要用户干预才能从中恢复。

在这个版本中，在清理失败或重新定位工作负载前，PeerReady 状态不再被设置为 true，因此用户不再有混淆。

(BZ#2138855)

当 ACM hub 在灾难后恢复时，应用程序不再处于 Cleaningup 状态

在以前的版本中，当 ACM hub 在灾难过程中丢失，并使用备份恢复时，VRG ManifestWork 和 DRPC 状态不会被恢复。这会导致应用程序处于 Cleaningup 状态。

在这个版本中，Ramen 可确保 VRG ManifestWork 是 ACM 备份的一部分，并在 hub 恢复后重新创建 DRPC 状态，应用程序可以成功迁移到故障转移集群。

(BZ#2162469)

基于 STS 的应用程序现在可以按预期重新定位

在以前的版本中，因为底层程序错误，重新定位基于 STS 的应用程序会失败。这个程序错误已被解决，重新定位基于 STS 的应用程序现在可以正常工作。

(BZ#2224325)

hub 恢复后 ramen 协调

在以前的版本中，当使用主动/被动 Hub Metro-DR 设置时，您可能会遇到罕见的场景，Ramen 协调器会在超过其允许速率限制参数后停止运行。因为协调特定于每个工作负载，因此只有该工作负载会受到影响。在这种情况下，与那个工作负载相关的所有灾难恢复编配活动停止直到 Ramen pod 重启为止。

这个问题已被解决，在 hub 恢复后 Ramen 协调如预期。

(BZ#2175201)

在 hub 恢复过程中不会删除受管资源

在以前的版本中，在 hub 恢复过程中，OpenShift Data Foundation 遇到 Red Hat Advanced Cluster Management 版本 2.7.4 （或更高）的已知问题，其中某些与基于订阅的工作负载关联的资源可能会被意外删除。

这个问题已被解决，在 hub 恢复过程中不会删除受管资源。

(BZ#2211643)

Virtual-host 风格现在包括在 NooBaa bucket 中

在以前的版本中，Virtual-host 风格无法在 NooBaa bucket 上工作，因为 NooBaa 端点和内核不知道 DNS 配置的端口。

在这个版本中，NooBaa 操作器将 DNS 的端口传递给核心和端点，使 Virtual-host 风格可用。

(BZ#2183092)

虚拟凭证不再输出到日志中

在以前的版本中，dummy 凭证会被输出到日志中，这可能会导致混淆。这个程序错误已被解决，凭证将不再被打印。

(BZ#2189866)

当有限时间内没有提供凭证时，NooBaa 现在会回退到使用带有 pv-pool 的后备存储

当云凭证 Operator 在创建云凭证请求后无法提供 secret 时，例如在安装 NooBaa 云凭证 Operator 模式之前，云凭证 Operator 模式被设置为手动模式，且不会进行额外的必要的操作。提供的 secret 包括为默认后备存储创建目标存储桶所需的凭证。这意味着，默认后备存储没有创建，Noobaa 在阶段配置中卡住。

在这个版本中，如果发送了云凭证请求，且无法在定义的时间(10 分钟)中获取 secret，则 NooBaa 将回退到使用类型为 pv-pool 的后备存储。这意味着系统应处于 Ready 状态，默认后备存储应该类型为 pv-pool。

(BZ#2242854)

PostgreSQL DB 密码不再以明文形式显示在内核和端点日志中

在以前的版本中，noobaa-core 中的内部 Postgresql 客户端将连接参数对象输出到日志，此对象包含用于连接 Postgresql DB 的密码。

在这个版本中，在打印到日志的连接对象中省略了密码信息，日志的信息仅包含非敏感的连接详情。

(BZ#2240778)

升级后，CSI CephFS 和 RBD 拥有者 Pod 不再使用旧的 cephcsi 镜像

在以前的版本中，在升级 CSI CephFS 和 RBD 拥有者 Pod 后，它们不会被更新，因为它们使用旧的 cephcsi 镜像。

在这个版本中，CSI CephFS 和 RBD 拥有者的 daemonset 对象也会升级，CSI 拥有者 pod 使用最新的 cephcsi 镜像。

(BZ#2219536)

更可靠和控制的重新同步过程

在以前的版本中，resync 命令不会被有效地触发，从而导致同步问题，且无法禁用镜像镜像。这是因为 CephCSI 依赖于镜像镜像状态来发出 resync 命令，因为状态不可预测的更改。

在这个版本中，当卷被降级时，CephCSI 会保存创建镜像的时间戳。发出 resync 命令时，CephCSI 将保存的时间戳与当前创建时间戳进行比较，只有在时间戳匹配时才会进行 resync。另外，CephCSI 检查镜像的状态以及最后一个快照时间戳，以确定是否需要重新同步，或者是否需要显示错误消息。这会产生一个更可靠且受控的重新同步过程。

(BZ#2165941)

因为 S3 客户端无法在同一区与 RGW 通信，所以不再需要网络延迟

在以前的版本中，当使用 Ceph 对象存储以及请求传输到另一个区时，不需要的网络延迟，因为 S3 客户端无法在同一区域中与 RGW 通信。

在这个版本中，注解 "service.kubernetes.io/topology-mode" 添加到 RGW 服务中，以便请求路由到同一区域中的 RGW 服务器。因此，pod 会被路由到最接近的 RGW 服务。

(BZ#2209098)

从用户界面中删除卷类型下拉菜单

在以前的版本中，对于内部 OpenShift Data Foundation 安装，用户界面为现有集群显示 HDD、SSD 或两者，即使内部安装应该假定磁盘是 SSD。

在这个版本中，卷类型下拉菜单已从用户界面中删除，并且始终假定它是 SSD。

(BZ#2239622)

OpenShift Data Foundation Topology rook-ceph-operator 部署现在显示正确的资源

在以前的版本中，CSI pod 和其他 pod 的所有者引用被设置为 rook-ceph-operator，这会导致映射显示这些 pod 作为部署的一部分。

在这个版本中，映射 pod 方法被改为 top down 而不是 bottom up，这样可确保仅显示与部署相关的 pod。

(BZ#2209251)

设置了 CSS 属性，将资源列表的高度调整为窗口大小的变化

在以前的版本中，拓扑视图资源列表的边栏不会根据窗口大小调整其长度，因为 CSS 属性没有正确地应用到侧边栏。

在这个版本中，CSS 属性被设置为在全屏和常规屏幕模式下动态调整资源列表的高度变化。

(BZ#2209258)

当从 LSO 移到默认存储类时，添加容量操作不再会失败

在以前的版本中，当从 LSO 移到默认存储类时，用于添加容量操作，因为无法正确创建扩展的持久性卷(PV)。

在这个版本中，当存储集群最初使用基于 LSO 的存储类创建时，不允许使用非LSO 存储类添加容量操作。

(BZ#2213183)

OpenShift Data Foundation 拓扑的资源使用现在与指标匹配

在以前的版本中，OpenShift Data Foundation 拓扑的资源利用率与指标不匹配，因为侧边栏用于节点和部署的资源列表中使用的指标查询不同。

在这个版本中，指标查询相同，因此值在两个位置都相同。

(BZ#2214033)

现在禁用了外部模式的拓扑视图

在以前的版本中，拓扑视图显示外部模式的空白屏幕，因为拓扑视图中不支持外部模式。

在这个版本中，外部模式被禁用，并显示一条消息而不是空白屏幕。

(BZ#2216707)

拓扑不再在每个节点上显示 rook-ceph-operator

在以前的版本中，拓扑视图显示所有节点中的 Rook-Ceph 操作器部署，因为 Rook-Ceph 操作器部署是多个 pod 的所有者，它们实际上与它无关。

在这个版本中，拓扑视图中部署到节点的映射机制已更改，因此 Rook-Ceph 操作器部署仅在一个节点中显示。

(BZ#2233027)

控制台用户界面不再显示 SDN 而不是 OVN

在以前的版本中，控制台用户界面显示 SDN 而不是 OVN，即使 OpenShift Container Platform 已从 SDN 移到 OVN。

在这个版本中，文本已从 SDN 改为 OVN，因此管理网络的文本会显示 OVN。

(BZ#2233731)

资源名称必须遵循规则，"starts 和以小写或数字结尾，或者 regex 会返回错误

在以前的版本中，由于对对象存储桶声明(OBC)的输入名称无效 regex 验证，后备存储、阻塞池、命名空间存储和存储桶类时，当名称的开头输入符号或大写字母时，规则"starts 和 number"会违反。

在这个版本中，这个问题已被解决，如果资源名称没有遵循该规则，"starts 和以小写字母或数字"结尾，regex 会返回错误。

(BZ#2193109)

ODF 监控不再缺少任何指标值

在以前的版本中，ceph-exporter 的服务监控缺少端口。这意味着 Ceph 守护进程性能指标缺失。

在这个版本中，添加了 ceph-exporter 服务监控器的端口，Ceph 守护进程性能指标可在 prometheus 中可见。

(BZ#2221488)

如果出现网络问题，OSD pod 不再继续 flapping

在以前的版本中，如果 OSD pod 由于网络问题启动 flapping，则它们将继续 flapping。这会给系统造成负面影响。

在这个版本中，在一定时间后，flapping OSD pod 被标记为 down，不再影响系统。

(BZ#2223959)

MDS 不再被不必要重启

在以前的版本中，MDS pod 被不必要重启，因为存活度探测在不检查 ceph fs dump 的情况下会重启 MDS。

在这个版本中，存活度探测监控 ceph fs dump 中的 MDS，只有在转储输出中缺少 MDS 时重启 MDS。

(BZ#2234377)

故障转移操作报告 pod 上的 RADOS 块设备镜像挂载在仍然在使用中的 RPC 错误时失败

在灾难恢复(DR)受保护的工作负载时，可能会导致在故障转移集群中使用卷处于卡住的 pod，报告 RADOS 块设备(RBD)镜像仍在使用。这可防止 pod 在很长时间内启动（最多几个小时）。

(BZ#2007376)

为受管集群创建应用程序命名空间

应用程序命名空间需要存在于 RHACM 受管集群中，用于灾难恢复 (DR) 相关的预部署操作，因此当应用程序部署在 RHACM hub 集群中时预先创建。但是，如果在 hub 集群中删除某个应用程序，并且在受管集群中删除对应的命名空间，则会在受管集群上重新应用。

临时解决方案： openshift-dr 在 RHACM hub 的受管集群命名空间中维护一个命名空间 manifestwork 资源。需要在应用程序删除后删除这些资源。例如，作为集群管理员，在 hub 集群上执行以下命令： oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw。

(BZ#2059669)

当集群处于扩展模式时，Ceph df 会报告一个无效的 AVAIL 值

当 Red Hat Ceph Storage 集群的 crush 规则具有多个"take"步骤时，ceph df 报告显示该映射的最大可用大小。这个问题将在即将推出的版本中解决。

(BZ#2100920)

这两个 DRPC 都保护在同一命名空间中创建的所有持久性卷声明

托管多个灾难恢复(DR)保护工作负载的命名空间，保护 hub 集群上每个 DRPlacementControl 资源的命名空间，该命名空间不根据 spec.pvcSelector 字段在工作负载上指定并隔离 PVC。

这会生成 PVC，它与多个工作负载的 DRPlacementControl spec.pvcSelector 匹配。或者，如果所有工作负载都缺少选择器，复制管理可能会多次管理每个 PVC，并根据单独的 DRPlacementControl 操作造成数据崩溃或无效操作。

临时解决方案：标签 PVC 属于唯一工作负载，并使用所选标签作为 DRPlacementControl spec.pvcSelector，以忽略哪个 DRPlacementControl 保护和管理命名空间中的哪些 PVC 子集。无法使用用户界面为 DRPlacementControl 指定 spec.pvcSelector 字段，因此必须使用命令行删除并创建此类应用程序的 DRPlacementControl。

结果： PVC 不再由多个 DRPlacementControl 资源管理，不会造成任何操作和数据不一致。

(BZ#2111163)

MongoDB pod 处于 CrashLoopBackoff，因为的权限错误读取 cephrbd 卷中的数据

跨不同受管集群的 OpenShift 项目具有不同的安全性上下文约束 (SCC)，这在指定的 UID 范围和/或 FSGroups 中有所不同。这会导致某些工作负载 pod 和容器无法在这些项目中启动后故障转移或重新定位操作，因为日志中的文件系统访问错误。

临时解决方案：确保在所有带有同一项目级别的 SCC 标签的受管集群中创建工作负载项目，以便在通过或重新定位失败时使用相同的文件系统上下文。Pod 不再对文件系统相关的访问错误失败失败。

(BZ#2114573)

应用程序在重新定位过程中处于 Relocating 状态

Multicloud Object Gateway 允许将相同名称或命名空间的多个持久性卷 (PV) 对象添加到同一路径的 S3 存储中。因此，Ramen 不会恢复 PV，因为它检测到指向同一 claimRef 的多个版本。

临时解决方案：使用 S3 CLI 或等同于从 S3 存储清理重复的 PV 对象。仅保持接近故障转移或重新定位时间的时间戳的那一个。

结果：恢复操作将继续完成，故障切换或重新定位操作会继续下一步。

(BZ#2120201)

灾难恢复工作负载在删除时会卡住

当从集群中删除工作负载时，对应的 pod 可能无法与 FailedKillPod 等事件终止。这可能会导致垃圾收集依赖的 DR 资源（如 PVC、VolumeReplication 和 VolumeReplicationGroup）的延迟或失败。它还可防止以后将相同的工作负载部署到集群中，因为过时的资源还没有垃圾回收。

临时解决方案：重启正在运行 pod 的 worker 节点，并处于终止状态。这会导致 pod 终止以及随后相关的 DR API 资源被收集垃圾回收。

(BZ#2159791)

当受管集群位于不同版本的 OpenShift Container Platform 和 OpenShift Data Foundation 时，应用程序故障切换会处于 FailingOver 状态

使用 OpenShift Data Foundation 4.14 的灾难恢复解决方案除了持久性卷(PV)数据外，还保护并恢复持久性卷声明(PVC)数据。如果主集群位于旧的 OpenShift Data Foundation 版本，并且目标集群更新至 4.14，则故障转移将卡住，因为 S3 存储不会具有 PVC 数据。

临时解决方案：在升级灾难恢复集群时，必须首先升级主集群，然后必须运行升级后的步骤。

(BZ#2214306)

当 DRPolicy 应用到同一命名空间中的多个应用程序时，不会创建卷复制组

当为与命名空间中的其他应用程序在一起的应用程序创建 DRPlacementControl (DRPC)时，DRPC 没有为应用设置标签选择器。如果对标签选择器进行任何更改，OpenShift Data Foundation Hub 控制器中的验证准入 Webhook 会拒绝更改。

临时解决方案：更改准入 Webhook 以允许此类更改，DRPC validatingwebhookconfigurations 可以修补以删除 Webhook。

oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

$ oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

(BZ#2210762)

在 FailingOver 中将应用程序从 c1 故障转移到 c2 集群挂起。

当因为 s3 存储错误配置导致数据没有上传到 s3 存储错误配置时，Ramen 不会禁用故障转移操作。这意味着故障转移过程中在故障转移集群中无法使用集群数据。因此，无法完成故障转移。

临时解决方案：在初始部署后检查日志以确保没有报告 s3 配置错误。

oc get drpc -o yaml

$ oc get drpc -o yaml

(BZ#2248723)

hub 恢复后数据丢失的潜在风险

因为旨在清理孤立资源而在 hub 恢复后存在潜在的数据丢失风险。这会识别并标识对于集合缺少对应 ManifestWorks 的 AppliedManifestWorks 实例。提供了 1 小时的硬编码宽限期。在这个周期过后，与 AppliedManifestWork 关联的任何资源都会受到垃圾回收的影响。

如果 hub 集群无法在初始一小时窗口中重新生成对应的 ManifestWorks，则可能会出现数据丢失。这重点介绍了及时解决可能防止在 ManifestWorks 后恢复 后重新创建的问题的重要性，以最大程度降低数据丢失的风险。

(BZ-2252933)

CephFS 上扩展集群的性能不佳

具有许多小元数据操作的工作负载可能会因为在多站点 Data Foundation 集群上放置元数据服务器(MDS)造成性能不佳。

(BZ#1982116)

SELinux 重新标记问题，带有大量文件

当将卷附加到 Red Hat OpenShift Container Platform 中的 pod 时，pod 有时无法启动或需要很长时间才能启动。这个行为是通用的，它绑定到 Kubelet 处理 SELinux 重新标记的方式。对于任何基于文件系统的卷，会发现这个问题。在 OpenShift Data Foundation 中，使用基于 CephFS 的卷和大量文件时会出现此问题。解决此问题的方法有多种。根据您的业务需求，您可以从知识库解决方案 https://access.redhat.com/solutions/6221251 中选择一个临时解决方案。

(Jira#3327)

运行崩溃或关闭测试后 Ceph 无法访问

在扩展集群中，当 monitor 被 revived 且处于其他 monitor 的探测阶段时，无法接收最新的信息，如 monitorMap 或 OSDMap，它无法在 probing 阶段进入 stretch_mode。这可防止它正确设置 elector 的 disallowed_leaders 列表。

假设 revived monitor 实际上具有最佳分数，它认为它最好是当前选举循环中的领导者，并会导致 monitor 的选举阶段卡住。因为它会持续推出自己，但会因为 disallowed_leaders 列表被 surviving monitor 拒绝。这会导致 monitor 处于选举状态，Ceph 最终会变得无响应。

要解决这个问题，当处于选举状态且 Ceph 变得无响应时，使用以下命令重置每个 monitor 的连接分数：

`ceph daemon mon.{name} connection scores reset`

`ceph daemon mon.{name} connection scores reset`

如果这不起作用，请逐一重新启动 monitor。选举随后将被解放，监视器将能够选举领导机，形成仲裁，Ceph 将再次响应。

(BZ#2241937)

Ceph 在工作负载部署后 没有报告活跃 mgr

在工作负载部署后，Ceph 管理器丢失了与 MON 的连接，或者无法响应其存活度探测。

这会导致 ODF 集群状态报告是否有 "no active mgr"。这会导致多个使用 Ceph 管理器请求处理的操作失败。例如，卷调配、创建 CephFS 快照等。

要检查 ODF 集群的状态，请使用 oc get cephcluster -n openshift-storage 命令。在状态输出中，如果集群有此问题，status.ceph.details.MGR_DOWN 字段将具有消息 "no active mgr"。

要解决这个问题，请使用以下命令重启 Ceph 管理器 pod：

oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=0

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=0

oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=1

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=1

运行这些命令后，ODF 集群状态会报告一个健康的集群，没有有关 MGR_DOWN 的警告或错误。

(BZ#2244873)

当 StorageCluster 中使用自定义 deviceClass 时，CephBlockPool 创建会失败

由于一个已知问题，当 StorageCluster 中使用自定义 deviceClass 时，CephBlockPool 创建会失败。

(BZ#2248487)

自动扁平化快照无法正常工作

当有一个常见的父 RBD PVC 时，如果卷快照、恢复和删除快照是在超过 450 次的序列中执行的，则无法进行卷快照或克隆通用父 RBD PVC。

要解决这个问题，而不是按顺序执行卷快照、恢复和删除快照，您可以使用 PVC 克隆来完全避免这个问题。

如果您达到此问题，请联系客户支持来手动扁平化最终恢复 PVC，以继续对常见父 PVC 进行卷快照或克隆。

(BZ#2232163)

缺少 NodeStageVolume RPC 调用会阻止新 pod 进入 Running 状态

NodeStageVolume RPC 调用不会被发出，阻止某些 pod 进入 Running 状态。新 pod 会永久处于 Pending 状态。

要解决这个问题，请一次性缩减所有受影响的 pod，或者重启节点。应用临时解决方案后，所有 pod 应该处于 Running 状态。

(BZ#2244353)

备份无法传输数据

在某些情况下，备份无法传输数据，快照 PVC 处于 Pending 状态。

(BZ#2248117)