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

第 1 章 托管 control plane 发行注记

发行注记包含有关新的和已弃用的功能、更改以及已知问题的信息。

在这个版本中，托管 control plane 在 OpenShift Container Platform 4.20 中可用。OpenShift Container Platform 4.20 托管 control plane 支持 Kubernetes Operator 版本 2.10 的多集群引擎。

1.1.1. 新功能及功能增强
复制链接

1.1.1.1. 在托管集群中扩展工作负载
复制链接

现在，您只能使用 ScaleUpOnly 行为来扩展工作负载，而无需缩减托管集群中的工作负载。如需更多信息，请参阅在托管集群中扩展工作负载。

1.1.1.2. 在托管集群中扩展和缩减工作负载
复制链接

现在，您可以使用托管的集群中的 ScaleUpAndScaleDown 行为来扩展和缩减工作负载。如需更多信息，请参阅在托管集群中扩展和缩减工作负载。

1.1.1.3. 平衡忽略托管的集群中的标签
复制链接

扩展节点池后，现在可以设置 balancingIgnoredLabels，以便在节点池中均匀分配机器。如需更多信息，请参阅托管集群中的负载平衡忽略的标签。

1.1.1.4. 在托管集群中设置优先级扩展器
复制链接

现在，您可以通过在托管集群中配置优先级扩展器，在低优先级机器前创建高优先级机器。如需更多信息，请参阅在托管集群中设置优先级扩展器。

在这个版本中，在断开连接的环境中的 IBM Z 上托管 control plane 是一个 GA 功能。如需更多信息，请参阅在断开连接的环境中在 IBM Z 上部署托管 control plane。

1.1.2. 程序错误修复
复制链接

  • 在此次更新之前，hc.spec.configuration.apiServer.servingCerts.namedCertificates 中的自定义证书的 SAN 验证无法正确处理通配符 DNS 模式，如 *.example.com。因此，自定义证书中的通配符 DNS 模式可能会与内部 Kubernetes API 服务器证书 SAN 冲突而没有被检测处理，从而导致证书验证失败和潜在的部署问题。此发行版本提供了增强的 DNS SAN 冲突检测，使其包含与 RFC 兼容的通配符支持，实现了可正确处理通配符模式的双向冲突验证，如 *.example.com 与 sub.example.com 匹配。现在，通配符 DNS 模式会被正确验证，防止证书冲突，并确保使用通配符证书支持更可靠的托管集群部署。(OCPBUGS-60381)
  • 在此次更新之前，Azure 云供应商没有为 Azure 负载均衡器设置默认的 ping 目标 HTTP:10256/healthz。相反，在 Azure 上运行的 LoadBalancer 类型的服务具有 TCP:30810 的 ping 目标。因此，集群范围的服务健康探测无法正常工作，在升级过程中会出现停机时间。在这个版本中，云配置的 ClusterServiceLoadBalancerHealthProbeMode 属性设置为 shared。因此，Azure 中的负载均衡器具有正确的健康检查 ping 目标 HTTP:10256/healthz，它指向节点上运行的 kube-proxy 健康端点。(OCPBUGS-58031)
  • 在此次更新之前，HyperShift Operator 在从 HostedCluster 资源中删除 additionalTrustBundle 参数后无法清除 user-ca-bundle 配置映射。因此，user-ca-bundle 配置映射没有更新，从而导致无法生成 ignition 有效负载。在这个版本中，当从 HostedCluster 资源中删除时，HyperShift Operator 会主动从 control plane 命名空间中删除 user-ca-bundle 配置映射。现在，user-ca-bundle 配置映射会被正确清除，启用生成 ignition 有效负载。(OCPBUGS-57336)
  • 在此次更新之前，如果您试图在 AWS 上创建托管集群，当 Kubernetes API 服务器服务发布策略是带有 PublicAndPrivate 端点访问的 LoadBalancer 时，私有路由器接受 OAuth 路由，即使 External DNS Operator 没有注册 DNS 记录。因此，私有路由器没有正确解析路由 URL，OAuth 服务器无法访问。Console Cluster Operator 也无法启动，托管集群安装失败。在这个版本中，私有路由器仅在定义了外部 DNS 时接受 OAuth 路由。否则，路由器接受管理集群中的路由。因此，可以访问 OAuth 路由，Console Cluster Operator 可以正确地启动，托管集群安装可以成功。(OCPBUGS-56914)
  • 在以前的版本中，当管理 OpenShift 集群中的 IDMS 或 ICSP 定义了指向 registry.redhat.io 或 registry.redhat.io/redhat 的源时，镜像 registry 不包含所需的 OLM 目录镜像，因为未授权镜像拉取而停止对 HostedCluster 资源的置备。因此，HostedCluster 资源没有被部署，它会被阻断，其中无法从镜像 registry 中拉取基本目录镜像。在这个版本中，如果因为授权错误而无法拉取所需的镜像，置备现在会明确失败。改进了 registry 覆盖的逻辑，允许在 registry 的根目录（如 registry.redhat.io ）上匹配，用于 OLM CatalogSource 镜像解析。如果 registry 覆盖没有生成可正常工作的镜像，还会引入回退机制来使用原始 ImageReference。因此，可以成功部署 HostedCluster 资源，即使镜像 registry 缺少所需的 OLM 目录镜像，因为系统在适当的时候可以正确地回退到原始源拉取。(OCPBUGS-56492)
  • 在此次更新之前，AWS 云供应商没有为 AWS 负载均衡器设置默认的 ping 目标 HTTP:10256/healthz。对于在 AWS 上运行的 LoadBalancer 类型的服务，在 AWS 中创建的负载均衡器对象有一个 TCP:32518 的 ping 目标。因此，集群范围的服务健康探测无法正常工作，在升级过程中，这些服务会停机。在这个版本中，云配置的 ClusterServiceLoadBalancerHealthProbeMode 属性设置为 Shared。此云配置传递给 AWS Cloud Provider。因此，AWS 中的负载均衡器具有正确的健康检查 ping 目标 HTTP:10256/healthz，它指向节点上运行的 kube-proxy 健康端点。(OCPBUGS-56011)
  • 在此次更新之前，当使用 --disable-cluster-capabilities 选项禁用镜像 registry 功能时，托管 control plane 仍需要您为镜像 registry 配置受管身份。在本发行版本中，当禁用镜像 registry 时，镜像 registry 管理的身份配置是可选的。(OCPBUGS-55892)
  • 在此次更新之前，会处理来自管理集群的 ImageDigestMirrorSet (IDMS)和 ImageContentSourcePolicy (ICSP)资源，而无需考虑将 root registry 名称指定为镜像替换的镜像或源。因此，只使用 root registry 名称的 IDMS 和 ICSP 条目无法按预期工作。在本发行版本中，镜像替换逻辑可以正确地处理只提供 root registry 名称的情况。因此，这个问题不再发生，现在支持 root registry 镜像替换。(OCPBUGS-54483)
  • 在此次更新之前，托管的 control plane 无法正确持久保留 HostedCluster 资源中的 registry 元数据以及发行镜像供应商缓存。因此，发行和镜像原始的缓存会在 HostedCluster 控制器协调时被重置。此发行版本引入了一个通用的 registry 供应商，它供 HostedCluster 资源用于修复缓存丢失的问题。这可减少镜像拉取和网络流量的数量，从而提高了整体性能。(OCPBUGS-53259)
  • 在此次更新之前，当使用没有指定客户端 secret 的 OIDC 客户端为 HostedCluster 资源配置 OIDC 供应商时，系统会自动生成默认 secret 名称。因此，您无法配置 OIDC 公共客户端，它们不应该使用 secret。此发行版本解决了这个问题。如果没有提供客户端 secret，则不会生成默认的 secret 名称，从而启用对公共客户端的正确支持。(OCPBUGS-58149)
  • 在此次更新之前，会因为镜像查找失败，多个 mirror 镜像会导致托管的 control plane 有效负载错误。因此，用户无法创建托管集群。在这个版本中，托管 control plane 有效负载支持多个 mirror，避免在主 mirror 不可用时出现错误。因此，用户可以创建托管集群。(OCPBUGS-54720)

  • 在此次更新之前，当托管集群一次升级到多个版本时，HostedCluster 资源中的版本历史记录有时会超过 10 个条目。但是，API 对于版本历史记录字段的最大为 10 个项的验证限制。因此，当版本历史记录超过 10 个条目时，用户无法编辑或更新其 HostedCluster 资源。添加注解等操作（例如，集群大小覆盖）或执行维护任务等操作（如重新定义 request serving 节点大小）会失败，并显示验证错误： "status.version.history: Too many: 11: must have at most 10 items"。这个错误阻止 ROSA SREs 执行可能会影响客户 API 访问的关键维护操作。

    在这个版本中，最大项目验证约束已从 HostedCluster API 中的版本历史记录字段中删除，允许历史记录在没有触发验证错误的情况下增长超过 10 个条目。现在，无论版本历史记录中存在多少个条目，可以编辑和更新 HostedCluster 资源，以便管理员可以对有多个版本升级的集群执行必要的维护操作。(OCPBUGS-58200)

  • 在此次更新之前，在 CLI 重构后，MarkPersistentFlagRequired 函数停止正常工作。--name 和 --pull-secret 标志（它们对于集群的创建非常关键）被标记为是必需的，但并没有强制进行验证。因此，用户可以在没有提供必需的 --name 或 --pull-secret 标志的情况下运行 hypershift create cluster 命令，CLI 不会立即警告缺少这些所需标记。这可能会导致部署配置错误，并在稍后出现混淆的消息。

    此发行版本在 RawCreateOptions.Validate() 函数中添加了一个明确的验证过程，以检查是否存在 --name 和 --pull-secret 标志，在缺少任一标记时返回清晰的错误消息。另外，默认的 "example" 值已从 name 字段中删除，以确保正确验证。因此，当用户试图在没有使用必需的 --name 或 --pull-secret 标志的情况下创建集群时会立即接收到清晰的错误信息，声明缺少了哪个所需的标志（例如 "Error: --name is required" 或 "Error: --pull-secret is required"），这可以防止错误配置部署并改进用户体验。(OCPBUGS-37323)

  • 在此次更新之前，在 GetSupportedOCPVersions() 函数中有一个变量 shadowing 的错误，这会导致 supportedVersions 变量被错误地分配使用 := 而不是 =，创建一个本地变化会被立即丢弃，而不是更新预期的外部范围变量。因此，当用户运行 hypershift version 并部署了 HyperShift Operator 时，CLI 可能会为 Server Version 显示 <unknown>；或出现带有 "nil pointer dereference" 错误的 panic，导致用户无法验证部署的 HyperShift Operator 版本。

    此发行版本在 GetSupportedOCPVersions() 中将 supportedVersions := 更正为 supportedVersions = 以将配置映射正确地分配给外部范围变量，确保正确生成支持的版本数据。现在，当 HyperShift Operator 被部署时，hypershift version 命令可以正确地显示 Server Version （例如："Server Version: f001510b35842df352d1ab55d961be3fdc2dae32"），因此用户可以验证正在运行的 Operator 版本以及支持的 OpenShift Container Platform 版本。(OCPBUGS-57316)

  • 在此次更新之前，HyperShift Operator 在所有情况下都会验证 Kubernetes API 服务器主题替代名称(SAN)。因此，用户有时会在公钥基础架构(PKI)协调过程中遇到无效的 API 服务器 SAN。在这个版本中，只有在没有禁用 PKI 协调时，Kubernetes API Server SAN 才会被验证。(OCPBUGS-56457)

  • 在此次更新之前，共享入口控制器不会处理 HostedCluster.Spec.KubeAPIServerDNSName 字段，因此自定义 kube-apiserver DNS 名称不会添加到路由器配置中。因此，到使用自定义 DNS 名称的托管 control plane 上的 kube-apiserver 的流量无法被正确路由（通过 HostedCluster.Spec.KubeAPIServerDNSName），导致来自使用共享 ingress 的平台的 KubeAPIExternalName 功能无法正常工作。

    此发行版本添加了对共享入口控制器中的 HostedCluster.Spec.KubeAPIServerDNSName 的处理。当托管集群指定自定义 kube-apiserver DNS 名称时，控制器现在会自动创建一个将流量定向到 kube-apiserver 服务的路由。因此，为自定义 kube-apiserver DNS 名称的流量现在可以由共享入口控制器正确路由，启用 KubeAPIExternalName 功能在使用共享入口的平台上正常工作。(OCPBUGS-57790)

1.1.3. 已知问题
复制链接

  • 如果注解和 ManagedCluster 资源名称不匹配，Kubernetes Operator 控制台的多集群引擎会显示集群为 Pending import。多集群引擎 Operator 无法使用集群。当没有注解且 ManagedCluster 名称与 HostedCluster 资源的 Infra-ID 值不匹配时，会出现同样的问题。
  • 当使用 multicluster engine for Kubernetes Operator 控制台将新节点池添加到现有托管集群时，相同的 OpenShift Container Platform 版本可能会在选项列表中出现多次。您可以在列表中为您想要的版本选择任何实例。

  • 当节点池缩减为 0 个 worker 时，控制台中的主机列表仍然会显示处于 Ready 状态的节点。您可以通过两种方式验证节点数：

    • 在控制台中，进入节点池并验证它是否有 0 个节点。

    • 在命令行界面中运行以下命令：

      • 运行以下命令，验证有 0 个节点在节点池中： 

        $ oc get nodepool -A
        Copy to Clipboard Toggle word wrap

      • 运行以下命令验证集群中有 0 个节点： 

        $ oc get nodes --kubeconfig
        Copy to Clipboard Toggle word wrap

      • 运行以下命令验证报告了 0 个代理被绑定到集群： 

        $ oc get agents -A
        Copy to Clipboard Toggle word wrap
  • 当您在使用双栈网络的环境中创建托管集群时，您可能会遇到 pod 处于 ContainerCreating 状态。出现这个问题的原因是 openshift-service-ca-operator 资源无法生成 DNS pod 需要的 metrics-tls secret。因此，pod 无法解析 Kubernetes API 服务器。要解决这个问题，请配置双栈网络的 DNS 服务器设置。

  • 如果您在与其受管集群相同的命名空间中创建了托管集群，分离受管集群会删除受管集群命名空间中的所有集群（包括托管集群）。以下情况会在与受管集群相同的命名空间中创建托管集群：

    • 已使用默认托管集群集群命名空间，通过 multicluster engine for Kubernetes Operator 控制台在 Agent 平台上创建托管集群。
    • 您可以通过命令行界面或 API 创建托管集群，方法是将指定托管的集群命名空间指定为与托管集群名称相同。
  • 当您使用 console 或 API 为托管集群的 spec.services.servicePublishingStrategy.nodePort.address 字段指定 IPv6 地址时，需要一个带有 8 个八进制数字的完整的 IPv6 地址。例如，您需要指定 2620:52:0:1306:0:0:0:30，而不是 2620:52:0:1306::30。

1.1.4. 正式发行(GA)和技术预览功能
复制链接

此版本中的一些功能当前还处于技术预览状态。它们并不适用于在生产环境中使用。有关这些功能支持范围的更多信息，请参阅红帽客户门户网站中的技术预览功能支持范围。

重要

对于 IBM Power 和 IBM Z，会有以下例外：

  • 对于版本 4.20 及更新的版本，您必须在基于 64 位 x86 架构或 s390x 架构的机器类型上运行 control plane，以及在 IBM Power 或 IBM Z 上的节点池。
  • 对于版本 4.19 及更早版本，您必须在基于 64 位 x86 架构的机器类型以及 IBM Power 或 IBM Z 上的节点池上运行 control plane。
Expand
表 1.1. 托管 control plane GA 和 TP tracker
功能4.184.194.20

使用非裸机代理机器托管 OpenShift Container Platform 的 control plane

技术预览

技术预览

技术预览

在 RHOSP 上托管 OpenShift Container Platform 的 control plane

开发者预览

技术预览

技术预览

自定义污点和容限

技术预览

技术预览

技术预览

托管 control plane for OpenShift Virtualization 上的 NVIDIA GPU 设备

技术预览

技术预览

技术预览

在断开连接的环境中在 IBM Z 上托管 control plane

技术预览

技术预览

正式发布

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat