1.6. 程序错误修复
裸机硬件置备
-
在以前的版本中,当将 provisioning 网络从
Disabled
切换到Managed
时,不支持使用 MAC 地址配置置备网络接口。在这个版本中,provisioningMacAddresses
字段被添加到provisioning.metal3.io
CRD 中。使用此字段通过其 MAC 地址而不是其名称来标识 provisioning 网络接口。(BZ#2000081) -
在以前的版本中,Ironic 无法为置备 SuperMicro X11/X12 服务器附加虚拟介质镜像,因为这些模型需要非标准设备字符串,如
UsbCd
,用于基于 CD 的虚拟介质。在这个版本中,置备会覆盖在基于 CD 的虚拟介质置备的 SuperMicro 机器上的UsbCd
。(BZ#2009555) -
在以前的版本中,Ironic 无法将虚拟介质镜像附加到 SuperMicro X11/X12 服务器上,因为这些机器的 BMC 上有限制地验证。在这个版本中,如果虚拟介质镜像由本地文件支持,
filename
参数已从 URL 中删除。因此,如果镜像由对象存储支持,则参数仍会被传递。(BZ#2011626) -
在以前的版本中,机器下载器镜像使用的
curl
工具不支持带有no_proxy
的无类别域间路由(CIDR)。因此,在下载 Red Hat Enterprise Linux CoreOS(RHCOS)镜像时,任何noProxy 中的 CIDR 都会被忽略。在这个版本中,代理会在适当的时候调用curl
之前从环境中删除。因此,下载机器镜像时,no_proxy
中的任何 CIDR 不再被忽略。(BZ#1990556) - 在以前的版本中,观察了基于 OpenShift Container Platform 的虚拟介质部署,以便在 iDRAC 硬件类型中间歇性失败。当未完成的 Lifecycle Controller 任务与虚拟介质配置请求分离时会出现这种情况。在这个版本中,在部署前注册 iDRAC 硬件时清除任何生命周期控制器作业来解决虚拟介质部署失败。(BZ#1988879)
-
在以前的版本中,用户需要在安装配置文件中输入较长形式的 IPv6 地址,如
2001:0db8:85a3:0000:0000:8a2e:0370:7334
。Ironic 无法找到与这个 IP 地址匹配的接口,从而导致安装失败。在这个版本中,用户提供的 IPv6 地址转换为简短的表单地址,例如2001:db8:85a3::8a2e:370:7334
。现在,安装可以成功。(BZ#2010698) - 在此次更新之前,当 Redfish 系统具有 Settings URI 时,Ironic 置备服务总是尝试使用此 URI 来更改引导相关的 BIOS 设置。但是,如果 Baseboard Management Controller (BMC) 带有 Settings URI,但不支持使用此设置 URI 更改特定的 BIOS 设置,裸机置备会失败。在 OpenShift Container Platform 4.10 及更高版本中,如果系统具有 Settings URI,Ironic 会在继续操作前使用 Settings URI 来验证它是否可以更改特定的 BIOS 设置。否则,Ironic 使用 System URI 实现更改。此额外逻辑可确保 Ironic 可以应用与引导相关的 BIOS 设置更改,裸机置备可以成功。(OCPBUGS-6886)
Builds
在此次更新之前,如果您创建了包含 OpenShift Container Platform 4.7.x 或更早版本镜像更改触发器的构建配置,则镜像更改触发器可能会持续触发构建。
出现这个问题的原因是,在构建 BuildConfig spec 的
BuildConfig
spec 中弃用和删除lastTriggeredImageID
字段时,镜像更改会触发控制器在实例化构建前停止检查该字段。OpenShift Container Platform 4.8 在状态中引入了新字段,需要检查更改触发器控制器,但实际上并没有检查。在这个版本中,镜像更改触发器控制器会持续检查最近触发的镜像 ID 的 spec 和状态中的正确字段。现在,它仅在需要时触发构建。(BZ#2004203)
- 在此次更新之前,Builds 中的镜像引用需要明确指定红帽 registry 名称。在这个版本中,如果镜像引用不包含 registry,则 Build 会搜索 Red Hat registry 和其他已知 registry 以查找镜像。(BZ#2011293)
Jenkins
-
在此次更新之前,当 Jenkins 通知与 OpenShift Jenkins 管道构建策略配置关联的新作业时,OpenShift Jenkins 同步插件版本 1.0.48 会有一个
NullPointerException
错误。最终,这个错误是良性的,因为没有BuildConfig
对象与传入的 Jenkins 任务关联。核心 Jenkins 忽略了我们的插件中的异常并移到下一个监听器。但是,在 Jenkins 日志中会显示大量的堆栈跟踪信息,这会干扰用户找到需要的信息。在这个版本中,插件通过进行正确的检查来避免这个错误和后续的堆栈追踪来解决这个问题。(BZ#2030692) 在此次更新之前,OpenShift Sync Jenkins 插件的版本 1.0.48 中的性能会错误地指定用于映射到 Jenkins Kubernetes 插件 Pod 模板的
ConfigMap
和ImageStream
对象的标签。因此,插件不再从带有jenkins-agent
标签的ConfigMap
和ImageStream
对象中导入 pod 模板。在这个版本中,修正了接受的标签规格,以便插件从具有
jenkins-agent
标签的ConfigMap
和ImageStream
对象中导入 pod 模板。(2034839)
Cloud Compute
- 在以前的版本中,在 Red Hat OpenStack Platform(RHOSP)上编辑机器规格会导致 OpenShift Container Platform 尝试删除并重新创建机器。因此,这会导致它所托管的节点造成不可恢复的丢失。在这个版本中,创建后对机器规格所做的任何编辑都会被忽略。(BZ#1962066)
- 在以前的版本中,在 Red Hat OpenStack Platform(RHOSP)上运行的集群上,机器对象不会报告浮动 IP 地址。因此,kubelet 创建的证书签名请求(CSR)没有被接受,从而导致节点无法加入集群。现在,为机器对象报告所有 IP 地址。(BZ#2022627)
- 以前的版本中,用于确保 AWS 机器在重新排队列前没有被更新的检查被删除。因此,当 AWS 虚拟机被删除时,但其对象仍然可用时,就可能出现问题。如果发生这种情况,AWS 机器将在无限循环中重新排队,且无法删除或更新。在这个版本中,恢复了用来确保 AWS 机器在重新排队前没有被更新的检查。因此,如果机器已经更新,机器将不再重新排序。(BZ#2007802)
- 在以前的版本中,修改选择器会改变机器集观察的机器列表。因此,可能会出现泄漏问题,因为机器集丢失了它已经创建的机器。此更新可确保创建后选择器不可变。因此,机器集现在会列出正确的机器。(BZ#2005052)
-
在以前的版本中,如果虚拟机模板有快照,因为
linkedClone
操作使用了不正确的磁盘大小,造成选择不正确的磁盘大小。在这个版本中,所有情况都会将默认克隆操作更改为fullClone
。linkedClone
现在必须由用户指定。(BZ#2001008) - 在以前的版本中,自定义资源定义(CRD)模式的要求不允许使用数字值。因此,在升级过程中会发生错误。在这个版本中,修正了模式的要求,现在允许使用字符串和数值。因此,API 服务器转换不再报告 marshaling 错误。(BZ#1999425)
-
在以前的版本中,如果 Machine API Operator 已被移动,或者因为名称而部署 pod,
MachineNotYetDeleted
指标将为每个受监控的机器重置。在这个版本中,更改指标查询以忽略源 pod 标签。现在,MachineNotYetDeleted
指标在 Machine API Operator Pod 被重新命名的情况下可以正确地发出警报。(BZ#1986237) - 在以前的版本中,vSphere 上的出口 IP 由 kubelet 中的 vSphere 云供应商获取。对于证书签名请求(CSR)批准者,这些是意外的。因此,具有出口 IP 的节点不会批准其 CSR 续订。在这个版本中,CSR 批准员可以考虑出口 IP。因此,在 vSphere SDN 集群上具有出口 IP 的节点现在可以继续正常工作,并具有有效的 CSR 续订。(BZ#1860774)
- 在以前的版本中,worker 节点无法启动,安装程序无法生成 URL 镜像。造成这个问题的原因是,磁盘镜像的路径默认和 Google Cloud Platform(GCP) SDK 中做的一些变换不兼容。因此,机器控制器无法创建机器。在这个版本中,通过更改 GCP SDK 中的基本路径修复了 URL 镜像的问题。(BZ#2009111)
-
在以前的版本中,因为 vCenter 的
powerOff
任务中的延迟,机器在删除过程中会停滞。VMware 显示了要关闭的机器,但 OpenShift Container Platform 会报告它被开机,这会导致在删除过程中出现机器释放。在这个版本中,可以在创建数据库的任务前检查 vSphere 上的powerOff
任务处理,这会阻止机器在删除过程中释放。(BZ#2011668) - 安装或更新 OpenShift Container Platform 后,指标的值会在处理最后一个 CSR 后显示一个待处理的 CSR。这会导致在不应有待处理的 CSR 时报告一个待处理的 CSR。在这个版本中,通过更新每个协调循环末尾的指标,确保待处理的 CSR 计数始终为有效的 post-approval。(BZ#2013528)
-
在以前的版本中,当
cloud-provider
标志被设置为空字符串时,AWS 会检查凭证。通过调用元数据服务来检查凭证,即使在非 AWS 平台上也是如此。这会导致在 ECR 供应商启动和 AWS 凭证错误中记录所有平台(包括非 AWS)中的延迟。在这个版本中,凭证检查不再对元数据服务发出请求,以确保不再记录凭证错误。(BZ#2015515) - 在以前的版本中,Machine API 有时会在 AWS 在 API 中创建虚拟机前协调机器。因此,AWS 报告虚拟机不存在,Machine API 认为虚拟机失败。在这个版本中,Machine API 在尝试将机器标记为置备前会等待 AWS API 已同步。(BZ#2025767)
- 在以前的版本中,在 UPI 集群中同时创建的大量节点可能会导致生成大量 CSR。因此,证书续订不是自动的,因为批准员会在有 100 个待处理证书请求时停止批准证书。在这个版本中,在计算批准 cut-off 和 UPI 集群时,现有节点可以被考虑,即使具有大规模刷新请求,也可从自动化证书续订中受益。(BZ#2028019)
- 在以前的版本中,生成的在 Machine API 控制器中嵌入的实例类型列表已过时。其中一些实例类型未知,无法为 scale-from-zero 要求标注。在这个版本中,生成的列表被更新,以包含对较新的实例类型的支持。(BZ#2040376)
- 在以前的版本中,AWS Machine API 控制器没有设置 IO1 类型的块设备 IOPS 值,从而导致 GP3 块设备的 IOPS 字段被忽略。在这个版本中,对所有支持的块设备类型设置 IOPS,用户可以为附加到机器的块设备设置 IOPS。(BZ#2040504)
Cloud Credential Operator
-
在以前的版本中,当在 Azure 集群上以手动模式使用 Cloud Credential Operator 时,
Upgradeable
的状态为False
。这个行为在其他平台会有所不同。在这个版本中,在手动模式中使用 Cloud Credential Operator 的 Azure 集群会将Upgradeable
设置为False
。(BZ#1976674) -
在以前的版本中,现在由 Cloud Credential Operator 创建的
controller-manager-service
服务资源仍然存在。在这个版本中,Cluster Version Operator 会清理它。(BZ#1977319) -
在以前的版本中,忽略
CredentialsRequest
自定义资源中的 Cloud Credential Operator 的日志级别设置。在这个版本中,可以通过编辑CredentialsRequest
自定义资源来控制日志记录详细程度。(BZ#1991770) - 在以前的版本中,当 AWS 是 Red Hat OpenStack Platform(RHOSP)的默认 secret 时,Cloud Credential Operator(CCO)pod 会重启并带有持续错误。在这个版本中,CCO pod 的默认设置被修复,并防止 CCO pod 失败。(BZ#1996624)
Cluster Version Operator
- 在以前的版本中,pod 可能会因为不是清单一部分的无效挂载请求而无法启动。在这个版本中,Cluster Version Operator(CVO)从清单中不包含的集群资源中删除所有卷和卷挂载。这允许 pod 成功启动。(BZ#2002834)
- 在以前的版本中,当轮转监控证书时,Cluster Version Operator(CVO)会记录错误并监控无法查询指标,直到 CVO pod 手动重启为止。在这个版本中,CVO 监控证书文件,并在证书文件更改时自动重新创建指标连接。(BZ#2027342)
控制台存储插件
-
在以前的版本中,当置备持久性卷(PV)且容量为
0
TiB 时,不会出现载入提示,这会产生混淆的情况。在这个版本中,为载入状态添加了一个加载程序,它会在 PV 仍然被置备或容量来决定时为用户提供详情。它还会告知用户进程中的任何错误。(BZ#1928285) - 在以前的版本中,特定位置中的语法不正确,存在转换器无法解释上下文的实例。这对可读性有负面影响。在这个版本中,各种位置中的语法已被修正,转换器的存储类会项目化,总体可读性有所改进。(BZ#1961391)
-
在以前的版本中,当按块池页面中的池时,最终的
Ready
阶段会在删除后保留。因此,即使删除后池也会处于Ready
状态。此更新会将用户重定向到 池 页面,并在创建后刷新池。(BZ#1981396)
域名系统(DNS)
-
在以前的版本中,DNS Operator 不会缓存来自使用
spec.servers
配置的上游解析器的响应。在这个版本中,DNS Operator 会缓存来自所有上游服务器的响应。(BZ#2006803) -
在以前的版本中,DNS Operator 不会在服务器块中为自定义上游解析器启用
prometheus
pug-in。因此,CoreDNS 不会报告上游解析器的指标,而只报告默认服务器块的指标。在这个版本中,DNS Operator 被修改为在所有服务器块中启用prometheus
插件。CoreDNS 现在为自定义上游解析器报告 Prometheus 指标。(BZ#2020489) -
在以前的版本中,提供大于 512 个字符的响应的上游 DNS 会导致应用程序失败。这是因为无法从 GitHub 克隆存储库,因为无法解析到 DNS。在这个版本中,KNI CoreDNS 的
bufsize
设置为 521,以避免来自 GitHub 的名称解析。(BZ#1991067) -
当 DNS Operator 协调其操作对象时,Operator 会从 API 获取集群 DNS 服务对象,以确定 Operator 需要创建或更新服务。如果服务已存在,Operator 会将其与 Operator 期望的内容进行比较,以确定是否需要更新。Kubernetes 1.22 基于 OpenShift Container Platform 4.9,为服务引入了一个新的
spec.internalTrafficPolicy
API 字段。在创建服务时,Operator 会保留此字段为空,但 API 为此字段设置默认值。Operator 会观察到这个默认值,并尝试将字段更新为空值。这会导致 Operator 更新逻辑不断尝试恢复为服务内部流量策略的 API 设置的默认值。在这个版本中,当比较服务来确定是否需要更新时,Operator 现在会将spec.internalTrafficPolicy
的空值和默认值视为相等。因此,当 API 为服务的spec.internalTrafficPolicy 字段
设置默认值时,Operator 不再意外地尝试更新集群 DNS 服务。(BZ#2002461) -
在以前的版本中,DNS Operator 没有为 CoreDNS
Corefile
配置映射中的服务器块启用缓存插件,对应于dnses.operator.openshift.io/default
对象的spec.servers
字段中的条目。因此,CoreDNS 不会缓存来自使用spec.servers
配置的上游解析器的响应。在这个版本中,DNS Operator 被修改为为所有服务器块启用缓存插件,使用与 Operator 为默认服务器块配置的相同参数。CoreDNS 现在缓存来自所有上游解析器的响应。(BZ#2006803)
镜像 Registry
-
在以前的版本中,registry 内部解析了
\docker.io
引用\registry-1.docker.io
,并使用它来存储凭证。因此,\docker.io
镜像的凭据无法找到。在这个版本中,\registry-1.docker.io
主机名在搜索凭证时改回到\docker.io
。因此,registry 可以正确地查找\docker.io 镜像
的凭据。(BZ#2024859) - 在以前的版本中,镜像修剪器作业不会在失败时重试。因此,在下一次运行时,单个失败可能会降级 Image Registry Operator。在这个版本中,pruner 的临时问题不会降级 Image Registry Operator。(BZ#2051692)
- 在以前的版本中,Image Registry Operator 是修改 informer 中的对象。因此,这些对象可以被 informer 并发修改,并导致竞争条件。在这个版本中,控制器和通知程序有不同的对象副本,且没有竞争条件。(BZ#2028030)
-
在以前的版本中,
TestAWSFinalizerDeleteS3Bucket
可能会因为 Image Registry Operator 中的配置对象位置存在问题。在这个版本中,确保配置对象存储在正确的位置。因此,在运行TestAWSFinalizerDeleteS3Bucket
时,Image Registry Operator 不再 panic。(BZ#2048443) -
在以前的版本中,错误处理导致
访问被拒绝
的错误作为身份验证需要
的输出。这个程序错误会导致错误日志不正确。通过 Docker 分发错误处理,错误输出已从authentication required
改为access denied
。现在,访问拒绝
的错误提供更精确的错误日志。(BZ#1902456) - 在以前的版本中,registry 会立即在关闭请求退出。因此,路由器没有时间可以发现 registry Pod 已消失,并可向它发送请求。在这个版本中,当 pod 被删除时,它会多活跃额外几秒钟时间,为其他组件提供发现其删除的时间。现在,路由器不会在升级过程中向不存在的 pod 发送请求,这不再会造成中断。(BZ#1972827)
-
在以前的版本中,registry 会代理来自第一个可用的镜像 registry 中的响应。当镜像 registry 可用但没有请求的数据时,pull-through 也不会尝试使用其他镜像,即使它们包含所需数据。在这个版本中,如果第一个镜像回复了
Not Found
,则 pull-through 会尝试其他镜像 registry。现在,pull-through 可发现数据(如果镜像 registry 中存在)。(BZ#2008539)
镜像流
-
在以前的版本中,镜像策略准入插件无法识别部署配置,特别是可以更新有状态的集合。因此,当使用
resolve-names
注解时,镜像流引用会在部署配置中被取消解析。现在,插件已被更新,使它在部署配置和有状态集中解析注解。因此,镜像流标签会在创建和编辑的部署配置中解析。(BZ#2000216) -
在以前的版本中,当更新全局 pull secret 时,现有的 API 服务器 pod pull secret 不会被更新。现在,pull secret 的挂载点已从
/var/lib/kubelet/config.json
文件改为/var/lib/kubelet
目录。现在,更新的 pull secret 会出现在现有 API 服务器 pod 中。(BZ#1984592) - 在以前的版本中,镜像准入插件不会检查部署配置模板中的注解。因此,部署配置模板中的注解无法在副本控制器中处理,它们会被忽略。现在,镜像准入插件会分析部署配置的模板。在这个版本中,镜像准入插件可以识别部署配置及其模板上的注解。(BZ#2032589)
安装程序
-
OpenShift Container Platform Baremetal IPI 安装程序之前使用
install-config
中的主机中定义的第一个节点作为 control plane 节点,而不是过滤具有master
角色的主机。现在,master
和worker
节点的角色在定义时会被识别。(BZ#2003113) - 在此次更新之前,可以在 provisioning 网络 CIDR 中设置主机位。这可能导致置备 IP 有所不同,这和预期 IP 地址与 provisioning 网络上的其他 IP 地址冲突。在这个版本中,验证可确保调配网络 CIDR 无法包含主机位。如果置备网络 CIDR 包含主机位,安装程序会停止并记录错误信息。(BZ#2006291)
- 在以前的版本中,pre-flight 检查没有考虑 Red Hat OpenStack Platform(RHOSP)资源使用率。因此,当利用率而不是配额造成失败时,这些检查会失败并显示不正确的错误消息。现在,pre-flight 检查同时处理 RHOSP 配额和使用情况。如果配额足够但资源不足,则检查失败并带有正确的错误消息。(BZ#2001317)
- 在此次更新之前,oVirt Driver 可以在从配置文件创建 PVC 时指定 ReadOnlyMany(ROX)和 ReadWriteMany(RWX)访问模式。这会导致错误,因为驱动程序不支持共享磁盘,因此不支持这些访问模式。在这个版本中,访问模式仅限于单一节点访问。系统可防止在创建 PVC 时尝试指定 ROX 或 RWX,并记录错误消息。(BZ#1882983)
- 在以前的版本中,Terraform 供应商中的磁盘上传没有被正确处理。因此,OpenShift Container Platform 安装程序会失败。在这个版本中,磁盘上传处理已被修复,磁盘上传会成功。(BZ#1917893)
- 在以前的版本中,当安装带有特殊大小的 Microsoft Azure 集群时,安装程序会检查虚拟 CPU(vCPU)总数是否满足部署集群所需的最小资源要求。因此,这可能导致安装错误。在这个版本中,检查安装程序从 vCPU 总数到可用 vCPU 的数量改变。因此,给出一个简明的错误消息,可让 Operator 知道虚拟机大小不符合最低资源要求。(BZ#2025788)
- 在以前的版本中,Red Hat OpenStack Platform(RHOSP)的 RAM 验证使用错误单元检查了值,因此验证接受的类别不符合最小 RAM 要求。在这个版本中,RAM 验证会拒绝 RAM 不足的类别。(BZ#2009699)
- 在以前的版本中,当 OpenShift Container Platform control plane 节点可以调度并部署到 Red Hat OpenStack Platform(RHOSP)时,OpenShift Container Platform control plane 节点缺少 Ingress 安全组规则。因此,对于没有专用 worker 的紧凑集群,RHOSP 上的 OpenShift Container Platform 部署会失败。在这个版本中,在 control plane 节点可以调度时,在 Red Hat OpenStack Platform(RHOSP)上添加了 Ingress 安全组规则。现在,您可以在 RHOSP 上部署紧凑的三节点集群。(BZ#1955544)
- 在以前的版本中,如果您指定了无效的 AWS 区域,安装程序会继续尝试并验证可用区。这会导致安装程序在超时前有 60 分钟的无响应状态。安装程序现在在可用区前验证 AWS 区域和服务端点,这减少了安装程序报告错误的时间。(BZ#2019977)
- 在以前的版本中,如果 vCenter 主机名以数字开头,则无法将集群安装到 VMware vSphere。安装程序已更新,不再将这类主机名视为无效。现在,当 vCenter 主机名以数字开头时,集群会成功部署。(BZ#2021607)
- 在以前的版本中,如果您在 Microsoft Azure 上部署集群时指定了自定义磁盘实例类型,集群可能无法部署。这是因为安装程序错误地决定满足最低资源要求。安装程序已更新,现在在所选区域中实例类型的 vcpus 数量没有满足最低资源要求时报告错误。(BZ#2025788)
- 在以前的版本中,如果您在部署 AWS 集群时定义了自定义 IAM 角色,则必须在卸载集群后手动删除 bootstrap 实例配置集。在有些情况下,安装程序不会删除 bootstrap 实例配置集。安装程序已更新,在卸载集群时,所有机器实例配置集都会被删除。(BZ#2028695)
- 在以前的版本中,当置备网络 CIDR 中设置主机位时,默认的 provisioningIP 值会有所不同。这会导致 provisioningIP 的值与预期不同。这种差异会导致与 provisioning 网络中的其他 IP 地址冲突。在这个版本中,添加了一个验证,以确保 ProvisioningNetworkCIDR 没有设置主机位。因此,如果 ProvisioningNetworkCIDR 设置了主机位,安装程序会停止并报告验证错误。(BZ#2006291)
-
在以前的版本中,安全 UEFI 引导不支持 BMC 驱动程序 IPMI。这会导致引导失败。在这个版本中,添加了一个验证检查,以确保
UEFISecureBoot
模式没有用于裸机驱动程序。因此,安全 UEFI 引导可以成功。(BZ#2011893) - 在这个版本中,4.8 UPI 模板从版本 3.1.0 更新至 3.2.0,以匹配 Ignition 版本。(BZ#1949672)
-
在以前的版本中,当要求镜像基本 registry 的内容时,OpenShift Container Platform 安装程序将以验证错误退出,协调
imageContentSources
不正确的install-config
文件大小。在这个版本中,安装程序允许imageContentSources
值指定基本 registry 名称,安装程序在指定基本 registry 名称时不再退出。(BZ#1960378) -
在以前的版本中,UPI ARM 模板将 SSH 密钥附加到创建的虚拟机(VM)实例。因此,当用户提供的 SSH 密钥是
ed25519
类型时,虚拟机的创建会失败。在这个版本中,无论用户提供的 SSH 密钥类型,虚拟机创建都会成功。(BZ#1968364) -
成功创建
aws_vpc_dhcp_options_association
资源后,AWS 可能仍会报告该资源不存在。因此,AWS Terraform 供应商将无法安装。在这个版本中,您可以在创建时间段内重试aws_vpc_dhcp_options_association
资源的查询,直到 AWS 报告存在资源存在。因此,虽然 AWS 报告aws_vpc_dhcp_options_association
资源不存在,安装仍会成功。(BZ#2032521) - 在以前的版本中,当在启用了本地区的 AWS 上安装 OpenShift Container Platform 时,安装程序可能会在本地区而不是可用区中创建某些资源。这会导致安装程序失败,因为负载均衡器无法在本地区中运行。在这个版本中,安装程序会忽略本地区,且仅在安装集群组件时考虑可用域。(BZ#1997059)
- 在以前的版本中,terraform 可以在创建配置文件前尝试将 bootstrap ignition 配置文件上传到 Azure。如果在创建文件之前启动上传,安装将失败。在这个版本中,terraform 将 ignition 配置文件直接上传到 Azure,而不是首先创建本地副本。(BZ#2004313)
-
在以前的版本中,如果
cluster-bootstrap
和 Cluster Version Operator 组件同时试图为同一资源写入 Kubernetes API,则可能会出现竞争条件。这可能会导致身份验证
资源被默认副本覆盖,后者删除了对该资源所做的任何自定义。在这个版本中,Cluster Version Operator 会阻止覆盖来自安装程序的清单。这可防止对Authentication
资源的任何用户指定的自定义都会被覆盖。(BZ#2008119) -
在以前的版本中,当在 AWS 上安装 OpenShift Container Platform 时,安装程序使用
m5.large
实例类型创建 bootstrap 机器。这会导致安装在实例类型不可用的区域失败。在这个版本中,bootstrap 机器使用与 control plane 机器相同的实例类型。(BZ#2016955) - 在以前的版本中,当在 AWS 上安装 OpenShift Container Platform 时,安装程序无法识别 EC2 G 和 Intel Virtualization Technology(VT)实例,并将其默认转换为 X 实例。这会导致实例配额应用到这些实例。在这个版本中,安装程序会识别 EC2 G 和 VT 实例,并应用正确的实例配额。(BZ#2017874)
Kubernetes API 服务器
Kubernetes 调度程序
-
在此次更新之前,升级到当前的发行版本没有为
TaintandToleration
、NodeAffinity
和InterPodAffinity
参数设置正确的权重。在这个版本中解决了这个问题,升级可以正确地将TaintandToleration
的权重设置为3
、NodeAffinity
为2
,并将InterPodAffinity
设置为2
。(BZ#2039414) -
在 OpenShift Container Platform 4.10 中,提供不安全指标的代码已从
kube-scheduler
代码库中删除。现在,指标仅通过安全服务器提供。错误修复和支持将在以后的生命周期结束时提供。之后,不会进行新的功能增强。(BZ#1889488)
Machine Config Operator
-
在以前的版本中,Machine Config Operator(MCO)会在应用操作系统(OS)更改前,将待处理的配置更改保存到磁盘。因此,在电源丢失的情况下,MCO 假设的操作系统更改已在重启时应用,并通过
kargs
和kernel-rt
等更改跳过验证。在这个版本中,在操作系统更改后保存对磁盘配置更改。现在,如果在配置应用程序过程中丢失电源,MCO 知道它必须在重启时重试配置应用程序。(BZ#1916169) -
在以前的版本中,
baremetal-runtimecfg
项目中的 Kubernetes 客户端程序库无法及时关闭客户端连接。这可能会导致监控依赖 API 的容器的延迟时间。在这个版本中,可以在 VIP 故障转移后及时关闭客户端连接。(BZ#1995021) -
在以前的版本中,当更新 SSH 密钥时,Machine Config Operator(MCO)将
authorized_keys
文件的所有者和组改为root
。在这个版本中,在更新authorized_keys
文件时,MCO 会保留core
作为所有者和组。(BZ#1956739) -
在以前的版本中,
clone_slave_connection
函数发送的警告信息被错误地存储在new_uuid
变量中,它应该只存储连接的 UUID。因此,包含new_uuid
变量的nmcli
命令可能会因为将不正确的值存储在new_uuid
变量中而失败。在这个版本中,clone_slave_connection
功能警告消息会被重定向到stderr
。现在,用于引用new_uuid
变量的nmcli
命令不会失败。(BZ#2022646) -
在以前的版本中,
baremetal-runtimecfg
项目中有 Kubernetes 客户端库的旧版本。当虚拟 IP(VIP)失败时,可能无法及时关闭客户端连接。这可能会导致对依赖与 API 通信的容器进行长时间延迟。在这个版本中更新了客户端库。现在,在 VIP 故障转移中预期连接会关闭,而监控容器在一段时间内不会挂起。(BZ#1995021) - 在此次更新之前,Machine Config Operator(MCO)会在将待处理的配置更改应用到 Red Hat Enterprise Linux CoreOS(RHCOS)之前将其保存到磁盘。如果电源丢失导致 MCO 应用配置中断,它将被视为已应用且没有验证更改。如果此配置包含无效更改,应用会失败。在这个版本中,MCO 只有在应用后才会将配置保存到磁盘。这样,如果在 MCO 应用配置时电源丢失,它会在重启后获取配置。(BZ#1916169)
-
在此次更新之前,当使用 Machine Config Operator(MCO)创建或更新 SSH 密钥时,它会将
authorized_keys
文件的所有者和组设置为root
。这个版本解决了这个问题。当 MCO 创建或更新authorized_keys
文件时,它会正确设置或保留core
作为文件的所有者和组。(BZ#1956739) -
在以前的版本中,在使用无状态 Address AutoConfiguration(SLAAC)的集群中,Ironic
addr-gen-mode
参数不会被保留到 OVNKubernetes 网桥。因此,在创建网桥时 IPv6 地址可能会改变。这会破坏集群,因为不支持节点 IP 更改。在这个版本中,在创建网桥时会保留addr-gen-mode
参数。该 IP 地址现在在整个部署过程中一致。(BZ#1990625) -
在以前的版本中,如果机器配置包含了一个压缩文件,且
spec.config.storage.files.contents.compression
参数设置为gzip
,Machine Config Daemon(MCD)会错误地将压缩文件写入磁盘而不提取它。在这个版本中,当压缩参数设置为gzip
时,MCD 现在提取压缩文件。(BZ#1970218) -
在以前的版本中,只有在完全删除时才清理
systemd
单元。因此,systemd
单元无法使用机器配置取消屏蔽,因为掩码不会被删除,除非systemd
单元已完全删除。在这个版本中,当您在机器配置中将systemd
单元配置为mask: true
时,任何现有掩码都会被删除。现在,systemd
单元可以被取消屏蔽。(BZ#1966445)
管理控制台
-
在以前的版本中,OperatorHub 类别和卡链接不包括有效的
href
属性。因此,OperatorHub 类别和卡链接无法在新标签页中打开。在这个版本中,OperatorHub 类别和卡链接中添加有效的href
属性。因此,OperatorHub 及其卡链接可在新标签页中打开。(BZ#2013127) -
在以前的版本中,在 Operand Details 页面中,会创建一个特殊情况,其中
status.conditions
属性的条件表总是出现在所有其他表前。因此,status.conditions
表没有遵循描述符顺序规则,这会导致用户在尝试更改表顺序时造成意外行为。在这个版本中,删除了status.conditions
的特殊问题单,只有在没有为该属性定义描述符时,才会首先渲染它。因此,当描述符在那个属性上定义了描述符时,status.condition
的表会根据描述符排序规则呈现。(BZ#2014488) -
在以前的版本中,Resource Details 页面指标标签页超过集群范围的 Thanos 端点。因此,没有此端点授权的用户将收到所有查询的
401
响应。在这个版本中,Thanos 租期端点会被更新,并会删除冗余命名空间查询参数。因此,具有正确基于角色的访问控制(RBAC)权限的用户现在可以在 Resource Details 页面的 metrics 选项卡中看到数据。(BZ#2015806) - 在以前的版本中,当 Operator 在现有 API 组中添加 API 时,它不会触发 API 发现。因此,在页面被刷新前,前端不会看到新的 API。在这个版本中,Operator 通过前端添加 API 而无需页面刷新。(BZ#1815189)
- 在以前的版本中,在 Red Hat OpenStack Platform(RHOSP)的 Red Hat OpenShift Cluster Manager 中,control plane 没有被翻译为简体中文。因此,命名与 OpenShift Container Platform 文档不同。在这个版本中,Red Hat OpenShift Cluster Manager 中的翻译问题已被修复。(BZ#1982063)
-
在以前的版本中,Red Hat OpenShift Cluster Manager 中的虚拟表过滤无法正常工作。因此,在一个搜索后所有可用的
节点
不会出现。这个版本包括新的虚拟表逻辑,修复了 Red Hat OpenShift Cluster Manager 中的过滤问题。(BZ#1990255)
监控
在以前的版本中,在 OpenShift Container Platform 升级过程中,Prometheus 服务可能会不可用,因为两个 Prometheus pod 位于同一节点上,或运行 pod 的两个节点同时重启。这是因为 Prometheus pod 在节点放置方面具有软反关联性规则,且没有置备
PodDisruptionBudget
资源。因此,指标不会被收集,不会在一段时间内评估规则。要解决这个问题,Cluster Monitoring Operator(CMO)现在配置硬反关联性规则,以确保将两个 Prometheus pod 调度到不同的节点上。CMO 还置备
PodDisruptionBudget
资源,以确保至少有一个 Prometheus pod 始终在运行。因此,在升级过程中,节点现在按顺序重新引导,以确保至少有一个 Prometheus pod 始终在运行。(BZ#1933847)在以前的版本中,当包含两个 Thanos Ruler pod 的节点遇到中断时,Thanos Ruler 服务将不可用。这是因为 Thanos Ruler pod 只针对节点放置有软反关联性规则。因此,在节点重新上线前,不会评估用户定义的规则。
在这个版本中,Cluster Monitoring Operator(CMO)现在会配置硬反关联性规则,以确保将两个 Thanos Ruler pod 调度到不同的节点上。因此,单节点中断不再会在用户定义的规则评估中造成差距。(BZ#1955490)
在以前的版本中,当两个 Prometheus pod 位于同一节点上时,Prometheus 服务将不可用,且节点会出现停机的情况。这是因为 Prometheus pod 只针对节点放置有软反关联性规则。因此,指标不会被收集,在节点恢复在线之前不会评估规则。
在这个版本中,Cluster Monitoring Operator 配置硬反关联性规则,以确保两个 Prometheus pod 调度到不同的节点上。现在,Prometheus pod 被调度到不同的节点上,单个节点中断不再会在监控时造成一个差距。(BZ#1949262)
-
在以前的版本中,在 OpenShift Container Platform 补丁升级过程中,Alertmanager 服务可能会不可用,因为三个 Alertmanager pod 位于同一节点上,或者运行 Alertmanager pod 的节点会同时重启。这种情况是可能的,因为 Alertmanager pod 在节点放置方面具有软反关联性规则,且没有置备
PodDisruptionBudget
。此发行版本启用了硬反关联性规则和PodDisruptionBudget
资源,以确保在为 Alertmanager 和其他监控组件的补丁升级过程中不会停机。(BZ#1955489) -
在以前的版本中,当文件系统空间被很多 Docker 镜像占用时,会触发一个假的
NodeFilesystemSpaceFillingUp
警报。在本发行版本中,触发NodeFilesystemSpaceFillingUp
警告警报的阈值现在被减少到 20% 的可用空间,而不是 40%,这会防止触发假警报。(BZ#1987263) 在以前的版本中,Prometheus Operator 组件的警报不适用于启用用户定义的监控时运行
openshift-user-workload-monitoring
命名空间的 Prometheus Operator。因此,当管理openshift-user-workload-monitoring
命名空间遇到问题的 Prometheus Operator 时,不会触发警报。在这个版本中,修改了警报来监控
openshift-monitoring
和openshift-user-workload-monitoring
命名空间。因此,当管理用户定义的监控遇到问题的 Prometheus Operator 时,集群管理员会收到警报通知。(BZ#2001566)在以前的版本中,如果
node-exporter
代理的 DaemonSet pod 数量与集群中的节点数量不同,Cluster Monitoring Operator(CMO)会报告一个degraded
条件。当其中一个节点没有处于ready
条件时,会出现此问题。此发行版本现在会验证
node-exporter
代理的 DaemonSet pod 数量是否小于集群中的就绪节点的数量。此过程可确保node-exporter
pod 在每个活跃节点上运行。因此,如果其中一个节点没有处于 ready 状态,CMO 不会报告降级条件。(BZ#2004051)- 此发行版本解决了这个问题,监控堆栈中的一些 pod 会在与 TLS 证书相关的资源存在前启动,这会导致失败并重启。(BZ#2016352)
-
在以前的版本中,如果因为达到配置的示例限制而报告指标失败,指标目标仍会在 web 控制台 UI 中出现
Up
状态,即使缺少指标。在这个版本中,Prometheus 会绕过报告指标的示例限制设置,指标现在显示在示例限制设置中。(BZ#2034192)
网络
- 当在 4.8 之前的 OpenShift Container Platform 版本中使用 OVN-Kubernetes 网络供应商时,节点路由表用于路由决策。在较新版本的 OpenShift Container Platform 中,会绕过主机路由表。在这个发行版本中,您可以指定是否要使用或绕过主机内核网络堆栈进行流量路由决策。(BZ#1996108)
- 在以前的版本中,当使用带有代理的受限安装中使用 Kuryr 时,Cluster Network Operator 不会被强制使用代理来允许与 Red Hat OpenStack Platform(RHOSP)API 的通信。因此,集群安装不会进行。在这个版本中,Cluster Network Operator 可以通过代理与 RHOSP API 通信。现在,安装可以成功。(BZ#1985486)
- 在此次更新之前,SRIOV 会阻止在 Red Hat OpenStack Platform(RHOSP)环境中的 OpenShift Container Platform 上创建网络策略。在这个版本中,SRIOV 会读取并验证 RHOSP 元数据,现在可以使用它创建网络策略。(BZ#2016334)
-
在以前的版本中,
MachineConfig
对象无法更新,因为 SRIOV Operator 不会暂停MachineConfig
池对象。在这个版本中,SRIOV Operator 在运行需要重启的配置前会暂停相关的机器配置池。(BZ#2021151) -
在以前的版本中,
keepalived
会在应该运行时造成终止的时间问题。这个版本可防止在较短的时间内发送多个keepalived
命令。因此,时间不再是问题,keepalive
持续运行。(BZ#2022050) - 在以前的版本中,当使用带有代理的受限安装中使用 Kuryr 时,Cluster Networking Operator 不会被强制使用代理来允许与 Red Hat OpenStack Platform(RHOSP)API 的通信。因此,集群安装不会进行。在这个版本中,Cluster Network Operator 可以通过代理与 RHOSP API 通信。现在,安装可以成功。(BZ#1985486)
-
在以前的版本中,因为 IP 地址耗尽,使用 Whereabouts Container Network Interface(CNI)插件提供的二级接口的 pod 可能会处于
ContainerCreating
状态。现在,Whereabouts 可以正确地记录从集群事件中释放的 IP 地址(如重启后),之前没有跟踪这些 IP 地址。(BZ#1914053) - 在以前的版本中,当使用 OpenShift SDN 集群网络供应商时,闲置服务会使用大量 CPU 资源来取消闲置服务。在本发行版本中,kube-proxy 的闲置代码会被优化,以减少使用服务闲置的 CPU。(BZ#1966521)
- 在以前的版本中,当使用 OVN-Kubernetes 集群网络供应商时,内部配置映射中存在任何未知字段可能会导致 OVN-Kubernetes pod 在集群升级过程中启动。现在,存在未知字段会导致警告,而不是失败。因此,OVN-Kubernetes pod 现在在集群安装过程中成功启动。(BZ#1988440)
- 在以前的版本中,SR-IOV Network Operator 的 Webhook 会阻止 OpenStack 上安装 OpenShift 的网络策略。用户无法创建 SR-IOV 网络策略。在这个版本中,webhook 被修复。用户现在可以为 OpenStack 上安装创建 SR-IOV 网络策略。(BZ#2016334)
-
在以前的版本中,CRI-O 运行时引擎使用
K8S_POD_UID
变量传递 pod UID。但是,当 Multus 为已删除 pod 的沙盒设置网络时,当 pod 被删除并重新创建时,这个方法会导致额外的元数据和不必要的处理。在这个版本中,Multus 处理 pod UID,并避免不必要的元数据处理。(BZ#2017882) -
在以前的版本中,在单个节点上部署 OpenShift 时,SR-IOV Network Operator 的默认设置会阻止用户对节点进行修改。默认情况下,在应用配置更改后,受影响的节点会排空,然后使用新配置重启。当只有一个节点时,这个行为无法正常工作。在这个版本中,当您在单节点部署中安装 SR-IOV Network Operator 时,Operator 会更改其配置,以便
.spec.disableDrain
字段设置为true
。用户现在可以在单节点部署中成功应用配置更改。(BZ#2021151) - client-go 版本 1.20 及更早版本没有足够技术来重试请求到 Kubernetes API。因此,重试 Kubernetes API 并不够。此次更新解决了通过 client-go 1.22 引入的问题。(BZ#2052062)
节点
- 在以前的版本中,由 CRI-O 管理的网络、IPC 和 UTS 命名空间资源仅在 Kubelet 删除停止的 pod 时才会释放。在这个版本中,Kubelet 在 pod 停止时释放这些资源。(BZ#2003193)
-
在以前的版本中,当登录到 worker 节点时,可能会显示信息代表
systemd-coredump
服务失败。这是因为没有为容器包含system-systemd
命名空间。现在,过滤器可防止这个命名空间影响工作流。(BZ#1978528) -
在以前的版本中,当集群重启时,终止的 pod 的状态可能已重置为
Running
,这会导致错误。这个问题已被修正,现在所有终止的 pod 都保持被终止,活跃的 pod 反映了其状态。(BZ#1997478) - 在以前的版本中,OpenShift Container Platform 中会忽略某些停止信号,从而导致容器中的服务继续运行。随着对信号解析库的更新,现在所有停止信号都会被遵守。(BZ#2000877)
- 在以前的版本中,当 pod 被删除时,由 CRI-O 管理的 pod 命名空间(如 network、IPC 和 UTS)不会被卸载。这会导致泄漏,将 Open vSwitch CPU 增加到 100%,这会导致 pod 延迟和其他性能影响。这个问题已被解决,在移除时 pod 命名空间会被卸载。(BZ#2003193)
OpenShift CLI (oc)
- 在以前的版本中,因为集群中安装的自定义资源定义(CRD)数量增加,达到 API 发现的请求会根据客户端代码的限制。现在,限制号和 QPS 已被提高,客户端节流应更频繁出现。(BZ#2042059)
-
在以前的版本中,有些次要请求没有正确设置用户代理字符串,因此默认的 Go 用户代理字符串被用于
oc
。现在,适用于所有镜像请求的用户代理字符串会被正确设置,预期的oc
user agent 字符串现在发送到 registry。(BZ#1987257) -
在以前的版本中,
oc debug
假设它总是通过尝试运行 Bash shell 来定位基于 Linux 的容器,如果容器中不存在 Bash,则会尝试作为 Windows 容器调试。oc debug
命令现在使用 pod 选择器来决定容器的操作系统,现在可以在 Linux 和基于 Windows 的容器中正常工作。(BZ#1990014) -
在以前的版本中,
--dry-run
标志在几个oc set
子命令中无法正确执行,因此--dry-run=server
会对资源执行更新,而不是执行空运行。--dry-run
标志现在可以在oc set
子命令上执行空运行。(BZ#2035393)
OpenShift 容器
-
在以前的版本中,因为缺少策略,使用 SELinux 的容器无法读取
/var/log/containers
日志文件。在这个版本中,/var/log
中的所有日志文件都可访问,包括通过符号链接访问的日志文件。(BZ#2005997)
OpenShift Controller Manager
-
在以前的版本中,
openshift_apps_deploymentconfigs_last_failed_rollout_time
指标错误地将namespace
标签设置为exported_namespace
标签的值。openshift_apps_deploymentconfigs_last_failed_rollout_time
指标现在带有正确的namespace
标签设置。(BZ#2012770)
Operator Lifecycle Manager (OLM)
-
在此次更新之前,
marketplace-operator
的默认目录源不容许污点节点,CatalogSource
pod 只有容限的默认设置nodeSelector
和priorityClassName
。在这个版本中,CatalogSource
规格包含可选的spec.grpcPodConfig
字段,该字段可覆盖 pod 的容限、nodeSelector
和priorityClassName
。(BZ#1927478) -
在此更新之前,当 OLM Operator 重启时,
csv_suceed
指标将会丢失。在这个版本中,csv_succeeded
指标会在 OLM Operator 的启动逻辑的开头发出。(BZ#1927478) -
在此次更新之前,
oc adm catalog mirror
命令没有为--max-icsp-size
标志设置最小和最大值。因此,字段可以接受小于零的值,以及非常大的值。在这个版本中,值的大小限制为大于零且小于 250001。此范围之外的值无法通过验证。(BZ#1972962) -
在此次更新之前,捆绑镜像没有在基于文件的目录中包含部署 Operator 所需的相关镜像。因此,除非在 ClusterServiceVersion(CSV)的
relatedImages
字段中指定,镜像不会被镜像到断开连接的集群。在这个版本中,opm render
命令在基于文件的目录捆绑包镜像时将 CSV Operator 镜像添加到relatedImages
文件中。现在,即使它们没有在 CSV 的relatedImages
字段中列出,Operator 部署所需的镜像也会被镜像到断开连接的集群。(BZ#2002075) -
在此次更新之前,Operator 可能需要长达 15 分钟才能执行
skipRange
更新。这是一个已知问题,如果集群管理员在openshift-operator-lifecycle-manager
命名空间中删除了catalog-operator
pod,则可能解决。这会导致自动重新创建 pod 并触发skipRange
升级。在这个版本中,Operator Lifecycle Manager(OLM)中修复过时的 API 调用,skipRange
会立即更新触发器。(BZ#2002276) - 有时,当 Operator Lifecycle Manager(OLM)从列表缓存修改对象时,集群中的更新事件也会同时发生。这会导致并发映射写入。在这个版本中更新了 OLM,因此它不再修改从 lister 缓存检索的对象。相反,OLM 会修改适用的对象的副本。因此,OLM 不再遇到并发映射写入。(BZ#2003164)
-
在以前的版本中,Operator Lifecycle Manager(OLM)无法建立到仅可通过代理访问的目录源 pod 的 gRPC 连接。如果目录源 pod 位于代理后面,OLM 无法连接到代理,而托管 Operator 内容无法进行安装。此程序错误修复引入了
GRPC_PROXY
环境变量,它定义了一个 OLM 用来建立到 gRPC 目录源的连接的代理。现在,OLM 可以配置为在连接到 gRPC 目录源时使用代理。(BZ#2011927) - 在以前的版本中,未验证跳过的捆绑包是同一软件包的成员。捆绑包可以在软件包之间跳过,这会破坏升级链。此程序错误修复添加了验证,以确保跳过的捆绑包在同一个软件包中。因此,捆绑包无法跳过另一个软件包中的捆绑包,升级图形也不会在软件包间中断。(BZ#2017327)
-
在
CatalogSource
对象中,RegistryServiceStatus
字段存储了用来生成 Operator Lifecycle Manager(OLM)依赖的地址的服务信息,以与关联的 pod 建立连接。如果RegistryServiceStatus
字段不是 nil,且缺少其服务的命名空间、名称和端口信息,则 OLM 将无法恢复,直到关联的 pod 无效镜像或 spec。在这个版本中,当协调目录源时,OLM 现在会确保CatalogSource
对象的RegistryServiceStatus
字段有效并更新其状态,以反映更改。另外,这个地址存储在目录源的状态中(status.GRPCConnectionState.Address
项)。如果地址改变,OLM 会更新此字段以反映新的地址。因此,目录源的.status.connectionState.address
字段应该不再是 nil。(BZ#2026343)
OpenShift API 服务器
OpenShift 更新服务
Red Hat Enterprise Linux CoreOS (RHCOS)
- 在以前的版本中,当 RHCOS live ISO 为其自身添加了 UEFI 引导条目时,它会假定现有的 UEFI 引导条目 ID 会被连续,从而导致 live ISO 在带有 non-consecutive 引导条目 ID 的系统上引导时在 UEFI 固件中失败。在这个版本中,RHCOS live ISO 不再为自己添加 UEFI 引导条目,ISO 可以成功引导。(BZ#2006690)
- 为了帮助您确定用户提供的镜像是否已引导,在终端控制台中添加信息,描述机器是否置备了 Ignition 配置,以及是否提供用户 Ignition 配置。这可让您验证 Ignition 是否按预期运行。(BZ#2016004)
- 在以前的版本中,当在置备过程中重复使用现有的静态密钥的 LUKS 卷时,加密密钥无法正确写入磁盘,Ignition 将失败,并显示 "missing persist keyfile" 错误。在这个版本中,Ignition 可以正确地为重复利用的 LUKS 卷写入密钥,以便在置备过程中可以重复使用现有的静态密钥的 LUKS 卷。(BZ#2043296)
-
在以前的版本中,在将 Red Hat Enterprise Linux CoreOS(RHCOS)节点升级到 4.6.17 时,
ostree-finalize-staged.service
会失败。要修复这个问题,sysroot 代码现在忽略/etc
中任何 irregular 或 non-symlink 文件。(BZ#1945274) -
在以前的版本中,
initramfs
文件缺少通过附加的 SCSI 设备符号链接的 udev 规则。因此,引用这些符号链接的 Ignition 配置文件会导致引导安装的系统失败。在这个版本中,在 dracut 中添加了 SCSI 规则的63-scsi-sg3_symlink.rules
。(BZ#1990506) -
在以前的版本中,在裸机机器上,
system-rfkill.service
和ostree-remount.service
之间有一个竞争条件。因此,ostree-remount
服务失败,且节点操作系统在引导过程中冻结。在这个版本中,/sysroot/
目录是只读的。因此,这个问题不再发生。(BZ#1992618) - 在以前的版本中,Red Hat Enterprise Linux CoreOS(RHCOS) live ISO 引导会添加 UEFI 引导条目,在带有 TPM 的系统上提示输入重启。在这个版本中,RHCOS live ISO 不再添加 UEFI 引导条目,以便 ISO 在首次引导后不会启动重启。(BZ#2004449)
Performance Addon Operator
-
如果
spec.cpu.isolated
是PerformanceProfile
中定义的唯一参数,则默认情况下,spec.cpu.reserved' 标志可能无法正确设置。您必须在PerformanceProfile
中为spec.cpu.reserved
和spec.cpu.isolated
设置设置。此设置不能相互重叠,提到的所有 CPU 都必须覆盖目标池中 worker 期望的所有 CPU。(BZ#1986681) -
在以前的版本中,如果镜像中缺少
gather-sysinfo
二进制文件,oc adm must-gather
工具将无法收集节点数据。这是因为 Dockerfile 中缺少COPY
语句所致。要避免这个问题,您必须将所需的COPY
语句添加到 Dockerfile 中来生成并复制二进制文件。(BZ#2021036) - 在以前的版本中,Performance Addon Operator 从 registry 下载其镜像,而不检查它是否在 CRI-O 缓存中可用。因此,如果无法到达 registry,或者下载超时,则 Performance Addon Operator 无法启动。在这个版本中,如果无法从 CRI-O 缓存拉取镜像,Operator 只会从 registry 中下载其镜像。(BZ#2021202)
-
当将 OpenShift Container Platform 升级到 4.10 时,在 tuned 配置集中不会开始的任何注释(
#comment
)会导致解析错误。Performance Addon Operator 问题可以通过升级到与 OpenShift Container Platform 相同的级别(4.10)来解决。通过在一行中,将所有注释放在一行中,使用 # 字符在行的开头处理与注释相关的错误。(BZ#2059934)
路由
- 在以前的版本中,如果集群管理员提供的默认入口证书缺少了最坏一行的 newline 字符,OpenShift Container Platform 路由器会为 HAProxy 生成一个已损坏的 PEM 文件。现在,它写入有效的 PEM 文件,即使输入缺少换行符。(BZ#1894431)
-
在以前的版本中,创建 DNS 片段的 combined name 和 namespace 大于 63 个字符的路由会被拒绝。这个预期的行为可能会导致与升级的 OpenShift Container Platform 版本集成相关的问题。现在,注解允许非格式的 DNS 主机名。允许将
AllowNonDNSCompliantHostAnnotation
设置为true
、非一致性 DNS 主机名或一个大于 63 个字符。(BZ#1964112) -
在以前的版本中,当集群的
ControlPlaneTopology
设置为External
时,Cluster Ingress Operator 不会为 Ingress Controller 创建通配符 DNS 记录。在将ControlPlaneTopology
设置为External
且平台是 AWS 的 Hypershift 集群中,Cluster Ingress Operator 不会不可用。当ControlPlaneTopology
为External
且平台是 IBM Cloud 时,这个更新限制了 DNS 更新。因此,为 AWS 上运行的 Hypershift 集群创建通配符 DNS 条目。(BZ#2011972) - 在以前的版本中,集群入口路由器无法工作,因为 Ingress Operator 无法为 Azure Stack Hub IPI 上的集群入口路由器配置通配符 DNS 记录。在这个版本中,Ingress Operator 使用配置的 ARM 端点在 Azure Stack Hub IPI 上配置 DNS。因此,集群入口路由器现在可以正常工作。(BZ#2032566)
-
在以前的版本中,集群范围的代理配置无法接受
noProxy
设置的 IPv6 地址。因此,无法安装具有 IPv6 地址的noProxy
的集群。在这个版本中,Cluster Network Operator 可为集群范围代理资源的noProxy
设置解析 IPv6 地址。现在,可以为noProxy
设置排除 IPv6 地址。(BZ#1939435) -
在 OpenShift Container Platform 4.8 之前,IngressController API 在
status.endpointPublishingStrategy.hostNetwork
和status.endpointPublishingStrategy.nodePort
字段中没有任何子字段。即使spec.endpointPublishingStrategy.type
设置为HostNetwork
或NodePortService
,这些字段也可以为空。在 OpenShift Container Platform 4.8 中,添加了status.endpointPublishingStrategy.hostNetwork.protocol
和status.endpointPublishingStrategy.nodePort.protocol
子字段,当 Operator admitted 或 re-admitted 一个指定了 "HostNetwork" 或 "NodePortService" 策略类型时为这些子字段设置默认值。但是,Operator 会忽略对这些 spec 字段的更新,将spec.endpointPublishingStrategy.hostNetwork.protocol
或spec.endpointPublishingStrategy.nodePort.protocol
更新到PROXY
以在现有 IngressController 上启用代理协议会无效。要临时解决这个问题,需要删除并重新创建 IngressController 来启用 PROXY 协议。在这个版本中,Ingress Operator 已被修改,当status.endpointPublishingStrategy.hostNetwork
和status.endpointPublishingStrategy.nodePort
为 null,并且 IngressController spec 指定了代理协议HostNetwork
或NodePortService
端点发布策略类型,它可以被正确更新。因此,将spec.endpointPublishingStrategy.hostNetwork.protocol
或spec.endpointPublishingStrategy.nodePort.protocol
设置为PROXY
现在会在升级的集群上正确生效。(BZ#1997226)
Samples
-
在此次更新之前,如果 Cluster Samples Operator 遇到
APIServerConflictError
错误,它会将sample-operator
报告为具有Degraded 状态
,直到恢复为止。这个类型的 momentary 错误在升级过程中不会出现异常,但会导致管理员监控 Operator 状态的问题。在这个版本中,如果 Operator 遇到 momentary 错误,它不再指示openshift-samples
具有Degraded 状态
,并尝试连接到 API 服务器。momentary 变为Degraded 状态
不再会发生。(BZ#1993840) 在此次更新之前,集群镜像配置中的各种允许和阻止的 registry 配置选项可能会阻止 Cluster Samples Operator 创建镜像流。因此,示例 Operator 可能会将自身标记为 degraded,这会影响一般的 OpenShift Container Platform 安装和升级状态。
在各种情况下,Cluster Samples Operator 的管理状态可变为
Removed
。在这个版本中,这些情况包括在镜像控制器配置参数时,无法使用默认镜像 registry 或samplesRegistry
设置指定的镜像 registry 创建镜像流。Operator 状态现在还表示集群镜像配置会阻止创建示例镜像流。(BZ#2002368)
存储
- 在以前的版本中,由于 10 秒的延迟,Local Storage Operator(LSO)需要很长时间来删除孤立的持久性卷(PV)。在这个版本中,LSO 不使用 10 秒的延迟,PV 会提示您删除,本地磁盘将更快提供给新的持久性卷声明。(BZ#2001605)
- 在以前的版本中,Manila 错误处理会降级 Manila Operator 和集群。现在,错误会被视为非严重,以便 Manila Operator 被禁用,而不是降级集群。(BZ#2001620)
- 在较慢的云环境中,如使用 Cinder 时,集群可能会降级。现在,OpenShift Container Platform 会适应较慢的环境,以便集群不会降级。(BZ#2027685)
电信边缘
-
如果生成的策略具有
mustonlyhave
的 complianceType,则 Operator Lifecycle Manager(OLM)更新元数据会恢复,因为策略引擎恢复 CR 的"预期"状态。因此,OLM 和策略引擎会持续覆盖冲突 CR 的元数据。这会造成高 CPU 使用量。在这个版本中,OLM 和策略引擎不再冲突,这可以减少 CPU 用量。(BZ#2009233) -
在以前的版本中,如果基本源 CR 中不存在该字段,则
PolicyGenTemplate
overlay 中的用户提供的字段不会被复制到生成的清单中。因此,一些用户内容会丢失。policyGen
工具现已更新,以支持所有用户提供字段。(BZ#2028881) - 在以前的版本中,当在不受支持的平台上安装时,DNS 查找失败可能会导致 Cluster Baremetal Operator 持续失败。在这个版本中,当在不支持的平台上安装时,Operator 会保持禁用状态。(BZ#2025458)
Web 控制台(管理员视角)
Web 控制台 (开发者视角)
- 在此次更新之前,web 控制台的 Developer 视角中的资源具有与该资源相关的信息无效。这个版本解决了这个问题。它创建有效的链接,以便用户可以访问资源详情。(BZ#2000651)
-
在此次更新之前,您只能通过标签在
SinkBinding
表单中指定主题,而不按名称指定。在这个版本中,您可以使用下拉列表来选择按名称或标签指定主题。(BZ#2002266) -
在此次更新之前,只有在您在
openShift-operators
命名空间中安装了 Web Terminal Operator 时,Web 控制台横幅头中才有 Web 终端图标。在这个版本中,无论安装 Web Terminal Operator 的命名空间是什么,都会有终端图标。(2006329) -
在此次更新之前,如果使用
resource
属性而不是kind
属性定义ServiceBinding
自定义资源(CR)时,服务绑定连接器不会出现在拓扑中。在这个版本中,通过读取 CR 的resource
属性来解决此问题,以显示拓扑上的连接器。(BZ#2013545) - 在此次更新之前,名称输入字段使用复杂和递归正则表达式来验证用户输入。这个正则表达式进行名称检测非常慢,通常会导致错误。在这个版本中,通过优化正则表达式并避免递归匹配解决了这个问题。现在,名称检测速度快,不会造成错误。(BZ#2014497)
- 在此次更新之前,knative 插件贡献的一些扩展中缺少功能标记。虽然这个问题不会影响显示的内容,但这些扩展会不必要地运行,即使无服务器 Operator 没有安装。在这个版本中,添加功能标记到缺少它的扩展,从而解决了这个问题。现在,扩展不会有不必要的运行。(BZ#2016438)
-
在此次更新之前,如果您重复点击链接来获取资源详情,(如自定义资源定义或 pod),应用程序遇到多个代码引用错误,它会失败并显示
t is not a function
错误。这个版本解决了这个问题。发生错误时,应用会解析代码引用并存储了解析状态,以便正确处理额外的错误。当代码引用错误发生时,应用程序不再会失败。(BZ#2017130) - 在此次更新之前,具有受限访问权限的用户无法访问其共享命名空间中的配置映射,将其用户设置保存到集群中,并将它们加载到另一个浏览器或机器中。因此,用户首选项(如固定导航项)只会保存在本地浏览器存储中,而不是在多个浏览器之间共享。在这个版本中解决了这个问题:Web 控制台 Operator 会自动创建 RBAC 规则,以便每个用户都可以将这些设置保存到共享命名空间中的配置映射中,并在浏览器之间更轻松地切换。(BZ#2018234)
- 在此次更新之前,试图在 Topology 视图中创建虚拟机(VM)之间的连接会失败,并显示 "Error create connection" 信息。这是因为这个操作依赖于不支持自定义资源定义(CRD)的方法。在这个版本中,通过添加对 CRD 的支持来解决这个问题。现在,您可以创建虚拟机间的连接。(BZ#2020904)
- 在此次更新之前,PipelineRun 详情 中的任务工具会显示误导信息。它显示自任务运行以来经过的时间,而不是运行的时间。例如,对于在 5 天前运行了几分钟的任务,它会显示 122 小时。在这个版本中,工具提示会显示任务的持续时间。(BZ#2011368)