搜索
支持控制台（Console）开发人员开始试用联系人

1.7. 程序错误修复

download PDF

assisted-installer

  • 在以前的版本中，assisted-service 容器不会等待 postgres 启动并准备好来接受连接。assisted-service 容器试图建立数据库连接并失败，assisted-service 容器失败并重启。这个问题已被解决，assisted-service 容器会尝试连接到数据库最多 10 秒。如果 postgres 启动并在 10 秒内准备好接受连接，则 assisted-service 容器将会进行连接，而不会进入错误状态。如果 assisted-service 容器无法在 10 秒内连接到 postgres，它会进入错误状态、重启并重试。（BZ#1941859）

裸机硬件置备

  • 在以前的版本中,Ironic 无法下载安装的镜像，因为 Ironic 默认使用 HTTPS，且没有可用的证书捆绑包。这个问题已通过将镜像下载设置为 Insecure 以解决，从而在没有证书的情况下请求传输。（BZ#1953795）
  • 在以前的版本中，当使用双栈网络时，worker 节点主机名有时与 Ironic 在部署前检查的主机名不匹配。这会导致节点需要手动批准。该问题已解决。（BZ#1955114）
  • 在以前的版本中，在 UEFI 模式中，ironic-python-agent 在下载 RHCOS 镜像后会创建一个 UEFI 引导装载程序条目。当使用基于 RHEL 8.4 的 RHCOS 镜像时，镜像可能无法使用此条目引导。如果在引导镜像时使用 Ironic 安装的条目，引导可能会失败，并输出一个 BIOS 错误界面。这个问题由 ironic-python-agent 根据镜像中的 CSV 文件配置引导条目来解决，而不使用固定的引导条目。镜像可以正常引导，且无错误。(BZ#1972213)
  • 在以前的版本中，节点有时会在启动时选择不正确的 IP 版本（IPv6 而不是 IPv4，反之亦然）。该节点无法启动，因为它没有收到 IP 地址。这个问题已解决，Cluster Bare Metal Operator 将 IP 选项传递给下载器（ip=dhcp 或 ip=dhcp6），它在启动时可以正确设置，节点会如预期启动。（BZ#1946079）
  • 在以前的版本中，Ironic 中的镜像缓存机制被禁用，以启用与托管 virtualmedial iso 的 HTTP 服务器的直接连接，以防止本地存储问题。非标准兼容 HTTP 客户端和 redfish 实现会导致 BMC 连接失败。这个问题已通过恢复到缓存 virtualmedia iso 并从 Ironic 编排器节点提供的默认 Ironic 行为来解决。由非标准兼容 HTTP 客户端和 redfish 的实现造成的问题已被解决。(BZ#1962905)
  • 在以前的版本中，机器实例的 state 注解没有被设置。因此，STATE 列为空。在这个版本中，机器实例的 state 注解被设置，STATE 列中的信息会自动填充。(BZ#1857008)
  • 因为较新的 ipmitool 软件包默认使用加密套件 17，所以不支持密码套件 17 的旧硬件在部署过程中会失败。当硬件不支持密码套件 17 时，Ironic 现在使用密码套件 3，以便使用 ipmitool 的旧硬件上部署可以成功。(BZ#1897415)
  • 在以前的版本中，在某些情况下，在填充镜像缓存前发生采用，这会导致永久采用失败，且不会尝试重试。这会导致 control plane 裸机主机报告采用失败。在这个版本中，外部置备的主机会在采用失败后自动重试，直到正确采用 control plane 主机为止。(BZ#1905577)
  • 在以前的版本中，自定义资源（CR）需要 Baseboard Management Controller（BMC）详情。但是，在协助的安装程序中不会提供此信息。此更新允许 CR 在 Operator 没有创建节点时绕过 BMC 详情。（BZ#1913112）
  • 在将一个镜像置备到节点时，qemu-image 被限制为 1G RAM，这可能会导致 qemu-img 崩溃。在这个版本中，限制被增加到 2G，以便 qemu-img 现在能够可靠完成置备。（BZ#1917482）
  • 由于 redfish/v1/SessionService URL 需要身份验证，因此 Ironic 会在访问站点时生成身份验证错误。因为 Ironic 报告此错误消息时没有功能问题，因此已被删除。（BZ#1924816）
  • 对于某些驱动器，分区（如 /dev/sda1 ）没有只读文件。然而，基本设备（例如 /dev/sda ）有此文件。因此，Ironic 无法确定分区是只读的，这会导致元数据清理在该驱动器上失败。在这个版本中，确保了分区被检测到为只读分区，并包含对基本设备的额外检查。因此，不会对只读分区执行元数据清理，元数据清理不再失败。（BZ#1935419）
  • 当使用代理配置代理部署 Baremetal IPI 时，内部 machine-os 镜像下载会通过代理进行。这会破坏镜像并阻止下载。在这个版本中，内部镜像流量被修复为 no_proxy，因此镜像下载不再使用代理。(BZ#1962592)
  • 在以前的版本中，如果 Ironic 和 RAM 磁盘之间的大型数据包传输导致连接失败，裸机部署会失败。在这个版本中，Ironic 会查询 RAM 磁盘以获取解决连接错误的信息，从而使部署可以成功。（BZ#1957976）

Builds

  • 在以前的版本中，在修复 CVE-2021-3344 后，构建不会在 OpenShift Container Platform 节点上自动挂载授权密钥。因此，当授权证书存储在主机或节点上时，这个修复会阻止授权构建无缝运行。导致主机或节点上保存的权利证书失败的问题已在 BZ#1945692（4.7.z）和 BZ#1946363（4.6.z）中修复。但是，这些修复为在 Red Hat Enterprise Linux CoreOS（RHCOS）worker 节点上运行的构建引入了一个 benign 警告信息。当前发行版本解决了这个问题，它允许构建只在 RHEL worker 节点上自动挂载权利，并避免在 RHCOS worker 节点上尝试挂载。现在，在 RHCOS 节点上运行构建时，不会出现有关授权挂载的任何 benign 警告。（BZ#1951084）

  • 有些用户从 Docker Hub 拉取镜像可能会遇到以下错误： 

    container image registry lookup failed...​toomanyrequests: You have reached your pull rate limit

    发生此错误的原因是，它们用来调用 oc new-app 的 docker.io 登录没有足够的 docker.io 支持。生成的应用可能会受到镜像节流的影响，这可能会导致失败。当前发行版本更新了 oc new-app，提醒用户镜像 registry 和存储库规格的默认工作原理，因此用户可以尽可能使用非默认镜像引用以避免类似的错误。（BZ#1928850）

  • 在以前的版本中，构建不会执行错误检查来查看镜像推送是否失败。因此，构建总是记录 Successfully pushed 信息。现在，构建会检查是否有错误，只有在镜像推送成功后才会记录 Successfully pushed 信息。（BZ#1947164）
  • 在以前的版本中，文档和 oc explain 的帮助文本不会提示 BuildConfig 对象中的 buildArgs 字段不支持其底层 Kubernetes EnvVar 类型的 valueFrom 字段。因此，用户会相信它已被支持并尝试使用它。当前发行版本更新了文档和帮助文本，更明显地说明 BuildConfig 对象的 buildArgs 字段不支持 valueFrom 字段。（BZ#1956826）
  • 当构建与镜像 registry 交互（如拉取基础镜像）时，间歇性通信问题可能会导致构建失败。当前发行版本会增加对这些交互的重试次数。现在，当 OpenShift Container Platform 构建遇到与镜像 registry 间通信时，它们可以更加灵活。(BZ#1937535)

Cloud Compute

  • 在以前的版本中，Cluster Image Registry Operator 将 user_domain_name 视为不可变字段，且不会在安装后修改。这会导致一个接受对 user_domain_name 并生成的凭证的更改。在这个版本中，user_domain_name 标记为可变，且不会将其存储在镜像 registry 配置中。这允许在安装后修改 user_domain_name 以及所有其他 auth 参数。（BZ#1937464）
  • 在以前的版本中，代理更新会在持续集成（CI）运行时导致完整的集群配置更新，包括 API 服务器重启。因此，Machine API Operator 中的一些集群会因为意外的 API 服务器中断而超时。在这个版本中，代理测试分离并添加 postconditions，以便 Machine API Operator 中的集群在 CI 运行过程中再次变为稳定。（BZ#1913341）
  • 在以前的版本中，删除处于 Insufficient disk space on datastore 状态的机器所需的时间比预期的要长，因为不同 vCenter 任务类型之间没有区别。在这个版本中，机器控制器删除过程会检查 vCenter 任务类型，不再阻止删除机器控制器。因此，机器控制器会被快速删除。（BZ#1918101）
  • 在以前的版本中，即使实例类型缺失，从零注解进行扩展也会重新排队。因此，MachineSet 控制器日志中会有一个恒定的 requeue 和 error space 信息。在这个版本中，如果实例类型没有自动解析，用户可以手动设置注解。因此，如果用户手动提供注解，则可以从零对未知实例类型进行扩展。（BZ#1918910）
  • 在以前的版本中，Machine API 终止处理器没有正确关闭 HTTP 响应。因此，goroutines 在 net.http 读写循环中会被泄漏，这会导致较高的内存用量。此更新确保了始终正确关闭 HTTP 响应。因此，内存用量现在是稳定的。（BZ#1934021）
  • 在以前的版本中，在 MachineSet 控制器中创建的多个客户端集会导致启动时间较慢，这会导致一些大型集群中 pod 无法就绪度检查。因此，MachineSet 控制器会停留在无限循环中。在这个版本中修复了 MachineSet 控制器，使其使用单个客户端。因此，MachineSet 控制器的行为如预期。(BZ#1934216)
  • 在以前的版本中，当升级由 Machine Config Daemon 在第一次引导时执行时，实例引导需要更长的时间。因此，worker 节点处于重启循环中，机器健康检查（MCH）删除了 worker 节点，因为它们没有正确启动。在这个版本中，MHC 不再删除没有正确启动的节点。相反，MHC 仅在明确请求时删除节点。（BZ#1939054）
  • 在以前的版本中，因为未知原因，证书签名请求（CSR）批准会被延迟。因此，在安装过程中出现的新机器不会被迅速批准，从而延长集群安装。为了减少早期安装阶段中偶尔 API 服务器不可用的问题，这个更新会将缓存重新同步周期从 10 小时改为 10 分钟。因此，现在可以更快地批准control plane 机器，集群安装不再会需要非常长的时间。(BZ#1940972)
  • 在以前的版本中，默认的 Google Cloud Platform（GCP）镜像过期，并引用 OpenShift Container Platform 4.6 版本中的不支持较新版本的 Ignition 版本。因此，使用默认 GCP 镜像的集群中的新机器无法引导 OpenShift Container Platform 4.7 及之后的版本。在这个版本中，GCP 镜像被更新以与发行版本匹配。现在，新机器可以使用默认的 GCP 镜像引导。（BZ#1954597）
  • 在以前的版本中，由于对虚拟机的 ProvisioningState 值进行严格检查，虚拟机有时会在存在检查过程中失败。在这个版本中，检查会更加宽松，在存在检查过程中只有删除的机器会进入 Failed 阶段。(BZ#1957349)
  • 在以前的版本中，如果您在 AWS 集群中使用 oc delete machine 删除了 control plane 机器，则机器不会从负载均衡器中删除。因此，负载均衡器继续为删除的 control plane 机器提供请求。在这个版本中，当您删除 control plane 机器时，负载均衡器不再为机器提供请求。(BZ#1880757)
  • 在以前的版本中，当删除一个无法访问的机器时，为持久性卷创建并附加到节点的 vSphere Virtual Machine Disk（VMDK）会被错误删除。因此，VMDK 中的数据无法恢复。在这个版本中，如果 kubelet 无法访问，vSphere 云供应商会检查这些磁盘并从节点分离。因此，您可以在不丢失 VMDK 的情况下删除无法访问的机器。(BZ#1883993)
  • 在以前的版本中，因为生成的 AWS 实例类型列表已过时，所以在使用带有零副本的 Cluster Autoscaler Operator 和机器集时，一些较新的 Amazon Web Services（AWS）实例类型无法从零扩展。AWS 实例类型列表现已更新，以包含较新的实例类型。在这个版本中，Cluster Autoscaler Operator 可以使用更多实例类型从零副本进行扩展。(BZ#1896321)
  • 在以前的版本中，因为缺少上游驱除 API 功能，pod 中断预算不会在无法访问的节点上排空 pod。因此，在删除后，无法访问节点上的机器可能需要太多的时间才能被删除。现在，当删除无法访问节点上的机器时，宽限期超时将更改为 1 秒。在这个版本中，Machine API 可以成功排空和删除无法访问的节点。(BZ#1905709)

Cloud Credential Operator

  • 在以前的版本中，一个重复的 unsupported platform type: BareMetal 警告信息会出现在裸机平台上。在这个版本中，裸机平台不再被视为未知平台。因此，可以减少误导的日志记录信息。(BZ#1864116)
  • 在以前的版本中，一个周期性错误消息存储在 Cloud Credential Operator 的 credentialsRequest 自定义资源（CR）中，导致 CPU 使用量过大，并登录到一些错误场景，如 Amazon Web Services（AWS）速率限制。在这个版本中，删除了来自云供应商的请求 ID，以便错误消息存储在用户更容易地找到它们的条件中，并消除 credentialsRequest CR 中的重复错误信息。（BZ#1910396）
  • 在以前的版本中，如果 CCO 的部署不健康，Cloud Credential Operator（CCO）和 Cluster Version Operator（CVO）都会报告。这会导致在出现问题时出现双重报告。在这个版本中，在部署不健康时，CCO 不再进行报告。（BZ#1957424）

Cluster Version Operator

  • 在以前的版本中，Cluster Version Operator 在设置 cluster_operator_up 指标时会评估 Available 和 Degraded 参数，这会导致使用 Available=True 或 Degraded=True 的 Operator 显示 ClusterOperatorDown 警报。即使 Available=True 与 "has not available" 的警报描述不匹配。在这个版本中，Cluster Version Operator 在设置 cluster_operator_up 指标时会忽略 Degraded 参数。(BZ#1834551)
  • 在以前的版本中，当在集群中安装 Prometheus 时，重要的平台拓扑指标不可用，如果使用调用器生成的安装程序指标设置为""，则会出现 CI 错误。现在解决了在提供造成错误的指标前通知程序没有同步的竞争条件。(BZ#1871303)
  • 在以前的版本中，具有同一键的多个容限（如 Cluster Version Operator 自身的部署）的清单仅接受最后一个条目读取和覆盖之前的条目。这会导致 in-cluster tolerations 与清单列出的容限分离。在这个版本中，Cluster Version Operator 在完全相等时会考虑容限匹配。这允许 Cluster Version Operator 保留清单中针对 in-cluster 资源的所有容限。（BZ#1941901）
  • 在以前的版本中，Cluster Version Operator 对于没有设置这些属性的清单不会协调 env 和 envFrom。这意味着 Cluster Version Operator 没有正确管理容器环境。此更新改进了 Cluster Version Operator，以便在清单中未设置时清除 env 和 envFrom。这允许集群自动恢复对这些属性无效的 cluster-admin 更改。（BZ#1951339）
  • 在以前的版本中，具有同一键的多个容限（如 cluster-version-operator 的部署对象）的清单仅接受最后一个条目读取和覆盖之前的条目。这会导致集群内容限与清单列出的容限分离。在这个版本中，Cluster Version Operator 认为容限在相等时是匹配的。这允许 Cluster Version Operator 保留清单中针对 in-cluster 资源的所有容限。（BZ#1941901）
  • 在以前的版本中，当 ClusterOperator 资源降级了 10 分钟时，Cluster Version Operator 会报告 ClusterOperatorDegraded 警报。这个警报有时会在安装过程中发生，因为仍然在创建资源。这个版本将 10 分钟期限改为 30 分钟，为安装过程提供了充足的时间，从而可以避免不必要的 ClusterOperatorDegraded 警报。(BZ#1957991)

Compliance Operator

  • 在以前的版本中，当用户运行合规检查时，会给出 NON-COMPLIANT 结果，但没有指示用户执行操作所需的补救步骤。此发行版本提供了一个 instructions ，用户可以通过它来查看验证规则所需的步骤。这允许用户和审核员验证 Operator 正在检查正确的值。（BZ#1919367）

控制台 Kubevirt 插件

  • 在以前的版本中，在帮助用户向虚拟化模板添加引导源的 Web 控制台表单中，说明的文本仅针对 Fedora 提供信息，不论模板所使用的操作系统是什么。在这个版本中，添加了一个修复程序，它提供了特定于模板的操作系统的示例，以便用户获得相关指导。(BZ#1908169)
  • 在以前的版本中，在帮助用户创建虚拟机模板的 web 控制台向导中，因为给出的信息不清晰，使用户无法知道一个操作是针对于模板还是针对于一个虚拟机。在这个版本中，给出的信息更清晰，用户可以获得所需信息。（BZ#1922063）
  • 在以前的版本中，web 控制台会有一个模糊的错误消息。这个信息会给试图将网络接口添加到从模板创建的虚拟机的用户造成不必要的混淆。在这个版本中，错误消息中添加了更详细的内容，因此用户可以更轻松地对错误进行故障排除。（BZ#1924788）
  • 在以前的版本中，当您尝试通过 web 控制台从 RHEL 6 模板创建虚拟机时，会出现一个弹出窗口提供有关如何定义支持级别的信息，即使实际上并不支持 RHEL 6。在这个版本中，更改了这个窗口中的信息以明确告知用于 RHEL 6 不被支持。（BZ#1926776）
  • 在以前的版本中，web 控制台中的一个下拉列表被按钮元素遮盖，用户无法在创建虚拟机时选择特定的操作系统。在这个版本中，对按钮元素的 z-index 值进行了调整，从而解决了以前的问题，用户可以选择任何可用的操作系统。（BZ#1930015）
  • 在以前的版本中，如果您在没有定义的存储类的集群上使用了 web 控制台的新虚拟机向导，web 控制台会停留在无限循环中并崩溃。在这个版本中，如果没有定义存储类，会删除存储类下拉列表。因此，web 控制台不会崩溃。（BZ#1930064）
  • 在以前的版本中，按钮元素中的文本没有清楚地描述按钮的实际功能（从收藏的列表中删除虚拟机模板）。在这个版本中更新了相关的信息以阐明该按钮的作用。（BZ#1937941）
  • 在以前的版本中，对于具有 RerunOnFailure 运行策略的虚拟机，停止虚拟机会导致几个 UI 元素变得无响应，从而导致用户无法读取状态信息或重启虚拟机。在这个版本中解决了不响应的元素问题，用户可以使用这些功能。（BZ#1951209）
  • 在以前的版本中，对于配置为具有独立 /var 分区的集群，查询文件系统只返回挂载在根目录中的磁盘大小，它不包括 /var 分区的大小。在这个版本中，查询的运行方式进行了改变，用户现在可以决定集群中文件系统的总大小。（BZ#1960612）

控制台存储插件

  • 在以前的版本中，当正确的存储类不可用时，OpenShift Container Storage Operator 会显示一个错误消息。在这个版本中删除了这个错误消息，并禁用 Next 按钮，直到正确的存储类可用为止。（BZ#1924641）
  • 在以前的版本中，当用户在创建内部附加存储集群时点击浏览器的 back 按钮时，安装向导会重新执行整个过程。在这个版本中解决了这个问题。（BZ#1928008）
  • 现在，当您将一个节点添加到本地卷发现时，可以看到一个存在的节点的列表，这减少了不必要的导航。(BZ#1947311)
  • 在以前的版本中，Create Storage Cluster 向导可让您启用一个具有未定义值的仲裁区域。此更新中的修复过滤掉了未定义的值，因此只能使用定义的值来创建仲裁区域。（BZ#1926798）
  • 在以前的版本中，因为产品标题拼写以及使用注册商标的方式不一致，导致在在 web 控制台中错误地显示快速启动卡。在这个版本中，产品名称被正确拼写，注册商标的符号会正确地出现在第一个卡中。（BZ#1931760）

DNS

  • 在以前的版本中，BZ#1936587 将全局 CoreDNS 缓存最大 TTL 设置为 900 秒。因此，从上游解析器接收的 NXDOMAIN 记录被缓存了 900 秒。在这个版本中，负 DNS 响应记录被显式缓存最多 30 秒。因此，解析 NXDOMAIN 不再被缓存 900 秒。（BZ#1943578）
  • BZ#1953097 修复启用了 CoreDNS bufsize 插件，大小为 1232 字节。有些原始 DNS 解析器无法通过大于 512 字节的 UDP 接收 DNS 响应消息。因此，一些 DNS 解析器（如 Go 的内部 DNS 库）无法从 DNS Operator 接收详细的 DNS 响应。在这个版本中，所有服务器的 CoreDNS bufsize 设置为 512 字节。现在，UDP DNS 信息会被正确接收。(BZ#1966116)
  • 在以前的版本中，集群上游解析器返回的 DNS 响应通过 UDP 超过 512 字节。因此，coreDNS 返回的 SERVFAIL 或其他错误消息，并强制客户端通过 TCP 重试。这个版本启用了 coreDNS bufisze 插件，UDP 缓冲区大小为 1232 字节。（BZ#1949361）

etcd

  • 在以前的版本中，etcd Operator 存在一个传输泄漏问题，这会导致内存用量随着时间增大。解决了内存泄漏的问题。（BZ#1925586）
  • 在以前的版本中，etcdInsufficientMembers 警报会错误地触发。在这个版本中，警报已被更新，除了实例标签外还包含 pod 标签，因此仅在 quorum 丢失时警报才会触发。（BZ#1929944）
  • 在以前的版本中，因为引进了 SO_REUSEADDR 套接字选项，就绪度探测没有报告正确的就绪度，这会导致 即使在 etcd-quorum-guard 失败的情况下，etcd pod 也显示为就绪状态。现在，就绪度探测检查已被更新来考虑这些选项，etcd 就绪度探测现在可以正确地反映操作对象的就绪情况。（BZ#1946607）

  • 在以前的版本中，spec.loglevel 字段没有在 etcd 操作对象上设置 log-level 标志，因此用户无法更改 etcd 日志级别。用户现在可以设置日志级别，如下所示：

    • Debug、Trace 和 TraceAll 日志级别映射到 etcd 的debug 日志级别
    • Default 或 Normal 日志级别映射到 etcd 的 info 日志级别

    如需更多信息，请参阅 BZ#1948553。

  • 在以前的版本中，在 etcd 过程后，下一个过程在相关端口被释放后才会启动。在此过程中增加了 SO_REUSEADDR，可以立即重复利用这些端口。如需更多信息，请参阅 BZ#1927942。
  • 在以前的版本中，如果 network.Status.ServiceNetwork 字段未填充，etcd-endpoint 的 ConfigMap 会留空。因此，etcd Operator 无法扩展。OpenShift Container Platform 4.8 中的一项新功能允许 etcd Operator 在 network.Status.ServiceNetwork 字段未填充时扩展。（BZ#1902247）

镜像 Registry

  • 在以前的版本中，镜像修剪器会在删除镜像失败时停止。因此,当两个镜像修剪器同时删除镜像时，其中一个镜像失败并显示 not found 错误。在这个版本中，not found 错误会被忽略，这将使镜像修剪器可以处理并发删除。(BZ#1890828)
  • 在以前的版本中，在 Image Registry Operator 状态评估过程中缺少路由状态意味着 Image Registry Operator 没有降级，即使路由处于降级（degraded）状态。在这个版本中，Image Registry Operator 会获取所有配置的路由，并在评估其自身状态时评估其状态。在这个版本中，如果有任何路由处于降级状态，Image Registry Operator 会将自身报告为 degraded，并显示错误消息。（BZ#1902076）
  • 在以前的版本中，自动创建的 Docker 配置 secret 不包括集成的内部 registry 路由的凭证。因为没有凭证用于通过任何路由访问 registry，因此尝试访问 registry 的 pod 会失败，因为缺少身份验证。在这个版本中，默认 Docker 凭证 secret 中包含所有配置的 registry 路由。现在，pod 可以通过其任何路由访问集成的 registry，因为凭证现在包含每个路由的条目。（BZ#1911470）
  • 在以前的版本中，镜像 registry 忽略了集群范围的 ImageContentSourcePolicy（ICSP）规则。在 pull-through 中，镜像镜像被忽略，这会导致断开连接的集群中拉取失败。在这个版本中，如果目标存储库有 ICSP 规则，registry 会从镜像（mirror）拉取。因此，从配置的镜像拉取镜像不会失败。(BZ#1918376)
  • 在以前的版本中，Image Registry Operator 不会更新 config 资源的 .status.readyReplicas 字段，因此其值始终为 0。在这个版本中，Image Registry Operator 将部署的就绪镜像 registry 副本数写入配置中。现在，此字段显示有多少镜像 registry 副本已就绪。（BZ#1923811）
  • Azure 建议用户使用 Storage Accounts v2 而不是 v1。在某些安全配置集下，管理员可以强制 Azure 不接受创建 v1 存储帐户。由于镜像 registry 依赖于 v1 存储帐户，因此在这样的环境中集群安装会失败。在这个版本中，在集群 bootstrap 中，Image Registry Operator 会尝试创建和使用 V2 Storage account。v1 上运行的集群继续使用 V1 存储帐户。安装成功，Image Registry Operator 现在会报告 Available。（BZ#1929654）

ImageStreams

  • 在以前的版本中，从流导入多个镜像时，性能有时会慢。在这个版本中，对镜像 registry 的并发请求数量从 5 增加到 50，从而提高了性能。(BZ#1954715)

Insights Operator

  • 在以前的版本中，Insights Operator 不会收集 Cluster Version Operator（CVO）Pod 或 openshift-cluster-version 命名空间中的事件。因此，Insights Operator 不会显示有关 CVO 可能遇到的任何问题的信息，用户无法获取有关 CVO 的诊断信息。Insights Operator 现已更新，它会从 openshift-cluster-operator 命名空间中收集 CVO Pod 和事件，以便 Insights Operator 报告 CVO 的问题。（BZ#1942271）

安装程序

  • 在以前的版本中，DNSmasq 需要指定 IPv6 网络以外的任何 /64 网络时的前缀长度。因此，control plane 主机无法进行 PXE 引导。在这个版本中，DNSmasq 配置中包含子网前缀长度。因此，control plane 主机现在将在任何前缀长度的 IPv6 网络中引导 DHCP 和 PXE。(BZ#1927068)
  • 安装到 vSphere 时，bootstrap 机器有时无法正确更新 /etc/resolv.conf 文件中的名称服务器。因此，bootstrap 机器无法访问临时 control plane，安装会失败。在这个版本中，包括查找正确行以更新更可靠的更改。现在，bootstrap 管理器可以访问其临时 control plane，安装可以成功。(BZ#1967355)
  • 在以前的版本中，安装程序不会在生成其 URL 时考虑 bootstrap Ignition 配置应位于的区域。因此，bootstrap 机器无法从提供的 URL 获取配置，因为它不正确。在这个版本中，在生成 URL 时会考虑用户的区域，并选择正确的公共端点。因此，安装程序总是生成正确的 bootstrap Ignition URL。（BZ#1934123）
  • 在以前的版本中，在创建存储帐户时，Azure 的 Minimum TLS 的默认版本是 1.0。因此，策略检查会失败。在这个版本中，将 openshift-installer Azure 客户端配置为在创建存储帐户时将 Minimum TLS 版本设置为 1.2。现在，策略检查会通过。（BZ#1943157）
  • 在以前的版本中，使用 Azure 上 IPI 部署的私有集群有一个入站 NSG 规则，允许 SSH 到 bootstrap 节点。这个声明可能会触发 Azure 的安全策略。在这个版本中，NSG 规则已被删除。（BZ#1943219）
  • 在以前的版本中，安装程序无法识别 ap-northeast-3 AWS 区域。在这个版本中，安装程序允许安装适合已知分区模式的未知区域，允许用户在 ap-northeast-3 AWS 区域中创建基础架构。（BZ#1944268）
  • 在以前的版本中，内部平台无法创建内部负载均衡器。在这个版本中，当用户创建 manfiests 时，添加了一个检查，以确保仅在 AWS、Azure 和 GCP 等云平台中使用此策略。（BZ#1953035）
  • 在以前的版本中，当命名 Google Cloud Platform 资源时，过滤器会阻止一些使用 Google 一词的某些名称。在这个版本中，在集群名称的安装程序中添加了一个检查，允许在设置名称时使用 Google 的一些变体。（BZ#1955336）
  • 在以前的版本中，使用安装程序置备的基础架构进行裸机安装需要安装程序过程能够与置备网络通信。现在，安装程序过程可以与 API 服务器的虚拟 IP 通信。当置备网络不可路由且安装程序进程从远程位置运行，如 Hive for Red Hat OpenStack Platform（RHOSP）或 Red Hat Advanced Cluster Management 时，这个改变会导致这种情况。您可能需要调整防火墙规则，以允许与 API 服务器的虚拟 IP 上的 TCP 端口 6385 和 5050 通信。（BZ#1932799）

  • 在以前的版本中，当在 Red Hat OpenStack Platform（RHOSP）上安装提供 platform.openstack.machinesSubnet 字段中不存在的子网 ID 时，openshift-install 命令会生成 SIGSEGV 和 backtrace。现在，openshift-install 命令会被修改，它会生成类似以下信息的错误： 

    FATAL failed to fetch Metadata: failed to load asset "Install Config": platform.openstack.machinesSubnet: Not found: "<network-ID>"

    （BZ#1957809）

  • 在以前的版本中，除非将 RHOSP HTTPS 证书导入到托管设备，在 Red Hat OpenStack Platform（RHOSP）上安装会失败。现在，当 cloud.yaml 中的 cacert 值被设置为 RHOSP HTTPS 证书时，会成功进行安装。不再需要将证书导入到主机。(BZ#1786314)
  • 在以前的版本中，因为 proxy.config.openshift.io 中的外部网络条目不准确，安装可能会失败。现在，验证检查会识别出这些不准确以启用更正。(BZ#1873649)
  • 以前，Traform 组件描述已被更清晰的信息替代。(BZ#1880758)
  • gophercloud/utils 的先前更改引入了使用自签名证书的自定义 HTTP 客户端。由于此更改从 DefaultTransport（包括代理环境变量）中删除了设置，从而导致使用自签名证书和代理的安装失败。在这个版本中，自定义 HTTP 客户端会继承 DefaultTransport 中的设置，因此现在可以使用自签名证书和代理安装 OpenShift Container Platform。（BZ#1925216）
  • 在以前的版本中，安装程序在验证过程中不会考虑安装配置中的 defaultMachineSet 值，这会导致安装程序失败。在这个版本中，默认值应用到安装配置，并开始验证空字段。(BZ#1903055)
  • 在以前的版本中，soft-anti-affinity 需要客户端设置最小 Nova 微版本。Ansible OS 服务器模块的大多数版本都不需要客户端设置最小值。因此，软反关联性命令可能会失败。在这个版本中解决了在处理软反关联性时使用 Python OpenStack 客户端设置 Nova 微版本的问题。(BZ#1910067)
  • 在以前的版本中，OpenStack UPI playbook 没有标记创建的所有资源。因此，openshift-install destroy 命令无法正确识别所有集群资源并循环删除资源，直到它达到超时（这会放弃资源）。在这个版本中，为 OpenStack UPI playbook 添加缺少的标签指令。(BZ#1916593)
  • 在以前的版本中，e2e-gcp-upi 无法成功，因为 Python 软件包错误导致失败。在这个版本中，您可以为 gsutil 设置正确的 Python 版本、管道版本和 CLOUDSDK_PYTHON 以解决软件包错误。（BZ#1917931）
  • 在以前的版本中，pip 版本 21 不支持安装的 Python 版本 2。因此，这会导致解决设置容器所需的所有依赖软件包错误。在这个版本中，pip 版本被修复为小于 21 的值，以避免出现这个问题。（BZ#1922235）
  • 在以前的版本中，安装程序会收集有关云的信息两次。因此，对 OpenStack API 的请求数量翻倍，这在云上造成额外负载并增加安装时间。在这个版本中，在检查配额前收集有关云的信息，然后重复使用相同的验证信息。（BZ#1923038）
  • 在以前的版本中，当使用 IPv6 部署时使用 /64 以外的子网置备网络时，DNSmasq 需要指定前缀长度。因此，在使用非 64 网络时主机无法进行 PXE 引导。在这个版本中，DNSmasq 配置中包含前缀长度。因此，主机在 DHCP 上成功，在任何前缀长度的 IPv6 网络中启动 PXE。（BZ#1925291）
  • 在以前的版本中，在删除 Shared Subnet 标签时，OpenShift Container Platform 安装程序不会报告 IAM 权限问题，即使日志记录显示已删除它们。此更新会检查取消标记和日志记录错误的结果。现在，日志代表了未标记共享资源的状态。（BZ#1926547）
  • 在以前的版本中，Azure 集群是使用 Premium_LRS 的磁盘类型创建的，且实例类型不支持 PremiumIO 功能，这会导致集群失败。在这个版本中，只有在磁盘类型为 Premium_LRS（默认磁盘类型）时，才会检查所选的实例类型是否具有 PremiumIO 功能。代码查询 Azure 订阅和区域以获取所需的信息，并在未满足条件时返回错误。（BZ#1931115）
  • 在以前的版本中，当 API 服务器重启时，API VIP 可能会在 bootstrap 中不可用，这会导致置备服务不可用，并导致置备失败。置备服务 (Ironic) 现在包含在 VIP 健康检查中，API VIP 仍然可用。(BZ#1949859)

kube-apiserver

  • 在以前的版本中，GCP 负载均衡器健康检查器会在主机上保留过时的 conntrack 条目，这会导致网络中断使用 GCP 负载均衡器的 API 服务器流量。健康检查流量不再循环主机，因此不再对 API 服务器造成网络中断。（BZ#1925698）

Machine Config Operator

  • 在以前的版本中，排空超时和池限制周期太短，并可能导致在需要更多时间的普通集群中持续发出警报。在这个版本中，超时报告扩展失败前所需的时间。这为 Cluster Operator 提供了更现实和有用的警报，而不会永久降低普通集群的性能。（BZ#1968019）
  • 在以前的版本中，当使用 OpenShift Installer Provisioned Infrastructure（IPI）从 VMware vSphere 创建新虚拟机时，节点无法加入集群。当由 DHCP 输入主机名代替 IDI 提供的名称时，会出现这种情况。这个问题已解决。（BZ#1920807）
  • 在以前的版本中，如果在设置主机名前启用网络，安装可能会失败。这阻止节点加入 cluser，并在进行另一个尝试前强制进行五分钟的延迟。现在，这个问题已被解决，节点会在第一次尝试时自动加入集群。(BZ#1899187)
  • 在以前的版本中，用户可以删除 core 用户和相关 SSH 密钥，尽管密钥仍然存在。在这个版本中，用户无法删除 core 用户。(BZ#1885186)
  • 当从 4.6 升级到 4.7 时，只有在安装了节点时才会应用 vsphere-hostname 服务设置的主机名。如果在升级之前没有静态地设置主机名，则主机名可能会丢失。在这个版本中，删除了允许 vsphere-hostname 服务仅在安装节点时运行的条件。因此，升级时 vSphere 主机名不再丢失。（BZ#1942207）
  • 由于 Keepalived 2.0.10 中存在一个错误，如果存活度探测终止了 keepalived 容器，分配给系统的任何虚拟 IP 地址（VIP）仍然保留，且在 keepalived 重启时不会被清理。因此，多个节点可以拥有相同的 VIP。现在，当 keepalived 启动时会删除 VIP。因此，VIP 由单个节点持有。（BZ#1931505）
  • 在以前的版本中，与 rpm-ostree 相关的操作没有在非 CoreOS 节点上正确处理，如 Red Hat Enterprise Linux CoreOS（RHCOS）。因此，当在包含 RHEL 节点的池中应用操作（如内核切换）时，RHEL 节点会降级。在这个版本中，当非 CoreOS 节点上执行不支持的操作时,Machine Config Daemon 会记录一条消息。记录消息后，它会返回 nil 而不是错误。现在，当不支持的操作由 Machine Config Daemon 执行时，池中的 RHEL 节点会按预期进行。（BZ#1952368）
  • 在以前的版本中，空静态 pod 文件被写入 /etc/kubernetes/manifests 目录中。因此，kubelet 日志报告错误，可能会导致与某些用户产生混淆。现在，当不需要时，空清单会被移到另一个位置。因此，kubelet 日志中不会出现错误。（BZ#1927042）

Metering Operator

  • 在以前的版本中，Reporting Operator 在协调事件时错误处理 Report 自定义资源（CR），其中包含用户提供的保留周期。因此，过期的 Report CR 会导致 Reporting Operator 持续循环，因为受影响的自定义资源会无限期重新排队。在这个版本中，可以避免重新排队指定了保留周期的过期 Report CR。因此，Reporting Operator 可以正确地为过期的 Report CR 处理事件。（BZ#1926984）

监控

  • 在以前的版本中，node-exporter daemontset 的 mountstats 收集器会导致在带有 NFS 挂载点的节点中使用高内存。在这个版本中，用户可以禁用 mountstats 收集器来减少内存用量。(BZ#1955467)

网络

  • 在以前的版本中，一个不正确的 keepalived 设置有时会导致 VIP 结束在不正确的系统上，且无法返回到正确的系统。在这个版本中，删除了不正确的 keepalived 设置，以便 VIP 结束在正确的系统上。（BZ#1916890）
  • 根据 iptables 重写规则，使用固定源端口通过服务 IP 和 pod IP 连接到服务的客户端可能会遇到端口冲突的问题。在这个版本中，插入了一个额外的 OVS 规则，以注意发生端口冲突时，并执行额外的 SNAT 以避免上述冲突。因此，连接到服务时不再有端口冲突。(BZ#1910378)
  • 在以前的版本中，内部防火墙阻止 control plane 节点和出口分配节点之间的 IP 端口 9。这会导致将 IP 地址分配给出口节点失败。在这个版本中，可以通过 IP 端口 9 在 control plane 和出口（egress）节点间进行访问。现在，允许将 IP 地址分配给出口节点。（BZ#1942856）
  • 在以前的版本中，UDP 服务流量可能会因为过时的连接跟踪条目不再有效而被阻止。此服务器容器集在为 NodePort 服务循环后进行 pevented 访问。在这个版本中，当 NodePort 服务循环时，连接跟踪条目会被清除，这将允许新网络流量访问循环端点。（BZ#1949063）
  • 在以前的版本中，OVN-Kubernetes 网络供应商忽略带有多个 ipBlocks 的网络策略。在忽略第一个 ipBlock 后，每个 ipBlock 都被忽略，从而导致 pod 无法访问所有配置的 IP 地址。更正了用于从 Kubernetes 网络策略生成 OVN ACL 的代码。因此，带有多个 ipBlock 的网络策略现在可以正常工作。（BZ#1953680）
  • 在以前的版本中，当使用 OVN-Kubernetes 集群网络供应商时，Kubernetes 服务会错误地接受任何端点。在这个版本中，在没有端点的情况下，不再为服务创建一个负载均衡器，因此不再接受流量。（BZ#1918442）
  • 在以前的版本中，Mulltus 的 Container Network Interface（CNI）插件不知道以任意数量的零开头的 IPv6 地址。在这个版本中，CNI 插件可用于以大于零值开头的 IPv6。（BZ#1919048）
  • 在以前的版本中，当机器配置策略的更改也触发重启时，SR-IOV Network Operator 启动重启时可能会触发竞争条件。如果发生这种情况，节点将处于非确定状态。在这个版本中，可以避免出现这种情况。（BZ#1921321）
  • 在以前的版本中，当使用 Kuryr 集群网络供应商创建新用户置备的集群时，集群节点使用的 OpenStack 子集可能没有被检测到，从而导致集群安装超时。在这个版本中，可以正确地检测到子网，用户置备的安装会成功。（BZ#1927244）
  • 在以前的版本中，当从 OpenShift Container Platform 4.6 升级到 OpenShift Container Platform 4.7 时，Cluster Network Operator（CNO）会错误地将自身标记为完成升级到下一版本。如果升级随后失败，则 CNO 会报告自己降级，但会错误地报告版本 4.7。在这个版本中，CNO 会等待集群网络供应商镜像成功升级，然后报告 CNO 升级成功。（BZ#1928157）
  • 在以前的版本中，当使用 OVN-Kubernetes 集群网络供应商时，如果 Kubernetes 版本包含非数字字符的次版本，端点分片控制器可能无法运行。在这个版本中，端点片段控制器会被默认启用。（BZ#1929314）
  • 当使用 Kuryr 集群网络供应商时，安装后创建的 Neutron 端口的命名模式与安装期间创建的 Neutron 端口不同。因此，安装后创建的 Neutron 端口不会添加到默认负载均衡器中。在这个版本中，Kuryr 会检测使用任一命名规则创建的 Neutron 端口。（BZ#1933269）
  • 在以前的版本中，Open Virtual Network（OVN）将 Conpin 流量数据包的源 IP 地址改为负载均衡器的 IP 地址，当使用网络策略时有时会阻断流量。在这个版本中，Kuryr 会将流量打开到网络策略命名空间中所有服务的 IP 地址，并自由允许流量流。（BZ#1920532）
  • 在以前的版本中，当在带有 IPv4 地址的节点上启动单堆栈 IPv6 集群时，kubelet 可能已经使用 IPv4 IP，而不是节点 IP 的 IPv6 IP。因此，主机网络 pod 会具有 IPv4 IP 而不是 IPv6 IP，这使得它们无法从仅支持 IPv6 的 pod 访问。在这个版本中，node-IP-picking 代码被修复，这会导致 kubelet 使用 IPv6 IP。（BZ#1939740）
  • 在以前的版本中，因为未知的原因，kubelet 可能会为节点注册错误的 IP 地址。因此，节点会处于 NotReady 状态，直到重新引导为止。现在，systemd Manager 配置被重新载入，并带有有效的 IP 地址作为环境变量，这意味着节点不再进入 NotReady 状态，因为 kubelet 注册了错误的 IP 地址。（BZ#1940939）
  • 在以前的版本中，重构一个shadowed 变量会导致与使用检查点文件相关的回归，SR-IOV pod 沙盒不会启动。在重构过程中，检查 kubelet 套接字的路径没有被正确考虑。在这个版本中，正确地恢复了 kubelet 套接字路径的检查，现在 SR-IOV pod 沙盒可以被正确创建。(BZ#1968625)

节点

  • 在以前的版本中，运行 lsblk 的未授权容器 pod 中可以看到可靠的自主分布式对象存储（RADOS）块设备（RBD）。这个问题已被解决，运行 lsblk 的未授权容器容器集中将无法再看到 RBD。（BZ#1772993）。
  • 在以前的版本中，在集群升级过程中，/etc/hostname 文件被 CRI-O 更改，这会导致节点失败并在重启时返回。在这个版本中，在 CRI-O 中添加了特殊处理，以便在升级过程中单独保留 /etc/hosts 文件，这允许升级的节点在不出现问题的情况下引导。（BZ#1921937）
  • 在以前的版本中，CRI-O 在网络置备后创建 pod 所需的时间太长。这会在网络清理代码中触发一个错误，从而导致网络资源在调配网络资源后无法正确清理。这个版本会更改代码来正确清理网络资源，即使命令超时也是如此。这使得集群可以继续正常的网络操作，即使 pod 创建用时过长。（BZ#1957224）
  • 在以前的版本中，使用 CNI 插件重启节点无法成功完成。CRI-O 被修改为在重启前运行的所有容器上调用 CNI DEL。在这个版本中，清理 CNI 资源并允许成功重启。(BZ#1948137)
  • 在以前的版本中，如果 CNI DEL 请求失败，则不会处理它，因为 CNI 清理操作不会检查清理失败。现在，CRI-O 会重复调用 CNI DEL 请求直到成功为止，正确地清理 CNI 资源。(BZ#1948047)
  • 在以前的版本中，如果在容器或镜像提交到磁盘时重启发生，对容器或镜像的重启请求可能会导致失败。这会导致容器存储的明显损坏，并导致导致镜像或从镜像重新创建容器失败。此更新会检测节点的重启，并清除容器存储（如果为 true）。(BZ#1942536)
  • 在以前的版本中，runc 采用运行它的实体的权限。但是，workdir 的权限由 container 用户设置。当这些权限有所不同时，容器创建错误发生，并导致容器启动失败。此补丁更新了 runc，它会尝试多次 chdir 到 workdir，以防有一次失败。这样可确保容器创建成功。（BZ#1934177）
  • 在以前的版本中，CRI-O 日志不包含有关镜像拉取（pull）的源的信息。在这个版本中，日志拉取源被添加到 CRI-O 日志的 info 级别。(BZ#1881694)
  • 在以前的版本中，当 pod 被快速创建和删除时，pod 可能没有足够的时间来在 pod 启动删除前完成 pod 沙盒创建。因此，pod 删除可能会失败，并带有 'ErrCreatePodSandbox' 错误。现在，如果 pod 终止，这个错误会被忽略。因此，如果 pod 无法完成 pod 沙盒创建，pod 终止不再会失败。(BZ#1908378)
  • 在以前的版本中，Machine Config Operator（MCO）不接受 trace 作为有效的日志级别。因此，MCO 无法提供一个方法来启用追踪级别的日志记录，即使 CRI-O 支持它。MCO 现在已更新，以支持 trace 日志级别。因此，用户可以通过 MCO 配置来查看 trace 日志级别。（BZ#1930620）
  • 在以前的版本中，kubelet 会尝试获取没有完全拉取的镜像的状态。因此，crictl 会对这些镜像报告一个 error locating item named "manifest" 错误。CRI-O 现在被更新为不列出没有清单的镜像。因此，crictl 不再报告这些错误。（BZ#1942608）
  • 在以前的版本中，不会删除过时的状态信息。因此，Machine Config Operator（MCO）有时无法找到正确的机器配置池。在这个版本中，添加了一个清理功能来限制状态数量。因此，MCO 最多保留 3 个不同的 kubeletConfig 状态。（BZ#1950133）
  • 在以前的版本中，当从 OpenShift Container Platform 版本 4.6.25 升级时，在具有多个 kubeletconfig CR 或 ContainerRuntimeConfig CR 的集群中，Machine Config Operator（MCO）可能会为同一配置生成重复的机器配置。因此，升级会失败，因为 MCO 将使用旧的控制器版本（IGNITIONVERSION 3.1.0）。在这个版本中清理了过时的重复机器配置，并允许从 4.6.25 正确升级。（BZ#1955517）

oauth-apiserver

  • 在以前的版本中，一些 OAuth 服务器指标没有被正确初始化，且不会出现在 Prometheus UI 中的搜索中。现在，缺少的 OAuth 服务器指标会被正确初始化，并出现在 Prometheus UI 指标搜索中。(BZ#1892642)
  • 在以前的版本中，如果自定义安全性上下文约束（SCC）包含 defaultAllowPrivilegeEscalation: false 和 allowPrivilegedContainer: true 字段的组合，则安全性上下文变异将特权 openshift-apiserver 和 oauth-apiserver pod 改为失败 API 验证的状态。容器集启动失败，有时会导致 OpenShift API 中断。现在,安全性上下文变异会忽略已经特权的容器的 defaultAllowPrivilegeEscalation 字段，而包含这些字段的自定义 SCC 不会阻止 Pod 启动。（BZ#1934400）

oc

  • 在以前的版本中，当运行 oc explain 命令时，如果作为资源字符串的一部分提供资源组名称，则不会自动检测到资源组名称。如果不同组中的两个资源具有相同的资源名称，则返回最高优先级定义，除非通过 --api-version 参数声明该组。现在，如果没有包含 --api-version 参数，则会针对资源字符串运行前缀检查，以检测组名称。命令返回的说明与上述组中的匹配资源相关。(BZ#1725981)
  • 在以前的版本中，oc image extract 命令没有从镜像的根目录中提取文件。命令已更新，现在可以用于从映像根目录中提取文件。（BZ#1919032）
  • 在以前的版本中，oc apply 命令会在每次调用时获取 OpenAPI 规格。现在，当命令首次运行时，OpenAPI 规格会被缓存。当 oc apply 命令多次运行并减少了网络负载时，缓存的 OpenAPI 规格会被重复使用。（BZ#1921885）
  • 在以前的版本中，在镜像镜像过程中创建的授权标头可能会超过某些 registry 的标头大小限制。这在镜像操作过程中会导致错误。现在，oc adm catalog mirror 命令的 --skip-multiple-scopes 选项被设置为 true，以帮助防止授权标头超过标头大小限值。(BZ#1946839)
  • 在以前的版本中，当 oc volume set 命令包含 --claim-class 选项时，storageClassName 属性不会添加到 PersistentVolumeClaim 对象中。--claim-class 选项的值被添加到 volume.beta.kubernetes.io/storage-class 注解中。这会导致卷快照因为依赖 storageClassName 属性而失败。现在，oc volume set 命令将 --claim-class 选项的值应用到 PersistentVolumeClaim 对象中的 storageClassName 属性，卷快照可以引用属性值。（BZ#1954124）
  • 在以前的版本中，oc adm top --help 的输出表示 oc adm top 命令可能会显示 pod 和节点的 CPU、内存和存储资源使用情况。oc adm top 命令不显示存储资源使用情况。现在，oc adm top --help 输出中没有包括存储引用。（BZ#1959648）

Operator Lifecycle Manager (OLM)

  • 在以前的版本中，作为 Operator 安装一部分应用的 CustomResourceDefinition（CRD）对象有时可以满足同一 Operator 的较新版本的安装要求。因此，在 Operator 升级过程中，被替换的版本可能会被永久删除。在某些情况下，升级会停止。在这个版本中，作为 Operator 捆绑包安装一部分创建的或更新的 CRD 会被注解以指示其原始卷捆绑包。ClusterServiceVersion（CSV）对象使用这些注解来区分预先存在的 CRD 和相同捆绑包 CRD。因此，在应用当前版本的 CRD 前，升级不会完成。（BZ#1947946）
  • 在以前的版本中，运行由 CatalogSource 对象引用的索引的 pod 没有在 securityContext 字段中明确设置 readOnlyRootFileSystem: false。因此，如果存在一个安全上下文限制（SCC），它会强制 readOnlyRootFileSystem: true，并匹配该 pod 的 securityContext 匹配，它会被分配给该 pod，并导致它重复失败。在这个版本中，在 securityContext 字段中明确设置 readOnlyRootFileSystem: false。因此，CatalogSource 对象引用的 pod 不再与强制执行只读根文件系统的 SCC 匹配，因此不再失败。（BZ#1961472）
  • 在以前的版本中，如果在初始安装过程中在 startCSV 字段中指定版本，Operator Lifecycle Manager（OLM）不允许安装跳过的版本。这会导致这些跳过的版本无法安装，即使用户想要安装它们，无论为何要跳过它们。在这个版本中更新了 OLM，允许用户仅在初始安装过程中使用 Subscription 对象中的 startCSV 规格安装跳过的版本；用户仍然无法升级到跳过的版本，如预期一样。(BZ#1906056)
  • 因为 k8s.io/apiserver 没有处理 webhook 授权器的上下文错误，所以上下文错误（如超时）会导致授权器 panic。在这个版本中，增加了 API 服务器版本，使其包含此问题的上游修复，因此授权者可以正常处理上下文错误。（BZ#1913525）
  • 在以前的版本中，oc adm catalog mirror 命令无法轻松地用于在 airgapped 环境中监控镜像 Operator 目录。在这个版本中，目录的内容可以镜像到文件系统，放置到可移动介质中，然后从文件系统镜像（mirror）到 registry，以供 airgapped 集群使用。（BZ#1919168）
  • Catalog Operator 之前为安装计划创建了捆绑解包作业，但不设置超时。如果不存在或删除的捆绑包镜像，这会导致作业永久运行，安装计划将保留在 Installing 阶段，而不表示作业的 pod 无法解析镜像。在这个版本中，Catalog Operator 在捆绑解包作业上设置一个默认的 10m 超时，可以使用 --bundle-unpack-timeout 标志进行配置。因此，在配置的超时后捆绑解包作业会失败，安装也会过渡到 Failed 阶段，原因在 status.conditions 和 status.bundleLookups.conditions 属性中可见。（BZ#1921264）
  • OpenShift Container Platform 4.6 之前在集群上安装的 Operator 之前没有被识别为来自给定 Operator 软件包，用于依赖项解析和升级选择。这会导致现有 Operator 安装与其自己的订阅标准冲突，这会阻止命名空间内的升级和依赖项解析。在这个版本中更新了 OLM，以推断订阅引用的 Operator 的软件包名称和版本。因此，升级和依赖项解析可以如预期进行。（BZ#1921953）
  • 用于临时错误的 Info 日志级别会导致 OLM Operator 日志详细记录默认配置。在这个版本中，临时错误日志级别被改为 debug。因此，在 debug 配置中可以看到较少的非关键日志。(BZ#1925614)
  • 在以前的版本中，Subscription 对象的 spec.config.resources 部分总是应用于安装的部署，即使它未设置或为空。这会导致集群服务版本（CSV）中定义的资源被忽略，且只使用 Subscription 对象的 spec.config.resources 部分中定义的资源。在这个版本中更新了 OLM，仅在 spec.config.resources 部分设置为非 nil 或 non-empty 值时覆盖特定于部署的资源。（BZ#1926893）
  • 在依赖项和升级解析过程中，订阅的唯一性以前是基于订阅的软件包名称。如果命名空间中的两个订阅订阅同一软件包，它们会在内部被视为单个订阅，从而导致意外行为。在这个版本中，订阅在命名空间内部由 .metadata.name 而不是 .spec.name 进行唯一标识。因此，带有相同地 .spec.name 的多个 Subscription 对象的命名空间的升级和依赖关系解析行为一致。（BZ#1932001）
  • 当在后续的目录更新轮询尝试前剩余一分钟时，interval jitter 函数会截断重新同步间隔到零。这会导致 Operator Catalog 进入热循环，并浪费 CPU 周期。在这个版本中增加了用于计算重新同步延迟的 jitter 函数的精度。因此，Catalog Operator 大多会处于闲置状态，直到下一次目录更新轮询为止。（BZ#1932182）
  • 在 Operator 升级过程中，任何关联的 ServiceAccount 对象的所有者引用已更新为指向新的 ClusterServiceVersion（CSV）对象，而不是旧对象。这可能会导致在协调 CSV 和 Catalog Operator 的 OLM Operator 之间出现竞争条件，它会执行安装计划，因为服务帐户所有权更改将旧 CSV 标记为 Pending/RequirementsNotMet。当新 CSV 无限期等待旧 CSV 表示健康状态时，这会阻止升级完成。在这个版本中，第二个所有者已附加到任何现有所有者，而不是在一个步骤中更新所有者引用。因此，同一服务帐户可以同时满足旧 CSV 和新 CSV 的要求。（BZ#1934080）
  • 在以前的版本中，集群服务版本（CSV）需要关联的服务帐户没有设置 ownerReferences 值，或者将 ownerReferences 值设置为相关的 CSV。这会导致，default 服务帐户（它没有作为 Operator 安装的一部分创建）无法满足 CSV 的要求，如果其 metadata.ownerReferences 字段不为空。在这个版本中，CSV 需要相关服务帐户将 ownerReferences 值设置为 CSV，或者将 ownerReferences 值设置为相关的 CSV。因此，只有非 CSV ownerReferences 值的服务帐户可以满足任何 CSV 的要求。(BZ#1935909)
  • 在 OpenShift Container Platform 4.5 之前，由 openshift-marketplace 命名空间中的 Marketplace Operator 部署和管理的默认目录由 OperatorSource 对象创建，后者是由 Marketplace Operator 公开的 API。提供了适当的指标和警报，以指示 Operator 源遇到的错误。在 OpenShift Container Platform 4.6 中，OperatorSource 资源在几个发行版本已弃用后被删除，而 Marketplace Operator 则直接创建 OLM 的 CatalogSource 资源。但是，没有为 openshift-marketplace 命名空间中部署的目录源执行相同的指标和警报检测。因此，默认的目录源遇到的错误不会在 Prometheus 警报中突出显示。在这个版本中，OLM 中引入了新的 catalogsource_ready 指标，每当默认目录源的指标表示目录源处于 unready 状态时，Marketplace Operator 会触发警报。现在，Prometheus 警报会为 openshift-marketplace 命名空间中的未就绪默认目录源提供。(BZ#1936585)
  • 在以前的版本中，当从默认频道和非默认频道提供 candidate Operator 依赖项时，Operator Lifecycle Manager（OLM）可能会生成一个随机指定两个频道之一的订阅。现在，候选者会首先从默认频道，然后从其他频道满足 Operator 的依赖关系。（BZ#1945261）
  • 在以前的版本中，集群服务版本（CSV）可能被复制为多个 Operator 的组件。当在安装 Operator 后将命名空间添加到 Operator 组时，可能会发生这种情况。这个行为会影响内存使用和 CPU 负载。现在，CSV 不会出现在 Operator 的 status.components 字段中，原因为 Copied，性能不受影响。（BZ#1946838）

Operator SDK

  • 在以前的版本中，有些资源被发现在无限循环中，因为 ManagedFields 在协调过程中被处理。在这个版本中，更新了 operator-lib 来忽略 ManagedFields，从而获得一致性的循环。(BZ#1856714)
  • 正在为 Operator SDK 输出帮助信息，因为在 CLI 上传递 --help 时默认插件没有被调用。在这个版本中，调用默认插件，并在用户运行 operator-sdk init --help 命令时显示更为有用的帮助信息。(BZ#166222)
  • 在以前的版本中，如果使用缺少的可选验证器运行，operator-sdk bundle 将失败，而不是发出警告。这个问题已被修正。（BZ#1921727）

openshift-apiserver

  • 在以前的版本中，自定义安全性上下文约束（SCC）可能比默认集合中的其他人具有更高的优先级。因此，这些 SSC 有时与 openshift-apiserver pod 匹配，这会破坏它们在 root 文件系统中写入的功能。此错误还会导致一些 OpenShift API 中断。在这个版本中，openshift-apiserver pod 中明确提到 root 文件系统应该可写。因此，自定义 SCC 不应该阻止 openshift-apiserver pod 运行。（BZ#1942725）

Performance Addon Operator

  • 在以前的版本中，当将容器配置为提供低延迟响应时，带有 CRI-O 的动态中断掩码与 byirqbalance 系统服务的中断掩码不匹配。各自设置不同的掩码和被破坏的容器延迟。在这个版本中，通过将 CRI-O 设置为与其 irqbalance 系统服务匹配来更改中断掩码设置。因此，动态中断掩码处理现在可以正常工作。（BZ#1934630）

RHCOS

  • 在以前的版本中，在引导过程中启用多路径太晚。因此，Red Hat Enterprise Linux CoreOS (RHCOS) 会在有些多路径环境中返回 I/O 错误。在这个版本中，多路径已在引导过程早期启用。因此，RHCOS 不再在某些多路径环境中返回 I/O 错误。(BZ#1954025)
  • 在以前的版本中，一个潜在的竞争条件可能会导致 Red Hat Enterprise Linux CoreOS（RHCOS）PXE 部署中获取 rootfs 在一些环境中失败。在这个版本中，添加了在尝试拉取 rootfs 之前重试连接检查，以便在继续执行 coreos-livepxe-rootfs 脚本有时失败前验证对远程服务器和 rootfs 文件的访问。(BZ#1871303)
  • 在以前的版本中，MachineConfig 的用户预设置会被忽略。这意味着用户无法更改 kdump.service 的配置。现在，默认预设置的优先级级别低于用户配置的默认值，因此用户配置可以正确地覆盖供应商配置。（BZ#1969208）
  • 在以前的版本中，coreos-installer 会拒绝安装到带有损坏 GUID 分区表（GPT）的磁盘中，因为它会在使用安装镜像覆盖目标磁盘的 GPT 前尝试读取它。在这个版本中，当指示保留现有分区时，coreos-installer 只通过读取目标磁盘的 GPT 成功安装到带有损坏 GPT 的磁盘中。（BZ#1914976）
  • 在以前的版本中，在未格式化的直接访问存储设备（DASD）上安装集群会导致 coreos-installer 错误地创建磁盘扇区。现在，coreos-installer 可以正确地格式化新的、未格式化的 DASD 驱动器到 4096 个字节扇区。这允许 coreos-installer 完成操作系统镜像的安装到磁盘驱动器。（BZ#1905159）
  • 在以前的版本中，s390x z15 系统中的硬件辅助 zlib 解压缩会导致挂载 RHEL rootfs 镜像失败，这会导致使用 RHEL 8.3 内核的 REHL s390x z15 节点引导失败。现在，当有硬件辅助 zlib压缩时，内核已被更新来正确处理 zlib-compressed squashfs 文件。(BZ#1903383)
  • 在以前的版本中，zipl 命令通过假设扇区大小为 512 字节来配置磁盘 geometry。因此，在带有 4k 扇区的 SCSI 磁盘中，zipl 引导装载程序配置包含不正确的偏移，zVM 无法引导。在这个版本中，zipl 会考虑磁盘扇区大小，以便 zVM 可以成功引导。（BZ#1918723）
  • 在以前的版本中，chrony.config 可能会自动运行多次，除第一次运行外，每次都会失败。这会导致问题，因为 chrony.config 配置在初始运行时被设置且无法更改。现在，通过将配置设置过程限制为首次运行 chrony.config 来避免这些错误。（BZ#1924869）
  • 在以前的版本中，节点会出现不健康状态，在高负载期间不会如预期运行。这会导致使用内存比内存快的工作负载被回收。在这个版本中，解决了内存回收和内存不足的情况，这些状况在负载较大时不再发生。(BZ#1931467)
  • 在以前的版本中，使用 kernal 参数的绑定接口的最大传输单元（MTU）规格没有被正确分配。这个问题已被修正。（BZ#1932502）
  • 在以前的版本中，clevis-luks-askpass.path 单元不会被默认启用。这会导致重启后非 root LUKS Clevis 设备无法自动解锁。这个版本默认启用 clevis-luks-askpass.path 单元，并允许非 root LUKS Clevis 设备在重启时自动解锁。(BZ#1947490)
  • 在以前的版本中，systemd 过度读取 mountinfo 和过量消耗 CPU 资源，这会导致容器无法启动。在这个版本中，systemd 读取 mountinfo 时启用限制，允许容器成功启动。(BZ#1957726)
  • 在以前的版本中，当 Machine Config Operator（MCO）在启动时调用 Ignition 来检查 Ignition 版本时，Ignition 会崩溃。因此，MCO 启动会失败。在这个版本中，MCO 不再查询 Ignition 版本，MCO 会成功启动。(BZ#1927731)

路由

  • 在以前的版本中，HAProxyDown 警报信息是模糊的。因此，最终用户认为警报意味着路由器 Pod（而非只有 HAProxy pod）不可用。在这个版本中，HAProxyDown 警报信息更清晰。（BZ#1941592）
  • 在以前的版本中，HAProxy 的帮助程序功能模板负责为白名单 IP 生成文件，这预期为错误的参数类型。因此，较长 IP 列表中的后端不会应用白名单 ACL。在这个版本中，helper 功能模板的参数类型会被改变，以便白名单 ACL 应用到长 IP 列表的后端。(BZ#1964486)
  • 在以前的版本中，当使用自定义域创建 Ingress 时，Ingress Ingress 控制器使用路由器规范主机名更新 Ingress 的状态，并使用 external-dns 与 Route 53 同步。问题是 DNS 中不存在规范路由器主机名，且不是由 OpenShift Container Platform 创建的。OpenShift Container Platform 创建 *.apps.<cluster_name>.<base_domain> DNS 记录，而不是 apps.<cluster_name>.<base_domain> DNS 记录。因此，规范路由器主机名不正确。在这个版本中，将规范路由器主机名设置为 router-default.apps.<cluster_name>.<base_domain>。具有自动化并采用规范主机名并加上通配符或子域的集群管理员应注意，规范入口主机名被设置为 <ingress-controller-name>.apps.<cluster_name>.<base_domain>。(BZ#1901648)
  • 在以前的版本中，BZ#1932401 的修复会覆盖默认的 Go HTTP 客户端传输。因此，集群范围的代理设置不会被 Ingress Operator pod 处理，这会导致在带有集群范围出口代理的集群上出现 Canary 检查失败。在这个版本中，在 canary 客户端的 HTTP 传输中明确设置了代理设置。因此，canary 检查可用于所有集群范围的代理。（BZ#1935528）
  • 在以前的版本中，canary DaemonSet 没有指定节点选择器，因此它会为 canary 命名空间使用默认节点选择器。因此，canary DaemonSet 无法调度到 infra 节点，在某些情况下会引发警报。在这个版本中，将 Canary DaemonSet 明确调度到 infra 节点，并容许污点的 infra 节点。这允许 Canary DaemonSet 安全地部署到 worker 和 infra 节点，而无需出现问题或警报。（BZ#1933102）
  • 在以前的版本中，当从带有空闲工作负载的旧版本升级集群时，闲置工作负载在升级到 OpenShift Container Platform 4.6 或 4.7 后不会在 HTTP 请求中唤醒，因为 oc idle 功能修复并重新工作。在这个版本中，闲置更改从端点镜像到 Ingress Operator 启动时的服务。因此，升级后取消闲置工作负载可以正常工作。（BZ#1925245）
  • 在以前的版本中，通过将所有 HTTP 流量重定向到 HTTPS 的外部负载均衡器公开默认 Ingress Controller 会导致 Ingress Canary 端点检查失败，从而导致 Ingress Operator 降级。在这个版本中，明文 Canary 路由转换为边缘加密路由。现在，canary 路由只在负载均衡器重定向不安全流量时才可以正常工作。（BZ#1932401）
  • 在以前的版本中，Ingress Operator Canary Check Client 会将 Canary 请求通过 HTTP 发送到丢弃 HTTP 流量的负载均衡器。这会导致 Ingress Operator 在 Canary 检查失败后变为降级。在这个版本中，Ingress Operator Canary Check Client 从启动时通过 HTTPS 发送 Canary 检查请求，而不依赖于路由器的重定向。现在，canary 检查可以通过丢弃不安全 HTTP 流量的负载均衡器来公开默认 Ingress Controller 的集群。（BZ#1934773）
  • 在以前的版本中，openshift-router 使用的 HAProxy 模板重复调用 firstMatch() 函数。该函数每次都解析和重新编译正则表达式。在对 firstMatch() 的每个调用中解析和重新编译正则表达式非常昂贵，特别是具有数以千计路由的配置。在这个版本中，如果调用 firstMatch() 中的正则表达式已被看到，则已编译的版本将被重复使用并缓存。现在，在解析和评估 haproxy-config.template 时，运行时减少了 60%。（BZ#1937972）
  • 在以前的版本中，用户可以使用覆盖注解命名带有无效主机名的路由。在这个版本中解决了这个问题。（BZ#1925697）
  • 在以前的版本中，从通过路由公开的服务中删除 选择器（selector） 会导致为服务 pod 创建的 endpointslices 重复，这会因为重复的服务器条目而触发 HAProxy 重新加载错误。在这个版本中，在编写 HAProxy 配置文件时会过滤掉意外重复的服务器行，因此从服务中删除选择器不再会导致路由器失败。（BZ#1961550）

Samples

  • 在以前的版本中，Cluster Samples Operator 可能会更改其正在监视的对象的控制器缓存，这会导致 Kubernetes 管理控制器缓存时出现错误。在这个版本中，Cluster Samples Operator 如何使用控制器缓存中的信息。因此，Cluster Samples Operator 通过修改控制器缓存不会造成错误。（BZ#1949481）

service-ca

  • OpenShift Container Platform 4.8 允许用户以非 root 用户身份运行 service-ca-operator pod，以满足其机构的需求。当以非 root 用户身份运行时，service-ca-operator 会以以下 UID 和 GID 的形式运行： 

    uid=1001(1001) gid=1001 groups=1001

    (BZ#1914446)

存储

  • 在以前的版本中，请求一个 capacity breakdown 容量时不会报告块类型 PVC 文件系统的指标。这意味着用户收到所有文件系统中指标的不准确报告。在这个版本中，Kubelet 请求块类型 PVC。这提供了对所有文件系统指标的准确报告。(BZ#1927359)
  • 在以前的版本中，/var/lib/kubelet 在 Cinder CSI Node Controller 容器中被挂载两次。这会导致 CSI Node Controller 无法启动并显示 /var/lib/kubelet/pods 缺少空间的错误。在这个版本中，删除了 /var/lib/kubelet 和 /var/lib/kubelet/pods 的重复挂载，这允许 CSI Node Controller 成功运行。(BZ#1952211)
  • 在以前的版本中，在 Cinder CSI Driver 调整持久性卷（PV）大小的过程中，findmnt 命令会收到多个卷挂载，且无法选择正确的挂载，从而导致重新定义大小停止。因此，用户必须手动扩展文件系统。在这个版本中，命令使用第一次挂载，以便文件系统与 PV 的大小调整。（BZ#1919291）
  • 现在，在创建默认存储类时，Cinder CSI Driver Operator 会自动为 Cinder CSI 置备默认 VolumeSnapshotClass 对象，而不是手动创建 VolumeSnapshotClass 对象。（BZ#1905849）
  • 在以前的版本中，recycler-pod 模板被错误地放入 kubelet 静态清单目录中。这个错误的位置会产生静态 pod 日志消息，指出回收器静态 pod 启动失败。在这个版本中，错误的 recycler-pod 模板已从静态 pod 清单目录中移除。因此，不再会出现错误消息。(BZ#1896226)
  • 在以前的版本中，Local Storage Operator（LSO）可能会声明属于其他置备程序磁盘，因为忙碌磁盘被错误地检测到为空闲。现在会检查磁盘中的绑定挂载，以便 LSO 无法声明这些磁盘。（BZ#1929175）
  • 在以前的版本中，LSO 会尝试创建一个带有无效标签值的持久性卷（PV），因为设备 ID 包含不受支持的字符，例如 :。通过将设备信息从标签移到注解中，这个问题已被修正。（BZ#1933630）
  • 在以前的版本中，Local Storage Operator（LSO）没有清理持久性卷（PV），因为删除器没有被正确排队。这会导致 PV 处于 released 状态。现在，PV 可以被正确排队，以便可以正确删除 PV。(BZ#1937145)
  • 在以前的版本中，当 pod 被删除时，Fibre Channel 卷会错误地从节点卸载。当节点上 kubelet 未运行时，使用该卷的不同 pod 会在 API 服务器中删除。在这个版本中，Fibre Channel 卷在新 kubelet 启动时正确卸载。另外，在新 kubelet 完全启动和卸载卷前，卷无法挂载到多个节点，这样可确保光纤通道卷不会被破坏。（BZ#1954509）

Web 控制台（管理员视角）

  • 在以前的版本中，当在开发人员模式的控制台 UI 中尝试删除 CNV 命名空间中的自定义资源时，点 Delete 会导致 Delete 按钮挂起处于卡住状态。此外，在 CLI 中执行相同操作时出现的错误消息不会显示。在这个版本中，错误消息会如预期显示，Delete 按钮不会处于卡住状态。（BZ#1939753）
  • 在以前的版本中，OperatorHub Provider Type filter 属性没有清晰地显示与 CatalogSource 的关系。因此，用户无法知道 filter 标准的含义。此补丁将 Provider Type filter 更新为 Source。这可以更清楚地显示 filter 和 CatalogSource 之间的关系。(BZ#1919406)
  • 在以前的版本中，Resources 菜单中的 ResourceListDropdown 组件没有对某些语言进行国际化。在这个版本中，Resource 菜单已被更新，以便为非英语用户提供更好的用户体验。(BZ#1921267)
  • 在以前的版本中，一些菜单项（如 Delete Persistent Volume Claim ）没有正确国际化。现在，更多菜单项目已被正确国际化。（BZ#1926126）
  • 在以前的版本中，Add HorizontalPodAutoscaler 页面的一些文本和警告信息没有被国际化。文本现已国际化。（BZ#1926131）
  • 在以前的版本中，当用户使用 Operator SDK 创建 Operator 并指定如下注解时，如 xDescriptors={"urn:alm:<…​>:hidden"} 以隐藏 Operator 实例创建页面中的字段，该字段可能仍会在页面中可见。现在，Operator 实例创建页面中会省略隐藏字段。(BZ#1966077)
  • 在以前的版本中，表在移动设备中没有正确显示。在这个版本中，表会正确显示。（BZ#1927013）
  • 在以前的版本中，启动 OpenShift Container Platform Web 控制台可能会很慢。在这个版本中，Web 控制台启动速度更快。(BZ#1927310)
  • 在以前的版本中，向 OpenShift Container Platform 管理员发出的通知没有进行国际化。现在，进行了一些国际化。（BZ#1927898）
  • 在以前的版本中，Cluster Utilization 仪表板中对持续时间信息缺少国际化。现在，进行了一些国际化。（BZ#1927902）
  • 在以前的版本中，当 OpenShift Container Platform Web 控制台中的 Operator Lifecycle Manager（OLM）状态描述符被分配不兼容的数据类型时，会出现错误。添加了验证，消除了不兼容的数据类型处理，从而避免了错误。记录警告也会识别不兼容的状态类型。(BZ#1927941)

  • 以下 OpenShift Container Platform Web 控制台视图现在支持多面过滤：

    • Home Search （ Resources 选项卡）
    • Home Events （ Resources 选项卡）
    • Workload Pods（Filter 选项卡）

    如需更多信息，请参阅 BZ#1930007。

  • 以下程序错误修复解决了 OpenShift Container Platform Web 控制台的各种转换问题：

  • 在以前的版本中，web 控制台依赖于硬编码的频道字符串来填充频道模态下拉菜单。因此，用户可以看到其当前版本可能不正确的频道值。现在，如果 Cluster Version Operator 没有为给定版本提供正确的频道，频道模态下拉列表会变为文本输入字段，并为用户推荐频道和帮助文本。控制台不再依赖于硬编码频道字符串。（BZ#1932281）
  • 在以前的版本中，无法正确格式化中文或日语的时间戳。因此，时间戳难以阅读。在这个版本中，在 Moment.js 中针对中文和日文使用默认的时间戳格式，以提供更好的用户体验。（BZ#1932453）
  • 在以前的版本中，FilterToolbar 组件中的 rowFilters prop 不接受 null 值。因此，如果 rowFilters 未定义，则会出现未被捕获的异常。现在，当 FilterToolbar 组件中引用了 rowFilters prop 时，则接受 null 值。因此，当 rowFilters prop 未定义，FilterToolbar 不再会抛出异常。（BZ#1937018）
  • 在以前的版本中，帮助文本的错误样式应用到字段级别的帮助实例。现在，显示了字段级别的帮助文本的正确样式，并在控制台中保持一致。（BZ#1942749）。
  • 在以前的版本中，Operator Lifecycle Manamgent（OLM）状态条件描述符在资源详情页面中作为普通详情项呈现。因此，Conditions 表呈现为一半宽度。在这个版本中，状况描述符在 Operand 详情页的普通 Conditions 表下以全宽度表的形式呈现。(BZ#1943238)
  • 在以前的版本中，为中文用户翻译了"Ingresses"一词，这不太符合用户的习惯。现在，单词"Ingress"保留为英文。(BZ#1945816)
  • 在以前的版本中，为中文用户翻译了"Operators"，这不同符合用户的习惯。现在，单词"Operators"保留为英文。（BZ#1945818）
  • 在以前的版本中，一个不正确的代码会导致 User 和 Group 详情显示不相关的主题。现在，添加了根据 User 或 Group 的过滤代码，因此 User 和 Group 详情会显示相关的主题。（BZ#1951212）
  • 在以前的版本中，pod Containers 文本没有国际化，因此用户体验较差。现在，pod Containers 文本已被国际化，因此用户体验已被改进。（BZ#1937102）
  • 在以前的版本中，PackageManifest 列表页项没有链接到详情页面，因此用户无法轻松深入到列表页面中的单个 PackageManifest 项目。现在，每个 PackageManifest 项目都链接到与其它列表页的惯例匹配的详情页面。用户可从列表页面轻松访问 PackageManifest 详情页面。(BZ#1938321)
  • Jobs 表的 Completions 列按期望（Desired）完成的数量而不是成功（Succeeded）完成的数量进行排序。数据会显示为 # Succeeded of # Desired，因此当对列进行排序时，结果看起来很混乱，因为数据是按第二个数字排序的。现在，Jobs Completions 列按照 # Succeeded 进行排序。（BZ#1902003）
  • Manage Columns modal 中的输入标签不是可点击的按钮，因此您无法单击它们来管理列。在这个版本中，标签是用来管理列的可点击按钮。(BZ#1908343)
  • 在 Google Cloud Platform 上创建存储类时，CSI 置备程序不会被列出。在这个版本中，这个问题已解决。（BZ#1910500）
  • 在以前的版本中，如果用户从 User Management Roles 列表视图中点 Cluster Role，则详情页面中的后端链接是 Cluster Roles，它提供了 Cluster Role 的通用列表视图。这会导致向后 Web 控制台导航重定向到不正确的页面。在这个版本中，后端链接会把用户从 Cluster Role/RoleBinding 详情页导向 Role/Bindings 列表视图。这样，用户可以在 Web 控制台中正确地向后导航。（BZ#1915971）
  • 在以前的版本中，创建的日期时间不会以可读格式显示，从而导致难以理解和使用 UTC 中显示的时间。在这个版本中，显示的时间会被重新格式化，以便 UTC 可以被读取和理解。（BZ#1917241）
  • 在以前的版本中，Web 控制台中的 pod 请求和限制计算不正确。这是因为没有排除完成的 pod 或 init 容器。在这个版本中，计算中不需要的 pod 会被排除，这可以提高 Pod 请求 web 控制台计算结果的准确性。（BZ#1918785）
  • 在以前的版本中，解析未定义值会导致一个“不是一个数字”（NaN）异常，Chart 工具提示会显示没有值的方框。在这个版本中，在获取数据时指定一个开始日期，以便 Chart 工具提示显示正确的值。此更改可确保同步结果，并且未定义的值不会被解析。（BZ#1906304）
  • 在以前的版本中，pod 日志的下载链接被改为带有空 download 属性的标准 HTML 定位符元素。因此，下载文件会丢失默认文件名格式。在这个版本中，在 anchor 元素下载属性中添加了一个文件名，以便在下载 pod 日志时使用默认文件名（格式为 <pod-name>-<container-name>.log ）。（BZ#1945630）
  • 在以前的版本中，当用户有创建资源的权限但没有编辑资源的权限时，Web 控制台 YAML 编辑器被错误地设置为只读模式。现在，具有创建资源权限的用户可以编辑编辑器中的内容。(BZ#1824911)
  • 在以前的版本中，web 控制台在大多数情况下都以 12 小时格式显示时间，其他位置显示 24 小时格式。另外，过去一年之前的日期没有显示年信息。在这个版本中，日期和时间的格式一致，并符合用户的区域设置和语言首选项设置。过去一年之前的日期将显示年信息。(BZ#1862084)
  • 在以前的版本中，web 控制台正在为没有权利查看这些事件的用户轮询 ClusterVersion 资源。这会输出控制台 pod 日志中的大量错误。为避免这种情况，请在轮询资源前检查用户的权限，从而消除控制台 Pod 日志中的不必要的错误。(BZ#1848151)
  • 在以前的版本中，YAML 编辑器的键盘用户无法退出编辑器。编辑器外部的视图快捷方式弹出不可用供用户访问。在这个版本中，用户可以使用 opt + F1 键操作在编辑器上显示可访问性帮助。此更改允许 YAML 编辑器的键盘用户使用正确的击键操作退出编辑器。(BZ#1874931)
  • 在 OpenShift Container Platform（OCP）4.x 发布后，上传到 OCP 4 Web 控制台的二进制 secret 文件无法加载。这会导致安装失败。在 OpenShift Container Platform 4.8 中，此功能已恢复到 OCP 4 Web 控制台。现在，所需 secret 的输入可以使用二进制文件格式来完成。(BZ#1879638)
  • 在以前的版本中，为了解决 BZ#1871996 以正确创建 RoleBinding 会导致在选择命名空间时无法选择绑定类型。因此，拥有活跃命名空间的用户无法在不将活跃命名空间更改为 All namespace 的情况下创建集群 RoleBinding。此更新恢复了针对 BZ#1871996 的更改的一部分，以便无论活跃命名空间，用户可以创建集群角色绑定。（BZ#1927882）

Web 控制台 (开发者视角)

  • 在以前的版本中，当在 Developer 控制台中将服务集群设置为本地的标签更改时，用户将无法创建 Knative 服务。在这个版本中，Knative 服务使用 cluster-local 的最新支持标签，以便用户以 cluster-local 用户身份从 Developer Console 创建 Knative 服务。(BZ#1969951)
  • 在以前的版本中，Image Manifest Vulnerabilities (IMV) 的 Low 和 Medium 严重性问题颜色与（Quay.io）界面中显示的颜色不匹配。因此，当用户将漏洞的严重性更改为 High 时，IMV 会错误地将问题排序。这会在检查 IMV 时造成混淆。当前发行版本解决了这个问题。(BZ#1942716)
  • 在以前的版本中，如果因为未安装 Samples Operator 而导致 OpenShift 命名空间模板不可用，Developer 视角中的 Topology 视图不会加载。在这个版本中解决了这个问题。（BZ#1949810）
  • 在以前的版本中，当导入 devfile 时，web 控制台会忽略 build guidance 占位符容器，该容器提供环境变量、端口和限值的配置。新部署有第二个容器，无法启动，因为无法获取占位符镜像，并且丢失了所需的配置。现在，build guidance 容器已从新部署中丢弃，容器会添加环境变量、端口和限制配置。（BZ#1952214）
  • 在以前的版本中，当在另一个标签页中切换到 Developer 视角并重新载入项目详情时，绑定到该视角的路由不会被呈现，并导致一个 404 错误。在这个版本中，会加载所有不活跃的路由，并切换到正确的视角。（BZ#1929769）
  • 在以前的版本中，当因为用户没有命名空间所需的访问权限而发生错误时，Monitoring dashboard 页面中的 Workload 下拉菜单会持续显示 Load-in-progress 图标。当前发行版本解决了这个问题。现在，Monitoring 仪表板页面会显示一个错误消息，指示已发生 Forbidden 错误。(BZ#1930546)
  • 在以前的版本中，API 服务器可能无法创建资源，当在更新资源配额时有冲突，资源会返回 409 状态代码。因此，资源将无法创建，您可能需要重试 API 请求。在这个版本中，OpenShift 控制台 Web 应用会在收到 409 状态代码时尝试重试请求 3 次，这通常足以完成请求。如果 409 状态代码持续发生，控制台中会显示一个错误。（BZ#1920699）
  • 在以前的版本中，当选择 YAML 选项卡时，metadata.managedFields 部分不会立即折叠。这是因为在一些页（如 Pipeline Builder 和 Edit HorizontalPodAutoscaler (HPA)）中的 Form 或 YAML 的切换功能中存在一个问题。因此，在您试图输入的文档部分会被折叠。metadata.managedFields 部分保持不变，光标则重置为 YAML 编辑器左上角的起始位置。当前发行版本解决了这个问题。现在，在载入 YAML 时，metadata.managedFields 部分会立即折叠。（BZ#1932472）
  • 在以前的版本中，在 Git Import 流中为私有存储库创建的管道无法运行。这是因为管道 ServiceAccount 对象没有将 Git Import 流创建的 secret 用于私有 Git 存储库。在这个版本中，您可以在管道 ServiceAccount 对象的注解中添加 secret 名称，并在提供的 secret 中添加特定于管道的注解。因此，私有 Git 存储库的管道运行可以成功。（BZ#1970470）
  • 在以前的版本中，当用户在 YAML 编辑器中插入格式化的 YAML 代码段时，新选择与代码片段中的新内容不匹配。缩进已被移除，在选择中可以看到一些随机字母。当前发行版本解决了这个问题。现在，光标保留在它启动的位置，并为光标结束位置添加缺少的缩进。插入 YAML 代码段后，新选择与新内容匹配。(BZ#1952545)
  • 在以前的版本中，注解被传递给 Knative 服务规格和元数据。因此，Topology 中 Knative 服务的相关修订会显示修饰符。此发行版本只将注解传递给 Knative 服务元数据，从而解决了这个问题。现在，只有 Topology 中的 Knative 服务会显示修饰符，而不是关联的修订版本。（BZ#1954959）
  • 在以前的版本中，如果您创建的管道带有带有空字符串的参数，如 "，OpenShift Container Platform Web 控制台中的字段将不会接受空字符串。当前发行版本解决了这个问题。现在，" 在 parameters 部分中被支持作为有效的默认属性。（BZ#1951043）
  • 在以前的版本中，用户无法从 Developer 视角将 Knative 服务创建为私有服务。这个问题现已解决，更新了标签 'networking.knative.dev/visibility': 'cluster-local'。(BZ#1970796)
  • 在以前的版本中，事件源和类型源的 Kamelets 类型在目录中显示。现在，通过过滤 Kamelets 资源来只列出源类型解决了这个问题。(BZ#1972258)

Windows 容器

  • 在以前的版本中，当用户扩展额外的 Windows 节点时，负载均衡器服务会变得不稳定。在这个版本中，负载均衡器服务稳定，允许用户添加多个 Windows 节点，而不会出现错误的性能。（BZ#1905950）
  • 在以前的版本中，如果 kube-proxy 服务在 Windows Pod 运行后创建，则 kube-proxy 服务会在负载均衡器被创建后意外崩溃。在这个版本中，kube-proxy 服务在重新创建负载均衡器服务时不会崩溃。（BZ#1939968）
  • 在以前的版本中，负载均衡器的 Ingress 中的空 IP 地址值会破坏数据路径。因此，Windows 服务无法访问。在这个版本中，即使 IP 地址值为空，也可以访问 Windows 服务。（BZ#1952914）
  • 在以前的版本中，当用户创建带有投射卷的 Windows pod 时，pod 会停留在 ContainerCreating 阶段。在这个版本中，Windows pod 创建可以成功进入 Running 阶段。（BZ#1973580）
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.