Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

1.6. 程序错误修复

  • 在以前的版本中，在某些配置中，kubelet podresources API 可能会报告分配给活跃和终止的 pod 的内存，而不是只报告分配给活跃 pod 的内存。因此，这种不准确报告可能会受到 NUMA 感知调度程序影响的工作负载放置。

    在这个版本中，kubelet 不再报告终止 pod 的资源，由 NUMA 感知调度程序(link:https://issues.redhat.com/browse/OCPBUGS-56785[OCPBUGS-56785)造成准确的工作负载放置。

1.6.1. API 服务器和客户端
复制链接

1.6.2. 裸机硬件置备
复制链接

  • 在此次更新之前，使用安装程序置备的基础架构在裸机上安装双栈集群时，安装会失败，因为 Virtual Media URL 是 IPv4，而不是 IPv6。因为 IPv4 无法访问，所以在虚拟机(VM)和集群节点中 bootstrap 会失败。在这个版本中，当在安装程序置备的基础架构的裸机上安装双栈集群时，双栈集群会使用 Virtual Media URL IPv6，这个问题已解决。(OCPBUGS-60240)
  • 在此次更新之前，当安装裸机作为服务(BMaaS) API 的集群时，会报告一个模糊的验证错误。当您在没有校验和的情况下设置镜像 URL 时，BMaaS 无法验证部署镜像源信息。在这个版本中，当您没有为镜像提供所需的校验和时，会报告一条清晰的信息。(OCPBUGS-57472)
  • 在此次更新之前，当使用裸机安装集群时，如果没有禁用清理，硬件会在运行 coreos-installer 工具前尝试删除任何软件 RAID 配置。在这个版本中，这个问题已解决。(OCPBUGS-56029)
  • 在此次更新之前，通过使用 Redfish 系统 ID，如 redfish://host/redfish/v1/ 而不是 redfish://host/redfish/v1/Self，在 Baseboard Management Console (BMC) URL 中，报告无效 JSON 的注册错误。这个问题是由 Bare Metal Operator (BMO)中的一个错误造成的。在这个版本中，BMO 会在没有 Redfish 系统 ID 作为有效地址的情况下处理 URL，而不会造成 JSON 解析问题。在这个版本中，改进了 BMC URL 中缺少 Redfish 系统 ID 的软件处理。(OCPBUGS-55717)
  • 在此次更新之前，虚拟介质引导尝试有时会失败，因为 SuperMicro 的一些模型（如 ars-111gl-nhr ）使用与其他 SuperMicro 机器不同的虚拟介质设备字符串。在这个版本中，在 sushy 库代码中添加了一个额外的条件检查，以检查受影响的特定模型并调整其行为。因此，Supermicro ars-111gl-nhr 可以从虚拟介质引导。(OCPBUGS-55434)
  • 在此次更新之前，RAM 磁盘日志不包括明文文件分隔符，这偶尔会导致内容在一行中重叠。因此，用户无法解析 RAM 磁盘日志。在这个版本中，RAM Disk 日志包含 clear file 标头，以指示每个文件的内容之间的边界。因此，改进了用户的 RAM 磁盘日志的可读性。(OCPBUGS-55381)
  • 在此次更新之前，在 Ironic Python Agent (IPA)部署期间，metal3-ramdisk-logs 容器中的 RAM 磁盘日志不包括 NetworkManager 日志。没有 NetworkManager 日志会妨碍了有效的调试，这会影响网络问题。在这个版本中，metal3 pod 的 metal3-ramdisk-logs 容器中现有的 RAM 磁盘日志包括来自主机的整个日志，而不只是 dmesg 和 IPA 日志。因此，IPA 日志提供全面的 NetworkManager 数据，以改进调试。(OCPBUGS-55350)
  • 在此次更新之前，当在集群配置中禁用 provisioning 网络时，您可以使用需要网络引导的驱动程序创建一个裸机主机，如智能平台管理接口(IPMI)或没有虚拟介质的 Redfish。因此，检查或置备过程中会出现引导失败，因为无法识别正确的 DHCP 选项。在这个版本中，当您在这种情况下创建裸机主机时，主机无法注册，报告的错误引用禁用的 provisioning 网络。要创建主机，您必须启用置备网络，或使用基于 virtual-media 的驱动程序，如 Redfish 虚拟介质。(OCPBUGS-54965)

1.6.3. Cloud Compute
复制链接

  • 在此次更新之前，AWS 计算机器集可以包括 userDataSecret 参数的 null 值。使用 null 值有时会导致机器处于 Provisioning 状态。在这个版本中，user DataSecret 参数需要一个值。(OCPBUGS-55135)
  • 在此次更新之前，使用版本 4.13 或更早版本创建的 AWS 上的 OpenShift Container Platform 集群无法更新到 4.19 版本。使用版本 4.14 及之后的版本创建的集群默认具有 AWS cloud-conf ConfigMap，从 OpenShift Container Platform 4.19 开始需要此 ConfigMap。在这个版本中，当集群中不存在时，Cloud Controller Manager Operator 会创建一个默认的 cloud-conf ConfigMap。这个更改可让使用版本 4.13 或更早版本创建的集群更新至 4.19 版本。(OCPBUGS-59251)
  • 在此次更新之前，当 机器的 InternalDNS 地址没有如预期设置时，日志中会显示为 node …​ 信息查找机器失败。因此，用户可能会将这个错误解释为机器没有存在。在这个版本中，日志消息读取 failed to find machine with InternalDNS matching …​。因此，用户明确表明匹配失败的原因。(OCPBUGS-19856)
  • 在此次更新之前，程序错误修复通过将故障域计数更改为使用最大可用值，而不是在 2 中修复。这会导致意外地扩展在程序错误修复前创建的计算机器集的问题，因为控制器会尝试修改不可变可用性集。在这个版本中，可用性集在创建后不再被修改，允许受影响的计算机器集正确进行扩展。(OCPBUGS-56380)
  • 在此次更新之前，从 Cluster API 迁移到 Machine API 的计算机器集会处于 Migrating 状态。因此，计算机器集无法完成转换到使用不同的权威 API 或对 MachineSet 对象状态进行进一步协调。在这个版本中，迁移控制器会监控 Cluster API 资源的更改，并对权威 API 转换做出反应。因此，计算机器集可以成功从 Cluster API 转换到 Machine API。(OCPBUGS-56487)
  • 在此次更新之前，MachineHealthCheck 自定义资源定义(CRD)中的 maxUnhealthy 字段不会记录默认值。在这个版本中，CRD 会记录默认值。(OCPBUGS-61314)
  • 在此次更新之前，可以指定在同一机器模板中使用 CapacityReservationsOnly 容量保留行为和 SpotInstances。因此，创建具有这两个不兼容设置的机器。在这个版本中，机器模板的验证可确保不会同时设置这两个不兼容的设置。因此，无法创建具有这两个不兼容设置的机器。(OCPBUGS-60943)
  • 在此次更新之前，在支持将 Machine API 资源迁移到 Cluster API 资源的集群上，删除非权威机器不会删除对应的权威机器。因此，应该在集群中清理的孤立机器保留，并可能导致资源泄漏。在这个版本中，删除非权威机器会触发删除到对应的权威机器传播。因此，在非权威机器上删除请求可以正确地级scade，防止孤立的权威机器并确保机器清理的一致性。(OCPBUGS-55985)
  • 在此次更新之前，在支持将 Machine API 资源迁移到 Cluster API 资源的集群上，Cluster CAPI Operator 可以在 Paused 状态下创建一个权威 Cluster API 计算机器集。因此，新创建的 Cluster API 计算机器集无法协调或扩展机器，即使它使用了权威 API。在这个版本中，Operator 可确保 Cluster API 计算机器集在 Cluster API 具有权威时以取消暂停状态创建。因此，新创建的 Cluster API 计算机器集会立即协调，在 Cluster API 有权威时可以继续扩展机器生命周期操作。(OCPBUGS-56604)
  • 在此次更新之前，扩展大量节点会较慢，因为扩展需要多次协调每台机器，且每台机器被单独协调。在这个版本中，最多可以同时协调十个机器。此更改提高了扩展期间机器的处理速度。(OCPBUGS-59376)
  • 在此次更新之前，Cluster CAPI Operator 状态控制器使用未排序的相关对象列表，从而导致在没有功能更改时进行状态更新。因此，用户可能会因为持续和不必要的状态更新而在日志中看到 Cluster CAPI Operator 对象和日志。在这个版本中，状态控制器逻辑在比较相关对象以进行更改前对其进行排序。因此，只有在 Operator 状态有变化时才会发生状态更新。(OCPBUGS-56805,OCPBUGS-58880)
  • 在此次更新之前，Cloud Controller Manager Operator 的 config-sync-controller 组件不会显示日志。这个问题已在本发行版本中解决。(OCPBUGS-56508)
  • 在此次更新之前，Control Plane Machine Set 配置使用来自计算机器集的可用区。这不是有效的配置。因此，当 control plane 机器位于跨越多个区的计算机器集时，将无法生成 Control Plane Machine Set。在这个版本中，Control Plane Machine Set 从现有 control plane 机器生成可用区配置。因此，Control Plane Machine Set 会生成有效的区配置，它准确反映当前的 control plane 机器。(OCPBUGS-52448)
  • 在此次更新之前，注解 Machine API 机器集的控制器不会在添加 scale-from-zero 注解前检查 Machine API 是否具有权威。因此，控制器会重复添加这些注解，并导致对 MachineSet 对象的持续更改循环。在这个版本中，控制器会在添加 scale-from-zero 注解前检查 authoritativeAPI 字段的值。因此，当 Machine API 具有权威时，控制器只会将这些注解添加到 Machine API 计算机器集中来避免循环行为。(OCPBUGS-57581)
  • 在此次更新之前，Machine API Operator 会尝试在 AWS 以外的平台协调 Machine 资源，其中没有填充 .status.authoritativeAPI 字段。因此，计算机器无限期处于 Provisioning 状态，永远不会正常工作。在这个版本中，Machine API Operator 会使用机器规格中的对应值填充空的 .status.authoritativeAPI 字段。另外，在控制器中添加了一个 guard 来处理此字段可能仍为空的情况。因此，Machine 和 MachineSet 资源会被正确协调，计算机器不再无限期处于 Provisioning 状态。(OCPBUGS-56849)
  • 在此次更新之前，Machine API Provider Azure 使用旧版本的 Azure SDK，它使用一个不支持引用 Capacity Reservation 组的旧 API 版本。因此，在另一个订阅中创建引用 Capacity Reservation 组的 Machine API 机器会导致 Azure API 错误。在这个版本中，Machine API Provider Azure 使用支持此配置的 Azure SDK 版本。因此，在另一个订阅中创建引用 Capacity Reservation 组的 Machine API 机器可以正常工作。(OCPBUGS-55372)
  • 在此次更新之前，支持将 Machine API 资源迁移到 Cluster API 资源的集群上双向同步控制器在将权威 Cluster API 机器模板转换为 Machine API 机器集时无法正确比较机器规格。因此，对 Cluster API 机器模板规格的更改不会同步到 Machine API 机器集。在这个版本中，对比较逻辑的更改解决了这个问题。因此，Cluster API 机器集引用新的 Cluster API 机器模板后，Machine API 机器集会正确同步。(OCPBUGS-56010)
  • 在此次更新之前，支持将 Machine API 资源迁移到 Cluster API 资源的集群上双向同步控制器不会在删除对应的 Machine API 机器集时删除机器模板。因此，不需要的集群 API 机器模板会保留在集群中，并避免 openshift-cluster-api 命名空间。在这个版本中，双向同步控制器可以正确地处理机器模板的删除同步。因此，删除 Machine API 权威机器集会删除对应的 Cluster API 机器模板。(OCPBUGS-57195)
  • 在此次更新之前，支持将 Machine API 资源迁移到 Cluster API 资源的集群上双向同步控制器会持续报告成功迁移。因此，如果在更新相关对象状态时发生错误，则不会重试操作。在这个版本中，控制器会确保在报告成功状态前写入所有相关对象状态。因此，控制器会更好地处理迁移期间的错误。(OCPBUGS-57040)

1.6.4. Cloud Credential Operator
复制链接

  • 在此次更新之前，ccoctl 命令在通过 Microsoft Entra Workload ID 创建 OpenID Connect (OIDC)签发者和受管身份时，不需要使用 baseDomainResourceGroupName 参数。因此，当 ccoctl 试图创建私有集群时会显示一个错误。在这个版本中，baseDomainResourceGroupName 参数已被删除。因此，在 Microsoft Azure 上创建私有集群的过程与预期一致。(OCPBUGS-34993)

1.6.5. Cluster Autoscaler
复制链接

  • 在此次更新之前，集群自动扩展会尝试包含处于删除状态的机器对象。因此，机器的集群自动扩展计数不准确。此问题会导致集群自动扩展添加不需要的额外污点。在这个版本中，自动扩展会准确计算机器。(OCPBUGS-60035)
  • 在此次更新之前，当您使用在集群中启用 Cluster Autoscaler Operator 创建集群自动扩展对象时，openshift-machine-api 有两个 cluster-autoscaler-default pod 有时会同时创建，其中一个 pod 会立即终止。在这个版本中，只创建一个 pod。(OCPBUGS-57041)

1.6.6. Cluster Resource Override Admission Operator
复制链接

1.6.7. Cluster Version Operator
复制链接

1.6.8. config-operator
复制链接

  • 在此次更新之前，集群会错误地切换到 CustomNoUpgrade 状态，且没有正确的 featureGate 配置。因此，会出现空 featureGates 和后续控制器 panics。在这个版本中，CustomNoUpgrade 集群状态的 featureGate 配置与默认值匹配，这可防止空 特性 和后续控制器 panic。(OCPBUGS-57187)

1.6.9. 扩展 (OLM v1)
复制链接

  • 在此次更新之前，如果 OLM v1 中的 preflight 自定义资源定义(CRD)安全检查会在 CRD 的 description 字段中检测到更改时阻止更新。在这个版本中，preflight CRD 安全检查不会阻止更新，当文档字段有变化时。(OCPBUGS-55051)
  • 在此次更新之前，catalogd 和 Operator Controller 组件没有在 OpenShift CLI (oc)中显示正确的版本并提交信息。在这个版本中，会显示正确的提交和版本信息。(OCPBUGS-23055)

1.6.10. ImageStreams
复制链接

1.6.11. 安装程序
复制链接

1.6.12. Machine Config Operator
复制链接

  • 在此次更新之前，外部操作程序可能会取消协调 Machine Config Operator (MCO)排空的节点。因此，MCO 和调度程序会同时调度和取消调度 pod，从而延长排空过程。在这个版本中，如果外部在排空过程中取消协调，MCO 会尝试记录该节点。因此，MCO 和调度程序不再同时调度和删除 pod。(OCPBUGS-61516)
  • 在此次更新之前，在从 OpenShift Container Platform 4.18.21 更新至 OpenShift Container Platform 4.19.6 时，Machine Config Operator (MCO)会因为一个或多个机器集中的多个标签而失败。在这个版本中，MCO 接受 capacity.cluster-autoscaler.kubernetes.io/labels 注解中的多个标签，在升级到 OpenShift Container Platform 4.19.6 过程中不再会失败。(OCPBUGS-60119)
  • 在此次更新之前，因为缺少基础架构状态字段，在 Azure Red Hat OpenShift (ARO)升级到 4.19 时，Machine Config Operator (MCO)证书管理会失败。因此，证书会在没有所需的存储区域网络(SAN) IP 的情况下刷新，从而导致升级 ARO 集群的连接问题。在这个版本中，MCO 在 ARO 中的证书管理过程中添加并保留 SAN IP，防止在升级到 4.19 时立即轮转。(OCPBUGS-59780)
  • 在此次更新之前，当从 4.15 之前的 OpenShift Container Platform 版本进行更新时，MachineNode 自定义资源定义(CRD) feature 被安装为技术预览(TP)会导致更新失败。此功能在 OpenShift Container Platform 4.16 中完全引入。在这个版本中，更新不再部署技术预览 CRD，确保可以成功升级。(OCPBUGS-59723)
  • 在此次更新之前，Machine Config Operator (MCO)会在不检查当前引导镜像来自 Google Cloud 或 Amazon Web Services (AWS) Marketplace 的情况下更新节点引导镜像。因此，MCO 将使用标准 OpenShift Container Platform 镜像覆盖 marketplace 引导镜像。在这个版本中，对于 AWS 镜像，MCO 有一个查找表，其中包含所有标准 OpenShift Container Platform 安装程序 Advanced Metering Infrastructures (AMI)，它在更新引导镜像前引用它。对于 Google Cloud 镜像，MCO 会在更新引导镜像前检查 URL 标头。因此，MCO 不再更新具有 marketplace 引导镜像的机器集。(OCPBUGS-57426)
  • 在此次更新之前，在镜像拉取更新的基础操作系统(OS)镜像前，OpenShift Container Platform 会更新对 Core DNS 模板的更改会重启 coredns pod。因此，操作系统更新管理器因为网络错误导致镜像拉取失败，从而导致更新停止。在这个版本中，在 Machine Config Operator (MCO)中添加了重试更新操作来临时解决这个问题。OCPBUGS-43406

1.6.13. 管理控制台
复制链接

1.6.14. 监控
复制链接

1.6.15. 网络
复制链接

  • 在此次更新之前，因为 baremetal 和多个网络接口控制器(NIC)环境中存在 NetworkManager-wait-online 依赖项问题，所以 OpenShift Container Platform 部署中会出现 NMState 服务失败。因此，不正确的网络配置会导致部署失败。在这个版本中，baremetal 部署的 NetworkManager-wait-online 依赖项被更新，这减少了部署失败并确保 NMState 服务稳定性。(OCPBUGS-61824)
  • 在此版本之前，当 cloud-event-proxy 容器或 pod 重启时，事件数据会立即可用。这会导致 getCurrenState 函数错误地返回 时钟类 0。在这个版本中，getCurrentState 功能不再返回不正确的 clockclass，而是返回 HTTP 400 Bad Request 或 404 Not Found Error。(OCPBUGS-59969)
  • 在此次更新之前，HorizontalPodAutoscaler 对象会临时将 istiod-openshift-gateway 部署扩展到两个副本。这会导致持续集成(CI)失败，因为测试预期一个副本。在这个版本中，HorizontalPodAutoscaler 对象扩展会验证 istiod-openshift-gateway 资源至少有一个副本来继续部署。(OCPBUGS-59894)
  • 在以前的版本中，DNS Operator 在其配置或其操作对象配置中不会将 readOnlyRootFilesystem 参数设置为 true。因此，DNS Operator 及其操作对象对 root 文件系统 有写权限。在这个版本中，DNS Operator 将 readOnlyRootFilesystem 参数设置为 true，以便 DNS Operator 及其操作对象现在对 root 文件系统 具有只读访问权限。在这个版本中，为集群提供增强的安全性。(OCPBUGS-59781)
  • 在此次更新之前，当启用 Gateway API 功能时，它会安装一个带有一个 pod 副本和关联的 PodDisruptionBudget 设置的 Istio control plane。PodDisruptionBudget 设置阻止唯一的 pod 副本被驱除，阻止集群升级。在这个版本中，Ingress Operator 会阻止 Istio control plane 配置 PodDisruptionBudget 设置。pod 副本不再阻止集群升级。(OCPBUGS-58358)
  • 在此次更新之前，当启用abouts -shim 网络附加时，Cluster Network Operator (CNO)会在集群升级过程中停止。出现这个问题的原因是 openshift-multus 命名空间中缺少 release.openshift.io/version 注解。在这个版本中，缺少的注解添加到集群中，因此当启用abouts -shim 附加位置时，CNO 不再在集群升级过程中停止。集群升级现在可以继续如预期。(OCPBUGS-57643)
  • 在此次更新之前，即使这些资源的 CRD 不存在，Ingress Operator 也会向 Cluster Operator 的 status.relatedObjects 参数添加资源、最明显的网关资源。另外，Ingress Operator 为 istios 和 GatewayClass'resources 指定一个命名空间，它们是集群范围的资源。由于这些配置，相关的Objects 参数包含误导信息。在这个版本中，对 Ingress Operator 的状态控制器的更新可确保控制器检查这些资源是否已存在，并在将任何这些资源添加到 relatedObjects 参数前检查相关的功能门。控制器不再为 GatewayClass 和 istio 资源指定命名空间。在这个版本中，确保 relatedObjects 参数包含 GatewayClass 和 istio 资源的准确信息。(OCPBUGS-57433)
  • 在此次更新之前，因为过时的网络地址转换(NAT)处理，集群升级会导致出口 IP 地址分配不一致。只有在 OVN-Kubernetes 控制器停机时，才会出现这个问题。因此，会发生重复的逻辑路由器策略和出口 IP 地址使用情况，这会导致流量流和中断不一致。在这个版本中，出口 IP 地址分配清理确保在 OpenShift Container Platform 4.20 集群中一致且可靠的出口 IP 地址分配。(OCPBUGS-57179)
  • 在以前的版本中，当内部安装程序置备的基础架构(IPI)部署使用 Cilium 容器网络接口(CNI)时，将流量重定向到负载均衡器的防火墙规则无效。在这个版本中，该规则可用于 Cilium CNI 和 OVNKubernetes。(OCPBUGS-57065)
  • 在此次更新之前，因为缺少权限，一个 keepalived 健康检查脚本会失败。这可能会导致在使用共享入口服务时导致入口 VIP 错误。在这个版本中，必要的权限被添加到容器中，因此健康检查现在可以正常工作。(OCPBUGS-55681)
  • 在此次更新之前，在 EgressFirewall CRD 的对应 DNS 规则的 address_set 列表中存在过时的 IP 地址。这些过时的地址而不是被删除，而是继续添加到 address_set 中，从而导致内存泄漏问题。在这个版本中，当达到 IP 地址的生存时间(TTL)过期时间时，IP 地址会在达到 5 秒宽限期后从 address_set 列表中删除。(OCPBUGS-38735)
  • 在此次更新之前，某些流量模式在 OpenShift Container Platform 节点和 pod 之间运行大型数据包的流量模式触发了 OpenShift Container Platform 主机，以将互联网控制消息协议(ICMP)发送到另一个 OpenShift Container Platform 主机。这种情形降低了集群中可行的最大传输单元(MTU)。因此，执行 ip route show cache 命令会显示一个缓存的路由，其 MTU 低于物理链接。数据包被丢弃，OpenShift Container Platform 组件会降级，因为主机没有发送带有大型数据包的 pod 到 pod 流量。在这个版本中，nftables 规则会阻止 OpenShift Container Platform 节点降低其 MTU 以响应这些流量模式。(OCPBUGS-37733)
  • 在此次更新之前，您无法覆盖在安装程序置备的基础架构上运行的部署的节点 IP 地址选择过程。这限制了在机器网络上不使用 VIP 地址的用户管理的负载均衡器，这会导致具有多个 IP 地址的环境出现问题。在这个版本中，在安装程序置备的基础架构中运行的部署现在支持 ' nodeip-configuration systemd 服务的 NODEIP_HINT ' 参数。此支持更新可确保使用正确的节点 IP 地址，即使 VIP 地址不在同一子网中。(OCPBUGS-36859)

1.6.16. 节点
复制链接

  • 在此次更新之前，在某些配置中，kubelet 的 podresources API 可能会报告分配给活跃和终止的 pod 的内存，而不是报告分配给活跃的 pod 的内存。因此，这种不准确报告可能会受到 NUMA 感知调度程序影响的工作负载放置。在这个版本中，kubelet 的 podresources 不再报告已终止 pod 的资源，这会导致 NUMA 感知调度程序准确的工作负载放置。(OCPBUGS-56785)
  • 在此版本之前，Container Runtime Interface-OpenShift (CRI-O)系统在后端存储停机时无法识别有状态集 pod 的终止状态，从而导致 pod 保持 Terminating 状态，因为无法检测容器进程不再存在。这会导致资源效率低下和潜在的服务中断。在这个版本中，CRI-O 可以正确地识别终止的 pod，改进了 StatefulSet 终止流。(OCPBUGS-55485)
  • 在此次更新之前，如果 Guaranteed QoS pod 中的 CPU 固定容器定义了 cgroups 配额，则内核 CPU 时间核算中的循环和小延迟可能会导致 CPU 固定进程节流，即使将配额设置为允许每个分配的 CPU 的 100% 消耗。在这个版本中，当 cpu-manager-policy=static 和静态 CPU 分配的资格满足时，容器具有带有整数 CPU 请求的 Guaranteed QOS，则禁用 CFS 配额。(OCPBUGS-14051)

1.6.17. Node Tuning Operator (NTO)
复制链接

1.6.18. Observability（可观察性）
复制链接

1.6.19. oc-mirror
复制链接

  • 在此次更新之前，oc-mirror 中镜像 Helm 镜像不正确的计数会导致无法记录所有镜像的 Helm 镜像。因此，会显示不正确的 Helm 镜像计数。在这个版本中，oc-mirror 中不正确的 Helm 镜像计数已被修复，并正确镜像所有 Helm 镜像。因此，oc-mirror 中 Helm chart 的镜像计数是准确的。(OCPBUGS-59949)
  • 在此次更新之前，--parallel-images 标志接受无效的输入，其最小值小于 1 个或大于镜像总数。因此，并行镜像复制会失败，并带有 0 或 100 -parallel-images 标记，并限制可镜像的镜像数量。在这个版本中，invalid --parallel-images 标志的问题已被修复，1 和镜像总数之间的值会被接受。因此，用户可以为有效范围中的任何值设置 --parallel-images 标志。(OCPBUGS-58467)
  • 在此次更新之前，高 oc-mirror v2 并发默认值会导致 registry 过载，并导致请求拒绝。因此，高并发默认值会导致 registry 拒绝，容器镜像推送失败。在这个版本中，oc-mirror v2 的并发默认值会减少，以避免 registry 拒绝，并改进了镜像推送成功率。(OCPBUGS-57370)
  • 在此次更新之前，因为 ImageSetConfig 参数中镜像摘要和阻止的镜像标签之间不匹配而发生错误。这个程序错误会导致用户在镜像集中查看来自不同云供应商的镜像，虽然它们被阻断。在这个版本中，ImageSetConfig 参数被更新为支持 blockedImages 列表中的正则表达式，以获得更灵活的镜像排除，并允许排除与 blockedImages 列表中正则表达式模式匹配的镜像。(OCPBUGS-56117)
  • 在此次更新之前，对于安全技术实施指南(STIG)合规性，系统 umask 值设置为 0077，并导致 disk2mirror 参数停止上传 OpenShift Container Platform 发行镜像。因此，用户无法上传 OpenShift Container Platform 发行镜像，因为 umask 命令的限制。在这个版本中，oc-mirror 处理有问题的 umask 值并警告用户。当系统 umask 设为 0077 时，OpenShift Container Platform 发行镜像会被正确上传。(OCPBUGS-55374)
  • 在此次更新之前，互联网系统 Consortium (ISC)指导行中错误地包含无效的 Helm Chart，并在运行 m2d'workflow 时出现错误消息。在这个版本中，'m2d 工作流中无效 Helm chart 的错误消息被更新，并改进了错误消息清晰。(OCPBUGS-54473)
  • 在此次更新之前，会因为重复的频道选择而发生多个发行集合。因此，会收集重复的发行镜像，并导致不必要的存储使用。在这个版本中，重复的发行版本集合已被修复，每个发行版本都会被收集一次。因此，重复的发行集合会被取消，并确保通过更快访问来确保有效的存储。(OCPBUGS-52562)
  • 在此次更新之前，oc-mirror 不会检查特定 OpenShift Container Platform 版本的可用性，并导致它继续不存在的版本。因此，用户假设镜像成功，因为没有收到错误消息。在这个版本中，除了问题的原因外，oc-mirror 会在指定不存在的 OpenShift Container Platform 版本时返回错误。因此，用户了解不可用的版本，并可以采取适当的操作。(OCPBUGS-51157)

1.6.20. OpenShift CLI (oc)
复制链接

1.6.21. Operator Lifecycle Manager (OLM) Classic
复制链接

  • 在此次更新之前，捆绑包解包作业不会在创建时继承目录 Operator 的 control plane 容错能力。因此，捆绑包解包作业只在 worker 节点上运行。如果因为污点而没有 worker 节点可用，集群管理员将无法在集群中安装或更新 Operator。在这个版本中，OLM (Classic)采用 control plane 容限来捆绑解包作业，作业可以作为 control plane 的一部分运行。(OCPBUGS-58349)
  • 在此次更新之前，当 Operator 组命名空间中提供多个 API 时，OLM (Classic)对为 Operator 组创建的集群角色进行不必要的更新调用。因此，这些不必要的调用会导致 ectd 和 API 服务器造成 churn。在这个版本中，OLM (Classic)不会对 Operator 组中的集群角色对象进行不必要的更新调用。(OCPBUGS-57222)
  • 在此次更新之前，如果 olm-operator pod 在因为错误标记的资源而在集群更新过程中崩溃，则通知消息将使用 info 标签。在这个版本中，因为错误标签的资源造成崩溃通知信息会使用 错误 标签。(OCPBUGS-53161)
  • 在此次更新之前，目录 Operator 每 5 分钟调度目录快照。在具有多个命名空间和订阅的集群中，快照会在目录源之间失败并级联。因此，CPU 负载高峰会有效地阻止安装和更新 Operator。在这个版本中，目录快照会每 30 分钟调度一次，以便有足够的时间来解决快照。(OCPBUGS-43966)

1.6.22. Performance Addon Operator
复制链接

1.6.23. Samples Operator
复制链接

1.6.24. Storage
复制链接

1.6.25. Red Hat Enterprise Linux CoreOS (RHCOS)
复制链接

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat