1.6. 程序错误修复

API 服务器和客户端
  • 在以前的版本中，在收到 workloadIsBeingUpdatedTooLong 错误后，Cluster Authentication Operator 状态被设置为 progressing = false。同时，在定义 inertia 时保留了 degraded = false。因此，由于缩短的进度以及增加的降级时间会导致一个问题：progressing = false 和 degraded = false 会在还不成熟的情况下被设置。这会导致 OpenShift CI 测试出现不一致的情况（因为假定了一个不正确的健康状态）。这个问题已通过在返回 workloadIsBeingUpdatedTooLong 错误后删除 progressing = false 设置来解决。现在，因为没有 progressing = false 状态，OpenShift CI 测试更为一致。(BZ#2111842)
裸机硬件置备
  • 在最近版本的服务器固件中，服务器操作之间的时间有所增加。当 OpenShift Container Platform 安装程序等待 Baseboard Management Controller (BMC) 的响应时，这会导致安装程序置备的基础架构安装过程中出现超时。新的 python3-sushy 发行版本会增加与 BMC 联系的服务器端尝试的数量。这个更新帐户会延长等待时间，并避免在安装过程中出现超时问题。(OCPBUGS-4097)
  • 在此次更新之前，Ironic 置备服务不支持使用弱 eTags 和严格的 eTag 验证的 Baseboard Management Controller (BMC)。按照设计，如果 BMC 提供弱 eTag，Ironic 会返回两个 eTags：原始的 eTag 和原始 eTag 转换为强格式，以便与不支持弱 eTags 的 BMC 兼容性。虽然 Ironic 可以发送两个 eTags，但使用严格的 eTag 验证的 BMC 会拒绝此类请求，因为存在第二个 eTag。因此，在某些较旧的服务器硬件上，裸机置备会失败，并显示以下错误： HTTP 412 Precondition Failed。在 OpenShift Container Platform 4.12 及更新的版本中，如果提供了弱 eTag，则此行为更改和 Ironic 不再尝试发送两个 eTags。相反，如果 Redfish 请求依赖 eTag 验证错误，Ironic 使用已知临时解决方案重试请求。这可最小化具有严格 eTag 验证的机器上裸机置备失败的风险。(OCPBUGS-3479)
  • 在此次更新之前，当 Redfish 系统具有 Settings URI 时，Ironic 置备服务总是尝试使用此 URI 来更改引导相关的 BIOS 设置。但是，如果 Baseboard Management Controller (BMC) 带有 Settings URI，但不支持使用此设置 URI 更改特定的 BIOS 设置，裸机置备会失败。在 OpenShift Container Platform 4.12 及更高版本中，如果系统具有 Settings URI，Ironic 会在继续操作前使用 Settings URI 来验证它是否可以更改特定的 BIOS 设置。否则，Ironic 使用 System URI 实现更改。此额外逻辑可确保 Ironic 可以应用与引导相关的 BIOS 设置更改，裸机置备可以成功。(OCPBUGS-2052)
Builds

  • 默认情况下，Buildah 会输出日志文件的步骤，包括环境变量的内容，其中可能包括 构建输入 secret。虽然您可以使用 --quiet 构建参数来禁止打印这些环境变量，但如果使用 Source-to-image(S2I)构建策略，则此参数将不可用。当前发行版本解决了这个问题。要禁止打印环境变量，请在构建配置中设置 BUILDAH_QUIET 环境变量： 

    sourceStrategy:
...
  env:
    - name: "BUILDAH_QUIET"
      value: "true"

    (BZ#2099991)

Cloud Compute
  • 在以前的版本中，实例不会被设置为遵守自动重启的 GCP 基础架构默认选项。因此，可以在不使用基础架构默认自动重启的情况下创建实例。这有时意味着实例在 GCP 中终止，但相关机器仍然列在 Running 状态，因为它们不会自动重启。在这个版本中，传递自动重启选项的代码已被改进，以更好地检测并传递用户的默认选项选择。现在，实例会正确使用基础架构默认，并在用户请求默认功能时自动重启。(OCPBUGS-4504)
  • PodDisruptionBudget 对象的 v1beta1 版本现在在 Kubernetes 中弃用。在这个版本中，对 v1beta1 的内部引用被 v1 替换。这个变化是集群自动扩展的内部，不需要用户操作，而不是 准备升级到 OpenShift Container Platform 4.12 Red Hat 知识库文章。(OCPBUGS-1484)
  • 在以前的版本中，GCP 机器控制器每 10 小时协调机器状态。其他提供程序将此值设置为 10 分钟，以便在短时间内检测到 Machine API 系统之外的更改。GCP 的较长的协调周期可能会导致意外的问题，如缺少证书签名请求(CSR)批准，因为延长周期没有检测到外部 IP 地址。在这个版本中，GCP 机器控制器被更新来每 10 分钟协调一次与其他平台一致，以便更早地获取外部更改。(OCPBUGS-4499)
  • 在以前的版本中，因为 Cluster Machine Approver Operator 的部署错误配置，启用 TechPreviewNoUpgrade 功能集会导致错误和 sporadic Operator 降级。因为启用了 TechPreviewNoUpgrade 功能集的集群使用 Cluster Machine Approver Operator 的两个实例，且两个部署都使用相同的端口集合，所以会出现单节点拓扑错误冲突。在这个版本中，Cluster Machine Approver Operator 部署被更新，为不同的部署使用不同的一组端口。(OCPBUGS-2621)
  • 在以前的版本中，Azure 中的零功能扩展依赖于静态编译的实例类型列表，将实例类型的名称映射到 CPU 数量以及分配给实例类型的内存量。此列表随着时间的推移会变得过时。在这个版本中，有关实例类型大小的信息直接从 Azure API 动态收集，以防止列表过时。(OCPBUGS-2558)
  • 在以前的版本中，Machine API 终止处理器 pod 不会在 spot 实例中启动。因此，如果实例终止，在污点 spot 实例上运行的 pod 不会收到终止信号。这可能会导致工作负载应用程序中丢失数据。在这个版本中，Machine API 终止处理器部署被修改为容许在带有污点的 spot 实例上运行的污点和容限，现在接收终止信号。(OCPBUGS-1274)
  • 在以前的版本中，Azure 集群的错误消息没有说明无法为只使用内部发布策略的断开连接的安装使用公共 IP 地址创建新机器。在这个版本中，会更新错误消息以提高清晰性。(OCPBUGS-519)
  • 在以前的版本中，Cloud Controller Manager Operator 不会检查 AWS 集群的 cloud-config 配置文件。因此，无法使用配置文件将额外的设置传递给 AWS 云控制器管理器组件。在这个版本中，Cloud Controller Manager Operator 会检查基础架构资源，并解析对 cloud-config 配置文件的引用，以便用户可以配置额外的设置。(BZ#2104373)
  • 在以前的版本中，当 Azure 添加了新实例类型并在之前没有它的实例类型启用加速网络支持时，机器控制器中的 Azure 实例列表已过时。因此，机器控制器无法使用之前不支持加速网络的实例类型创建机器，即使它们在 Azure 上支持此功能。在这个版本中，在创建机器前从 Azure API 检索所需的实例类型信息，以便机器控制器可以使用新的和更新实例类型创建机器。在这个版本中，还适用于将来添加的任何实例类型。(BZ#2108647)
  • 在以前的版本中，在使用 Cluster API 供应商时，集群自动扩展不会考虑 CSI 驱动程序的 AWS、IBM Cloud 和 Alibaba Cloud 拓扑标签。因此，当在横向扩展事件期间尝试平衡节点时，自动扩展不会正确处理带有拓扑标签的节点。在这个版本中，自动扩展的自定义处理器被更新，以便遵循该标签。自动缩放器现在可以平衡由 AWS、IBM Cloud 或 Alibaba CSI 标签标记的类似节点组。(BZ#2001027)
  • 在以前的版本中，Power VS 云供应商无法从 DHCP 服务器获取机器 IP 地址。更改 IP 地址不会更新节点，这会导致一些不一致，如待处理的证书签名请求。在这个版本中，Power VS 云提供商被更新为从 DHCP 服务器获取机器 IP 地址，以便节点的 IP 地址与计算机 IP 地址一致。(BZ#2111474)
  • 在以前的版本中，无法在带有无效配置的 OpenShift Container Platform 早期版本中创建的机器被删除。在这个版本中，防止创建带有无效配置的机器的 Webhook 不再阻止删除现有的无效机器。现在，用户可以通过在这些机器上手动删除终结器来成功从其集群中删除这些机器。(BZ#2101736)
  • 在以前的版本中，由 NetworkManager 不作为守护进程或连续模式运行导致的 DHCP 租期时间短短，从而导致机器在初始置备过程中卡住，永远不会成为集群中的节点。在这个版本中，会添加额外的检查，以便在机器处于这个状态下，它会被自动删除并自动重新创建。从 Machine API 控制器重启后，受此网络状况影响的机器可能会成为节点。(BZ#2115090)
  • 在以前的版本中，当使用 IBM Cloud 中不存在的机器配置集创建新 Machine 资源时，机器会停留在 Provisioning 阶段。在这个版本中，验证被添加到 IBM Cloud Machine API 供应商中，以确保机器配置集存在，机器 API 会拒绝具有无效机器配置集的机器。(BZ#2062579)
  • 在以前的版本中，AWS 的 Machine API 供应商不会验证机器规格中定义的安全组是否存在。本例中不使用返回错误，而是使用默认的安全组，它不应该用于 OpenShift Container Platform 机器，并在不通知用户使用默认组的情况下成功创建机器。在这个版本中，当用户在机器规格中设置不正确或空安全组名称时，Machine API 会返回错误。(BZ#2060068)
  • 在以前的版本中，Machine API 供应商 Azure 不会将实例类型的用户提供值视为区分大小写。当实例类型正确但与问题单不匹配时，这会导致误报错误。在这个版本中，实例类型转换为小写字符，以便用户获得正确的结果，而不会为不匹配的情况产生假错误。(BZ#2085390)
  • 在以前的版本中，在尝试访问对象前，机器对象的注解中没有检查 nil 值。这种情况罕见，但在协调机器时会导致机器控制器 panic。在这个版本中，会检查 nil 值，机器控制器可以在没有注解的情况下协调机器。(BZ#2106733)
  • 在以前的版本中，集群 CPU 和内存用量的集群自动扩展指标永远不会达到或超过 ClusterAutoscaler 资源设定的限制。因此，因为资源限制，当集群自动扩展无法扩展时，不会触发警报。在这个版本中，向集群自动扩展添加了一个名为 cluster_autoscaler_skipped_scale_events_count 的新指标，以便更准确地检测达到或超过资源限值。现在，当集群自动扩展无法扩展集群时，警报将触发，因为它已达到集群资源限制。(BZ#1997396)
  • 在以前的版本中，当 Machine API 供应商无法获取机器 IP 地址时，它不会设置内部 DNS 名称，机器证书签名请求不会被自动批准。在这个版本中，Power VS 计算机提供程序被更新，将服务器名称设置为内部 DNS 名称，即使它无法获取 IP 地址。(BZ#2111467)
  • 在以前的版本中，Machine API vSphere 机器控制器在克隆虚拟机时设置 PowerOn 标志。这会创建一个 PowerOn 任务，表示机器控制器不知道。如果该 PowerOn 任务失败，机器会一直处于 Provisioned 阶段，但永远不会处于开机状态。在这个版本中，克隆序列会被修改以避免出现这个问题。另外，机器控制器现在在失败时重试打开，并正确报告失败。(BZ#2087981, OCPBUGS-954)
  • 在这个版本中，AWS 安全组会在创建后立即标记，而不是在创建后标记。这意味着向 AWS 发送较少的请求，所需的用户权限会降低。(BZ#2098054, OCPBUGS-3094)
  • 在以前的版本中，如果在身份验证失败后尝试某些 RHOSP 操作，RHOSP 传统云供应商中的一个错误会导致崩溃。例如，关闭服务器会导致 Kubernetes 控制器管理器从 RHOSP 获取触发此错误的服务器信息。因此，如果初始云身份验证失败或者配置不正确，则关闭服务器会导致 Kubernetes 控制器管理器崩溃。在这个版本中，RHOSP 旧云供应商被更新为不会尝试任何 RHOSP API 调用（如果之前没有成功身份验证）。现在，关闭带有无效云凭证的服务器不再会导致 Kubernetes 控制器管理器崩溃。(BZ#2102383)
开发人员控制台
  • 在以前的版本中，openshift-config 命名空间对 HelmChartRepository 自定义资源进行了硬编码，它是 ProjectHelmChartRepository 自定义资源的同一命名空间。这导致用户无法在其所需命名空间中添加私有 ProjectHelmChartRepository 自定义资源。因此，用户无法访问 openshift-config 命名空间中的 secret 和 configmap。在这个版本中修复了带有 namespace 字段的 ProjectHelmChartRepository 自定义资源定义，该字段可通过具有正确权限的用户从所选命名空间中读取 secret 和 configmap。另外，用户可以将 secret 和 configmap 添加到可访问的命名空间中，他们可以在使用创建资源的命名空间中添加私有 Helm Chart 仓库。(BZ#2071792)
镜像 Registry
  • 在以前的版本中，镜像触发器控制器没有更改对象的权限。因此，镜像触发器注解无法在某些资源上工作。在这个版本中，会创建一个集群角色绑定，为控制器提供根据注解更新对象所需的权限。(BZ#2055620)
  • 在以前的版本中，Image Registry Operator 对于 node-ca 守护进程集没有 progressing 条件，并使用来自一个不正确对象的 generation。因此，在 Operator 仍在运行时，node-ca 守护进程集可能会被标记为 degraded。在这个版本中添加了 progressing 条件，这表示安装没有完成。因此，Image Registry Operator 可以成功安装 node-ca 守护进程集，安装程序会等待它被完全部署。([BZ#2093440)
安装程序
  • 在以前的版本中，支持的用户定义的标签数量是 8，保留的 OpenShift Container Platform 标签是 2 个用于 AWS 资源。在这个版本中，支持的用户定义标签的数量是 25，对于 AWS 资源，保留的 OpenShift Container Platform 标签为 25。现在，您可以在安装过程中最多添加 25 个用户标签。(CFE#592)
  • 在以前的版本中，在 Amazon Web Services 上安装集群启动，然后在 IAM 管理用户没有分配 s3:GetBucketPolicy 权限时失败。在这个版本中，将此策略添加到清单中，安装程序用来确保分配了所有所需的权限。现在，安装程序会停止安装，并显示 IAM 管理用户缺少 s3:GetBucketPolicy 权限的警告。(BZ#2109388)
  • 在以前的版本中，当 Azure DCasv5-series 或 DCadsv5-series 指定为 control plane 节点时，在 Microsoft Azure 上安装集群会失败。在这个版本中，安装程序会停止带有错误的安装，这代表 secret 虚拟机还不被支持。(BZ#2055247)
  • 在以前的版本中，在 control plane 机器运行前，无法收集 bootstrap 日志。在这个版本中，收集 bootstrap 日志只需要 bootstrap 机器可用即可。(BZ#2105341)
  • 在以前的版本中，如果因为服务帐户的权限不足而无法在 Google Cloud Platform 上安装，则生成的错误消息不在失败原因中提及这个问题。在这个版本中，错误消息进行了改进，它指示用户检查分配给服务帐户的权限。(BZ#2103236)
  • 在以前的版本中，当 Google Cloud provider (GCP)上安装因为指定了无效的 GCP 区域时，生成的错误消息不会在失败原因中提及这个问题。这个版本改进了错误消息，它现在指出区域无效。(BZ#2102324)
  • 在以前的版本中，如果 Hive 使用旧版本的 install-config.yaml 文件，使用 Hive 的集群安装可能会失败。在这个版本中，安装程序可以接受 Hive 提供的 install-config.yaml 文件的旧版本。(BZ#2098299)
  • 在以前的版本中，如果 apiVIP 和 ingressVIP 参数以不同方式表示地址，则安装程序会错误地允许 apiVIP 和 ingressVIP 参数使用相同的 IPv6 地址，如以缩写格式列出地址。在这个版本中，无论格式是什么，安装程序可以正确地验证这两个参数，每个参数都需要单独的 IP 地址。(BZ#2103144)
  • 在以前的版本中，如果集群名称超过 22 个字符，使用安装程序卸载集群将无法删除在 GCP 上安装的集群中的所有资源。在这个版本中，使用安装程序卸载集群会在长时间集群名称的情况下正确找到并删除所有 GCP 集群资源。(BZ#2076646)
  • 在以前的版本中，当在带有 machineNetwork 参数中定义的多个网络的 Red Hat OpenStack Platform (RHOSP) 上安装集群时，安装程序只为第一个网络创建安全组规则。在这个版本中，安装程序会为 machineNetwork 中定义的所有网络创建安全组规则，以便用户在安装后不再需要手动编辑安全组规则。(BZ#2095323)
  • 在以前的版本中，用户可以在 OpenStack 上安装集群时手动将 API 和 Ingress 虚拟 IP 地址设置为与 DHCP 服务器的分配池冲突的值。这可能导致 DHCP 服务器为新机器分配其中一个 VIP 地址，这无法启动。在这个版本中，安装程序会验证用户提供的 VIP 地址，以确保它们不会与任何 DHCP 池冲突。(BZ#1944365)
  • 在以前的版本中，当使用嵌入在文件夹中的数据中心在 vSphere 上安装集群时，安装程序无法找到数据中心对象，从而导致安装失败。在这个版本中，安装程序可以遍历包含 datacenter 对象的目录，以便安装可以成功。(BZ#2097691)
  • 在以前的版本中，当使用带有安装程序置备的基础架构的 arm64 架构在 Azure 上安装集群时，hyperVGeneration V1 的镜像定义资源会错误地具有 x64 的架构值。在这个版本中，hyperVGeneration V1 的镜像定义资源具有 Arm64 的正确架构值。(OCPBUGS-3639)
  • 在以前的版本中，当在 VMware vSphere 上安装集群时，如果用户在 install-config.yaml 文件的 failureDomain 部分中指定了用户定义的文件夹，则安装可能会失败。在这个版本中，安装程序会在 install-config.yaml 文件的 failureDomain 部分中正确验证用户定义的文件夹。(OCPBUGS-3343)
  • 在以前的版本中，当在 VMware vSphere 上安装失败后销毁部分部署的集群时，一些虚拟机文件夹不会被销毁。这个错误可能会在使用多个 vSphere 数据中心或多个 vSphere 集群配置的集群中发生。在这个版本中，在安装失败后销毁部分部署的集群时，所有安装程序置备的基础架构都会被正确删除。(OCPBUGS-1489)
  • 在以前的版本中，当在 VMware vSphere 上安装集群时，如果用户指定了 platform.vsphere.vcenters 参数，则安装会失败，但没有在 install-config.yaml 文件中指定 platform.vsphere.failureDomains.topology.networks 参数。在这个版本中，安装程序会在指定 platform.vsphere.vcenters 时警告用户，在指定 platform.vsphere.vcenters 时需要 platform.vsphere.failureDomains.topology.networks 字段。(OCPBUGS-1698)
  • 在以前的版本中，当在 VMware vSphere 上安装集群时，如果用户定义了 platform.vsphere.vcenters 和 platform.vsphere.failureDomains 参数，则安装会失败，但没有定义 platform.vsphere.defaultMachinePlatform.zones 或 compute.platform.vsphere.zones 和 controlPlane.platform.vsphere.zones。在这个版本中，安装程序会验证用户在安装前在多区域或多区部署中定义了 zones 参数。(OCPBUGS-1490)
Kubernetes Controller Manager
  • 在以前的版本中，Kubernetes Controller Manager Operator 在没有监控堆栈存在的环境中报告 degraded。在这个版本中，Kubernetes Controller Manager Operator 会在监控堆栈不存在时跳过检查监控是否有降级的情况。(BZ#2118286)
  • 在这个版本中，Kubernetes Controller Manager 警告 (KubeControllerManagerDown、PodDisruptionBudgetAtLimit、PodDisruptionBudgetLimit 和 GarbageCollectorSyncFailed) 带有指向 Github runbooks 的链接。runbooks 可帮助用户了解调试这些警报。(BZ#2001409)
Kubernetes 调度程序
  • 在以前的版本中，在删除二级调度程序自定义资源后，二级调度程序部署不会被删除。因此，Second Schedule Operator 和 Operand 没有被完全卸载。在这个版本中，在二级调度程序自定义资源中设置了正确的所有者引用，以便它指向二级调度程序部署。因此，当删除二级调度程序自定义资源时，从属调度程序部署会被删除。(BZ#2100923)
  • 对于 OpenShift Container Platform 4.12 发行版本，descheduler 现在可将事件发布到 API 组，因为发行版本为 descheduler 的配置集添加了额外的基于角色的访问控制 (RBAC) 规则。(OCPBUGS-2330)
Machine Config Operator
  • 在以前的版本中，只有在 Operator 的守护进程同步成功时，才会同步 Machine Config Operator (MCO )包含重要证书的 ControllerConfig 资源。按照设计，守护进程同步期间的未就绪节点阻止守护进程同步成功，因此未就绪的节点间接阻止 ControllerConfig 资源，因此这些证书无法同步。这会导致因为无法轮转 ControllerConfig 资源中包含的证书而出现未就绪节点时集群降级。在这个版本中，ControllerConfig 资源的同步不再依赖于守护进程同步成功，因此如果守护进程同步失败，ControllerConfig 资源现在可以继续同步。这意味着，未就绪节点不再阻止 ControllerConfig 资源同步，因此即使存在未就绪节点，证书也会继续更新。(BZ#2034883)
管理控制台
  • 在以前的版本中，Operator 详情页会尝试显示多个错误消息，但错误消息组件一次只能显示一个错误消息。因此，不会显示相关的错误消息。在这个版本中，Operator 详情页面只显示第一个错误消息，以便用户看到相关错误。(OCPBUGS-3927)
  • 在以前的版本中，Azure Red Hat OpenShift 的产品名在 Customer Case Management (CCM) 中不正确。因此，控制台必须使用相同的不正确的产品名称来正确地填充 CCM 中的字段。更新 CCM 中的产品名称后，还需要更新控制台。在这个版本中，与 CCM 相同的产品名称会在控制台的链接后面使用正确的 Azure 产品名称正确填充。(OCPBUGS-869)
  • 在以前的版本中，当插件页面出现错误时，在离开错误页面时，错误不会被重置，在进入到一个不是造成错误的页面时，错误仍会保留。在这个版本中，当用户进入到新页面时，错误状态将重置为默认值，错误将不再在新页面中被保留。(BZ#2117738, OCPBUGS-523)
  • 在以前的版本中，当选择了 All Namespaces 时，安装的 Operator 的 Operator 详情 栏中的 View it here 链接被错误地构建。因此，在 All Projects 中的集群服务版本（CSV）的 Operator 详情页面的链接是一个无效的路由。在这个版本中，到安装 CVS 的命名空间的 View it here 链接现在会被正确构建，链接可以正常工作。(OCPBUGS-184)
  • 在以前的版本中，带有超过五个数字的行号会导致一个显示问题，行号覆盖了行号和行内容之间的垂直划分器，使得读起来变得更加困难。在这个版本中，行号可用的空间量增加到不再有行号，行号不再覆盖垂直划分器。(OCPBUGS-183)
  • 在以前的版本中，在 Web 控制台的管理员视角中，在 Cluster Settings 页面中的 Default update server 弹出窗口中的 Learn more about the OpenShift local update services 链接会产生 404 错误。在这个版本中，这个链接可以正常工作。(BZ#2098234)
  • 在以前的版本中，MatchExpression 组件没有考虑数组类型值。因此，使用这个组件通过表单只能输入单个值。在这个版本中，MatchExpression 组件接受以逗号分隔的值作为数组。(BZ#207690)
  • 在以前的版本中，对模型进行冗余检查会导致重新载入标签页，偶尔会导致标签页内容被重新渲染。在这个版本中，删除了冗余模型检查，模型只检查一次。因此，标签内容不会波动，不再重新渲染。(BZ#2037329)
  • 在以前的版本中，当从 OpenShift Dedicated 节点页面中的操作列表中选择 edit 标签时，不会请求响应，并返回 Web hook 错误。这个问题已被解决，因此只有在编辑失败时才会返回错误消息。(BZ#2102098)
  • 在以前的版本中，如果问题处于待处理状态，点 Insights 链接会使页面崩溃。作为临时解决方案，您可以在点 Insights 链接前等待变量变为 initialized。因此，Insights 页面会如预期打开。(BZ#2052662)
  • 在以前的版本中，当 MachineConfigPool 资源暂停时，用于取消暂停 Resume rollouts 的选项。现在，信息已被更新，现在为 Resume updates。(BZ#2094240)
  • 在以前的版本中，在计算 master 和 worker 节点时使用了错误的计算方法。在这个版本中，当节点同时具有 master 和 worker 角色时，会计算正确的 worker 节点。(BZ#1951901)
  • 在以前的版本中，ImageManifestVuln 的 react-router 路由冲突会导致尝试呈现带有 ~new 名称的 ImageManifestVuln 的详情页面。现在，容器安全插件已被更新以删除冲突路由，并确保 Operator 详情页面中使用动态列表和详情页面扩展。因此，控制台会显示 ImageManifestVuln 的正确创建、列表和详情页。(BZ#2080260)
  • 在以前的版本中，不完整的 YAML 不会同步。偶尔会向用户显示不完整的 YAML。在这个版本中，同步的 YAML 始终会显示。(BZ#2084453)
  • 在以前的版本中，当安装需要创建自定义资源 (CR) 的 Operator 以供使用时，Create resource 按钮可能无法安装 CR，因为它指向不正确的命名空间。在这个版本中，Create resource 按钮可以正常工作。(BZ#2094502)
  • 在以前的版本中，Cluster update 模态无法正确显示错误。因此，Cluster update 模态在出现错误时不会显示或解释它们。在这个版本中，Cluster update 模态可以正确地显示错误。(BZ#2096350)
监控
  • 在此次更新之前，因为一个调度问题，集群管理员无法区分 pod 未就绪，因为它无法通过 kubelet 启动。在这两种情况下，KubePodNotReady 警报都会触发。在这个版本中，KubePodNotScheduled 警报会在 pod 未就绪时触发，而 KubePodNotReady 警报会在 pod 未就绪时触发，因为 kubelet 无法启动它。(OCPBUGS-4431)
  • 在此次更新之前，node_exporter 将报告有关虚拟网络接口的指标，如 tun 接口、br 接口和 ovn-k8s-mp 接口。在这个版本中，这些虚拟接口的指标将不再收集，这减少了监控资源消耗。(OCPBUGS-1321)
  • 在此次更新之前，Alertmanager pod 启动可能会因为 DNS 解析较慢而超时，Alertmanager pod 不会启动。在这个版本中，超时值增加到七分钟，这可防止 pod 启动超时。(BZ#2083226)
  • 在此次更新之前，如果 Prometheus Operator 运行或调度 Prometheus pod，系统不会提供失败的底层原因。在这个版本中，如果 Prometheus pod 没有运行或调度，Cluster Monitoring Operator 会使用故障原因更新 clusterOperator 监控状态，这可用于排除底层问题。(BZ#2043518)
  • 在此次更新之前，如果您从 OpenShift Container Platform Web 控制台中的 Developer 视角创建了警报静默，则会包括与警报不匹配的外部标签。因此，警报不会被静默。在这个版本中，在 Developer 视角中创建静默时，外部标签会被排除，以便新创建的静默可以正常工作。(BZ#2084504)
  • 在以前的版本中，如果您启用了专用于用户定义的项目的 Alertmanager 实例，在某些情况下可能会出现错误配置，您也不会告知用户定义的项目 Alertmanager 配置映射设置不会加载 Alertmanager 的主实例或专用于用户定义的项目的实例。在这个版本中，如果发生此错误配置，Cluster Monitoring Operator 现在会显示一个信息，告知您问题并提供解决步骤。(BZ#2099939)
  • 在此次更新之前，如果 Cluster Monitoring Operator (CMO)无法更新 Prometheus，CMO 不会验证以前的部署是否在运行，并报告集群监控是否仍在运行，即使其中一个 Prometheus pod 仍在运行。在这个版本中，CMO 检查在这种情况下运行 Prometheus pod，并在没有 Prometheus pod 运行时报告集群监控不可用。(BZ#2039411)
  • 在此次更新之前，如果您将 OpsGenie 配置为警报接收器，日志中会出现 api_key 和 api_key_file 相互排斥的警告，并且 api_key 具有优先权。即使您没有定义 api_key_file，也会出现这个警告。在这个版本中，只有在您定义了 api_key 和 api_key_file 时，这个警告才会出现在日志中。(BZ#2093892)
  • 在此次更新之前，Telemeter Client (TC) 仅在手动重启时载入新的 pull secret。因此，如果 pull secret 已更改或更新，且 TC 尚未重启，则 TC 无法与服务器进行身份验证。在这个版本中解决了这个问题，以便在 secret 被轮转时，部署会自动重启，并使用更新的令牌进行身份验证。(BZ#2114721)
网络
  • 在以前的版本中，处于 terminating 状态的路由器会延迟 oc cp 命令，这会延迟 oc adm must-gather 命令直到 pod 终止为止。在这个版本中，会为每个发出的 oc cp 命令设置一个超时，以防止延迟 must-gather 命令运行。因此，终止 pod 不再延迟 must-gather 命令。(BZ#2103283)
  • 在以前的版本中，Ingress Controller 无法同时配置 Private 端点发布策略类型和 PROXY 协议。在这个版本中，用户可以使用 Private 端点发布策略类型和 PROXY 协议配置 Ingress Controller。(BZ#2104481)
  • 在以前的版本中，routeSelector 参数在路由器部署前清除 Ingress Controller 的路由状态。因此，路由状态会错误地重新填充。为了避免使用过时的数据，路由状态检测已被更新，不再依赖于 Kubernetes 对象缓存。另外，这个更新还包括一个修复，用于检查路由部署时的生成 ID，以确定路由状态。因此，路由状态使用 routeSelector 更新一致清除。(BZ#2101878)
  • 在以前的版本中，从早于 4.8 的 OpenShift Container Platform 版本升级的集群可能会有孤立的 Route 对象。这是因为早期版本的 OpenShift Container Platform 将 Ingress 对象转换为 Route 对象，而与给定 Ingress 对象的指示 IngressClass 无关。在这个版本中，在 Ingress-to-Route 转换后，集群管理员会发送一个有关集群中任何孤立 Route 对象的警报。在这个版本中，添加了另一个警报，通知集群管理员有关没有指定 IngressClass 的 Ingress 对象。(BZ#1962502)
  • 在以前的版本中，如果没有创建路由器部署所依赖的 configmap，则路由器部署不会进行。在这个版本中，如果默认入口控制器部署正在进行，集群 Operator 会报告 ingress progressing=true。这会导致用户使用 oc get co 命令调试 ingress 控制器的问题。(BZ#2066560)
  • 在以前的版本中，当将错误创建的网络策略添加到 OVN-Kubernetes 缓存中时，会导致 OVN-Kubernetes 领导进入 crashloopbackoff 状态。在这个版本中，OVN-Kubernetes 领导不会通过跳过删除 nil 策略来进入 crashloopbackoff 状态。(BZ#2091238)
  • 在以前的版本中，在删除具有相同命名空间或名称的 60 秒内重新创建带有相同命名空间的 EgressIP pod，从而导致配置错误的 SNAT。因此，数据包可能会没有 nodeIP 而不是 EgressIP SNAT。在这个版本中，流量会将 pod 保留为 EgressIP 而不是 nodeIP。(BZ#2097243)。
  • 在以前的版本中，由于 ACL 中的从 arp 到 arp II nd 的更改，会导致带有 arp 的旧的访问控制列表 (ACL) 出现一个 unexpectedly found multiple equivalent ACLs (arp v/s arp||nd) 错误。这导致网络策略被正确创建。在这个版本中，只有 arp 匹配的旧 ACL 已被删除，以便只有带有新的 arp II nd 匹配项的 ACL 才能正确创建网络策略，且不会在 ovnkube-master 上出现错误。注意：这会影响客户从旧版本升级到 4.8.14、4.9.32、4.10.13 或更高版本。(BZ#2095852)。
  • 在这个版本中，CoreDNS 更新至 1.10.0 版本，它基于 Kubernetes 1.25。这会保留 CoreDNS 版本和 OpenShift Container Platform 4.12，它也基于 Kubernetes 1.25，并与另一个版本保持一致。(OCPBUGS-1731)
  • 在这个版本中，OpenShift Container Platform 路由器使用 k8s.io/client-go 版本 1.25.2，它支持 Kubernetes 1.25。这会保留 openshift-router 和 OpenShift Container Platform 4.12，它也基于 Kubernetes 1.25，并相互保持一致。(OCPBUGS-1730)
  • 在这个版本中，Ingress Operator 使用 k8s.io/client-go 版本 1.25.2，它支持 Kubernetes 1.25。这会保留 Ingress Operator 和 OpenShift Container Platform 4.12，它也基于 Kubernetes 1.25，并相互保持一致。(OCPBUGS-1554)
  • 在以前的版本中，DNS Operator 不会协调 openshift-dns 命名空间。由于 OpenShift Container Platform 4.12 需要 openshift-dns 命名空间具有 pod-security 标签，这会导致在集群更新时缺少命名空间。如果没有 pod-security 标签，pod 无法启动。在这个版本中，DNS Operator 会协调 openshift-dns 命名空间，现在 pod-security 标签存在。因此，pod 会如预期启动。(OCPBUGS-1549)
  • 在以前的版本中，ingresscontroller.spec.tuniningOptions.reloadInterval 不支持十进制数字作为有效的参数值，因为 Ingress Operator 内部将指定的值转换为毫秒，这是不被支持的时间单位。这导致 Ingress Controller 被删除。在这个版本中，ingresscontroller.spec.tuningOptions.reloadInterval 现在支持十进制数字，用户可以删除之前不支持的带有 reloadInterval 参数值的 Ingress Controller。(OCPBUGS-236)
  • 在以前的版本中，Cluster DNS Operator 使用基于 Kubernetes 1.24 的 GO Kubernetes 库，而 OpenShift Container Platform 4.12 基于 Kubernetes 1.25。在这个版本中，GO Kubernetes API 是 v1.25.2，它将 Cluster DNS Operator 与使用 Kubernetes 1.25 API 的 OpenShift Container Platform 4.12 保持一致。（链接： OCPBUGS-1558）
  • 在以前的版本中，当重新创建 network-operator pod 时，将 disableNetworkDiagnostics 配置设置为 true 不会被持久保留。在这个版本中，网络 operator.openshift.io/cluster 的 disableNetworkDiagnostics 配置属性在 network operator 重启后不再重置为默认值。(OCPBUGS-392)
  • 在以前的版本中，ovn-kubernetes 没有在 br-ex 网桥中配置绑定接口的正确 MAC 地址。因此，对主 Kubernetes 接口使用绑定的节点无法加入集群。在这个版本中，ovn-kubernetes 配置 br-ex 网桥中绑定接口的正确 MAC 地址，并为主 Kubernetes 接口使用绑定的节点成功加入集群。(BZ2096413)
  • 在以前的版本中，当 Ingress Operator 配置为启用 mTLS 时，Operator 不会检查 CRL 是否需要更新，直到有些其他事件导致它协调。因此，用于 mTLS 的 CRL 可能已过时。在这个版本中，Ingress Operator 会在任何 CRL 过期时自动协调，并在其 nextUpdate 字段指定的时间更新 CRL。(BZ#2117524)
节点
  • 在以前的版本中，符号链接错误消息被输出为原始数据，而不是将其格式化为错误，因此很难理解。在这个版本中，错误消息被正确格式化，以便可以轻松地理解。(BZ#1977660)
  • 在以前的版本中，当将性能配置集应用到节点时，kubelet 硬驱除阈值与 Kubernetes 默认值不同。在这个版本中，默认值已更新，以匹配预期的 Kubernetes 默认值。(OCPBUGS-4362)。
OpenShift CLI (oc)
  • 当目标命名空间缺少适当的安全级别时，OpenShift Container Platform 4.12 发行版本解决了在目标节点上输入 debug 会话的问题。这会导致 oc CLI 提示您输入 pod 安全错误消息。如果现有命名空间不包含适当的安全级别，OpenShift Container Platform 现在会在目标节点上进入 oc debug 模式时创建一个临时命名空间。(OCPBUGS-852)
  • 在以前的版本中，在 macOS arm64 架构中，需要手动签名 oc 二进制文件。因此，oc 二进制文件无法按预期工作。在这个版本中，实现了一个自签发的二进制，用于对应 oc。因此，macOS arm64 构架中的 oc 二进制文件可以正常工作。(BZ#2059125)
  • 在以前的版本中，must-gather 会尝试收集服务器上不存在的资源。因此，must-gather 会输出错误信息。现在，在收集资源前，must-gather 会检查资源是否存在。因此，当在服务器中收集不存在的资源时，must-gather 不再打印错误。(BZ#2095708)
  • OpenShift Container Platform 4.12 发行版本更新了 oc-mirror 库，以便库可以支持多架构平台镜像。这意味着，在镜像一个平台发行有效负载时，您可以从更广泛的架构中进行选择，如 arm64。(OCPBUGS-617)
Operator Lifecycle Manager (OLM)
  • 在 OpenShift Container Platform 4.12 版本前，package-server-manager 控制器不会恢复对 package-server 集群服务版本(CSV) 所做的任何更改，因为 on-cluster 功能存在问题。这些持久性更改可能会影响 Operator 在集群中启动的方式。对于 OpenShift Container Platform 4.12，package-server-manager 控制器始终将 package-server CSV 重建到其原始状态，因此在集群升级操作后，对 CSV 的修改不会保留。on-cluster 功能不再控制 package-server CSV 的状态。(OCPBUGS-867)
  • 在以前的版本中，Operator Lifecycle Manager (OLM)会尝试更新命名空间以应用标签，即使命名空间中存在该标签。因此，更新请求会增加 API 和 etcd 服务的工作负载。在这个版本中，OLM 在发布更新前将现有标签与命名空间中预期的标签进行比较。因此，OLM 不再尝试对命名空间进行不必要的更新请求。(BZ#2105045)
  • 在以前的版本中，Operator Lifecycle Manager (OLM) 可防止因 ClusterVersion 自定义资源的 spec.DesiredVersion 字段错误地计算不应阻断的次版本集群升级。在这个版本中，当应该支持升级时，OLM 不再阻止集群升级。(BZ#2097557)
  • 在以前的版本中，协调器会在不生成资源副本的情况下更新资源的注解。这会导致一个终止协调器进程的错误。在这个版本中，协调器不再因为错误而停止。(BZ#2105045)
  • package-server-manifest (PSM) 是一个控制器，可确保在集群中安装正确的 package-server Cluster Service Version (CSV)。在以前的版本中，因为在协调功能中存在一个逻辑错误 (on-cluster 对象可能会影响预期的对象)，所以对 package-server CSV 的更改没有被恢复。用户可能会对 package-server CSV 进行了修改，这些修改不会被恢复。另外，集群升级不会更新 package-server CSV 的 YAML。在这个版本中，预期的 CSV 版本总是从头开始构建，这删除了 on-cluster 对象对预期值的影响。因此，PSM 现在会恢复对 package-server CSV 的任何修改尝试，集群升级现在会部署预期的 package-server CSV。(OCPBUGS-858)
  • 在以前的版本中，OLM 会根据 Operator 的 CRD 状态升级 Operator。CRD 根据 group/version/kind (GVK) 标识符定义的顺序列出组件引用。共享同一组件的 Operator 可能会导致 GVK 更改 Operator 的组件列表，这会导致 OLM 需要更多系统资源来持续更新 CRD 的状态。在这个版本中，Operator Lifecycle Manager (OLM) 会根据 Operator 组件引用升级 Operator。对 Operator 的自定义资源定义(CRD) 状态的更改不会影响 OLM Operator 升级过程。(OCPBUGS-3795)
Operator SDK
  • 在这个版本中，您可以通过在 pod 规格中包含 securityContext 配置字段来为 registry pod 设置安全上下文。这将为 pod 中的所有容器应用安全上下文。securityContext 字段还定义 pod 的权限。(BZ#2091864)
File Integrity Operator
  • 在以前的版本中，File Integrity Operator 使用 Operator 权限中的 openshift-file-integrity 命名空间部署模板。当 Operator 试图在命名空间中创建对象时，因为权限问题会失败。在这个版本中，OLM 使用的部署资源被更新为使用正确的命名空间，修复权限问题，以便用户可以在非默认命名空间中安装和使用 Operator。(BZ#2104897)
  • 在以前的版本中，File Integrity Operator 的底层依赖项改变了警报和通知是如何处理的，Operator 不会发送指标。在这个版本中，Operator 确保指标端点正确，并在启动时可访问。(BZ#2115821)
  • 在以前的版本中，File Integrity Operator 发布的警报没有设置命名空间。这使得用户难以了解警报来自哪里，或者负责发出该警报的组件。在这个版本中，Operator 会在警报中包含它安装到的命名空间，以便更轻松地缩小组件需要注意的内容。(BZ#2101393)
  • 在以前的版本中，File Integrity Operator 在升级过程中无法正确处理修改警报。因此，警报不包括安装 Operator 的命名空间。在这个版本中，Operator 会在警报中包含它安装到的命名空间，以便更轻松地缩小组件需要注意的内容。(BZ#2112394)
  • 在以前的版本中，因为底层 OLM 更新导致 File Integrity Operator 的服务帐户所有权，从 0.1.24 到 0.1.29 的更新无法正常工作。在这个版本中，Operator 默认为升级到 0.1.30。(BZ#2109153)
  • 在以前的版本中，File Integrity Operator 守护进程使用 ClusterRoles 参数而不是 Roles 参数进行最新的权限更改。因此，OLM 无法更新 Operator。在这个版本中，Operator 守护进程会恢复到使用 Roles 参数，并从旧版本更新到 0.1.29 版本。(BZ#2108475)
Compliance Operator
  • 在以前的版本中，Compliance Operator 使用 Operator SDK 的旧版本，这是构建 Operator 的依赖项。这会导致 Operator SDK 使用的已弃用 Kubernetes 功能的警报。在这个版本中，Compliance Operator 更新至 0.1.55 版本，其中包括 Operator SDK 的更新版本。(BZ#2098581)
  • 在以前的版本中，为 rhcos4-high-master-sysctl-kernel-yama-ptrace-scope 和 rhcos4-sysctl-kernel-core-pattern 规则应用自动补救会导致后续这些规则失败，即使它们已被修复。这个版本解决了这个问题。(BZ#2094382)
  • 在以前的版本中，Compliance Operator 硬编码通知到 default 命名空间。因此，如果 Operator 安装在不同的命名空间中，则不会出现来自 Operator 的通知。这个版本解决了这个问题。(BZ#2060726)
  • 在以前的版本中，当在没有 Ignition 规格的情况下解析机器配置时，Compliance Operator 无法获取 API 资源。这会导致 api-check-pods 检查崩溃循环。在这个版本中，Compliance Operator 被更新为在没有 Ignition 规格的情况下安全地处理机器配置池。(BZ#2117268)
  • 在以前的版本中，Compliance Operator 将机器配置处于卡住状态，因为它无法决定机器配置和 kubelet 配置之间的关系。这是因为机器配置名称的假设不正确。在这个版本中，Compliance Operator 可以确定 kubelet 配置是否是机器配置的一个子集。(BZ#2102511)
OpenShift API 服务器
  • 在以前的版本中，添加成员可能会从组中删除以前的成员。因此，用户会丢失组特权。在这个版本中，依赖项已被禁止，用户不再丢失组特权。(OCPBUGS-533)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • 在以前的版本中，升级到 Podman 4.0 会阻止用户使用 RHCOS 上带有 toolbox 容器的自定义镜像。在这个版本中更新了 toolbox 库代码来考虑新的 Podman 行为，因此用户现在可以按预期使用带有 toolbox 的自定义镜像。(BZ#2048789)
  • 在以前的版本中，podman exec 命令无法与嵌套容器正常工作。用户在使用 oc debug 命令访问节点时遇到这个问题，然后使用 toolbox 命令运行容器。因此，用户无法在 RHCOS 上重复使用 toolbox。在这个版本中更新了 toolbox 库代码来考虑此行为，因此用户现在可以在 RHCOS 上重复使用 toolboxes。(BZ#1915537)
  • 在这个版本中，运行 toolbox 命令会在启动容器前检查默认镜像的更新。这提高了安全性，并为用户提供最新的程序错误修复。(BZ#2049591)
  • 在以前的版本中，升级到 Podman 4.0 会阻止用户在 RHCOS 上运行 toolbox 命令。在这个版本中更新了 toolbox 库代码来考虑新的 Podman 行为，因此用户现在可以按预期在 RHCOS 上运行 toolbox。(BZ#2093040)
  • 在以前的版本中，rpm-ostree 不支持自定义 SELinux 策略模块，因此不会在更新后与系统的其余部分一起更新。这在不相关的组件中可能会出现故障。待处理的 SELinux 用户空间的改进将包括在以后的 OpenShift Container Platform 版本中，在这个版本中，为 RHCOS 提供了一个临时解决方案，它将根据需要在引导时重建和重新载入 SELinux 策略。(OCPBUGS-595)
可伸缩性和性能
  • tuned 配置集已被修改，会为在当前的 Red Hat Enterprise Linux (RHEL) 内核补丁中新添加的、针对每个特定 CPU 的 kthreads (ktimers) 分配相同的优先级作为 ksoftirqd 和 rcuc。如需更多信息，请参阅 OCPBUGS-3475, BZ#2117780 和 BZ#2122220。
  • 在以前的版本中，重启 tuned 服务会导致 irqbalance 配置不正确，从而导致在隔离的 CPU 上再次提供 IRQ 操作，从而违反隔离保证。在这个版本中，irqbalance 服务配置会在 tuned 服务重启后（因为被明确请求或因为错误）被正确保留，因此保留的 CPU 隔离保证会满足 IRQ 服务。(OCPBUGS-585)
  • 在以前的版本中，当 tuned 守护进程因为 Cluster Node Tuning Operator 的一部分而重启时，会重置中断处理程序的 CPU 关联性，并导致调优被破坏。在这个版本中，tuned 中的 irqbalance 插件被禁用，OpenShift Container Platform 现在依赖于 CRI-O 和 irqbalance 间的逻辑和交互。(BZ#2105123）
  • 在以前的版本中，当节点有负载时，为每个新的 veth 设备所执行的低延迟 hook 脚本用时过长。这会在 pod 启动事件期间累积延迟，从而导致 kube-apiserver 的推出部署时间较慢，有时会超过 5 分钟的推出部署的超时设置。在这个版本中，容器启动时间应该会比较短且在 5 分钟阈值中。(BZ#2109965)。
  • 在以前的版本中，oslat 控制线程与其中一个测试线程共存，这会导致测量的延迟激增。在这个版本中，oslat 运行程序为控制线程保留一个 CPU，这意味着测试使用较少的 CPU 来运行忙碌的线程。(BZ#2051443)
  • 延迟测量工具（也称为 oslat、cyclictest 和 hwlatdetect ）现在在完全隔离的 CPU 上运行，且没有在后台运行 helper 进程（这会而导致延迟激增），从而提供了更准确的延迟测量。(OCPBUGS-2618)
  • 在以前的版本中，虽然 group-du-sno-ranGen.yaml 的引用 PolicyGenTemplate 包含了两个 StorageClass 条目，但生成的策略仅包含一个。在这个版本中，生成的策略包括这两个策略。(BZ#2049306)。
Storage
  • 在以前的版本中，检查通用临时卷会失败。在这个版本中，检查可扩展卷现在包括通用临时卷。(BZ#2082773)
  • 在以前的版本中，如果 vSphere 有多个 secret，vSphere CSI Operator 会随机选择一个 secret，并有时会导致 Operator 重启。在这个版本中，当 vCenter CSI Operator 中有多个 secret 时会出现一个警告。(BZ#2108473)
  • 在以前的版本中，当 Container Storage Interface (CSI) 驱动程序无法从节点卸载卷时，OpenShift Container Platform 会分离卷。CSI 规格不允许在不卸载的情况下分离卷，驱动可能会进入 undocumented 状态。在这个版本中，CSI 驱动程序仅在不健康节点上卸载前被分离，从而防止出现 undocumented 的状态。(BZ#2049306)
  • 在以前的版本中，Manila CSI Driver Operator 的 VolumeSnapshotClass 缺少注解。因此，Manila CSI 快照无法找到 secret，无法使用默认 VolumeSnapshotClass 创建快照。在这个版本中解决了这个问题，secret 名称和命名空间包含在默认的 VolumeSnapshotClass 中。现在，用户可以使用默认的 VolumeSnapshotClass 在 Manila CSI Driver Operator 中创建快照。(BZ#2057637)

  • 用户现在可以选择在 Azure File 上使用实验性 VHD 功能。要选择它，用户必须在存储类中指定 fstype 参数，并使用 --enable-vhd=true 启用它。如果使用 fstype，且功能没有设为 true，则卷将无法置备。

    要不使用 VHD 功能，请从存储类中删除 fstype 参数。(BZ#2080449)

  • 在以前的版本中，如果 vSphere 有多个 secret，vSphere CSI Operator 会随机选择一个 secret，并有时会导致 Operator 重启。在这个版本中，当 vCenter CSI Operator 中有多个 secret 时会出现一个警告。(BZ#2108473)
Web 控制台 (开发者视角)
  • 在以前的版本中，用户无法在添加和编辑表单中取消选择 Git secret。因此，必须重新创建资源。在这个版本中，添加选项以在所选 secret 选项列表中选择 No Secret 解决了这个问题。因此，用户可以轻松选择、取消选择或分离任何附加的 secret。(BZ#2089221)
  • 在 OpenShift Container Platform 4.9 中，当开发者视角中只有非常少的数据或没有数据，大多数监控图表 (CPU 消耗、内存用量和带宽) 会显示 -1 到 1 范围内的数据。但是这些值都不能低于零。这将在以后的发行版本中解决。(BZ#1904106)
  • 在此次更新之前，当部署用户定义的 Alertmanager 服务时，用户无法在 OpenShift Container Platform Web 控制台的开发者视角中静默警报，因为 Web 控制台会将请求转发到 openshift-monitoring 命名空间中的平台 Alertmanager 服务。在这个版本中，当您在 web 控制台中查看 Developer 视角并尝试静默警报时，请求会被转发到正确的 Alertmanager 服务。(OCPBUGS-1789)
  • 在以前的版本中，Add Helm Chart Repositories 表单中有一个已知问题来扩展项目的 Developer Catalog。Quick Start 指南显示您可以在所需命名空间中添加 ProjectHelmChartRepository CR，但没有提到需要从 kubeadmin 执行这个权限。这个问题已解决，现在 Quickstart 提到了创建 ProjectHelmChartRepository CR 的正确步骤。(BZ#2057306)