第 1 章 托管 control plane 发行注记


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

1.1. OpenShift Container Platform 4.17 托管 control plane 发行注记

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

1.1.1. 新功能及功能增强

此版本对以下方面进行了改进:

1.1.1.1. 自定义污点和容限(技术预览)

对于 OpenShift Virtualization 上的托管 control plane,现在可以使用 hcp CLI -tolerations 参数或使用 hc.Spec.Tolerations API 文件将容限应用到托管的 control plane pod。此功能作为技术预览功能提供。如需更多信息,请参阅自定义污点和容限

1.1.1.2. 支持 OpenShift Virtualization 上的 NVIDIA GPU 设备(技术预览)

对于 OpenShift Virtualization 上的托管 control plane,您可以将一个或多个 NVIDIA 图形处理单元(GPU)设备附加到节点池。此功能作为技术预览功能提供。如需更多信息,请参阅使用 hcp CLI 附加 NVIDIA GPU 设备,并使用 NodePool 资源附加 NVIDIA GPU 设备

1.1.1.3. 支持 AWS 上的租期

当您在 AWS 上创建托管集群时,您可以指定 EC2 实例是否应该在共享或单租户硬件上运行。如需更多信息,请参阅在 AWS 上创建托管集群

1.1.1.4. 支持托管的集群中的 OpenShift Container Platform 版本

您可以在托管集群中部署一系列支持的 OpenShift Container Platform 版本。如需更多信息,请参阅 托管集群中的支持的 OpenShift Container Platform 版本

1.1.1.5. 在断开连接的环境中的 OpenShift Virtualization 上托管 control plane 正式发布

在本发行版本中,在断开连接的环境中的 OpenShift Virtualization 上托管 control plane 正式发布。如需更多信息,请参阅 在断开连接的环境中在 OpenShift Virtualization 上部署托管 control plane

1.1.1.6. 在 AWS 上为 ARM64 OpenShift Container Platform 集群托管 control plane 已正式发布

在本发行版本中,AWS 上的 ARM64 OpenShift Container Platform 集群的托管 control plane 正式发布。如需更多信息,请参阅在 ARM64 架构上运行托管集群

1.1.1.7. IBM Z 上的托管 control plane 正式发布

在本发行版本中,IBM Z 上的托管 control plane 正式发布。如需更多信息,请参阅在 IBM Z 上部署托管 control plane

1.1.1.8. IBM Power 上的托管 control plane 正式发布

在本发行版本中,IBM Power 上的托管 control plane 正式发布。如需更多信息,请参阅在 IBM Power 上部署托管 control plane

1.1.2. 程序错误修复

  • 在以前的版本中,当配置托管集群代理并使用具有 HTTP 或 HTTPS 端点的身份提供程序 (IDP) 时,IDP 的主机名在通过代理发送它前没有被解决。因此,只能由 data plane 解析的主机名无法为 IDP 解析。在这个版本中,在通过 konnectivity 隧道发送 IPD 流量前会执行 DNS 查找。因此,Control Plane Operator 可以验证只能由 data plane 解析的主机名的 IDP。(OCPBUGS-41371)
  • 在以前的版本中,当托管集群 controllerAvailabilityPolicy 设置为 SingleReplica 时,网络组件的podAntiAffinity 会阻止组件的可用性。在这个版本中,这个问题已解决。(OCPBUGS-39313)
  • 在以前的版本中,在托管集群镜像配置中指定的 AdditionalTrustedCA 不会被协调到 openshift-config 命名空间中,image-registry-operator 的预期,且组件不可用。在这个版本中,这个问题已解决。(OCPBUGS-39225)
  • 在以前的版本中,因为对核心操作系统的更改,Red Hat HyperShift 定期合规作业会失败。这些失败的作业会导致 OpenShift API 部署失败。在这个版本中,更新会递归复制单独的可信证书颁发机构(CA)证书,而不是复制单个文件,因此定期一致性作业会成功,OpenShift API 会按预期运行。(OCPBUGS-38941)
  • 在以前的版本中,托管集群中的 Konnectity 代理代理总是通过 HTTP/S 代理发送所有 TCP 流量。它还会忽略 NO_PROXY 配置中的主机名,因为它仅在其流量中接收解析的 IP 地址。因此,无论配置是什么,不应被代理的流量(如 LDAP 流量)都会被代理。在这个版本中,代理会在源 (control plane) 中完成,在 Konnectity 代理中的代理配置被删除。因此,不应被代理的流量(如 LDAP 流量)不再被代理。满足包含主机名的 NO_PROXY 配置。(OCPBUGS-38637)
  • 在以前的版本中,在使用 registryOverride 时,azure-disk-csi-driver-controller 镜像不会获得适当的覆盖值。这是有意设计的,以避免将值传播到 azure-disk-csi-driver data plane 镜像。在这个版本中,通过添加单独的镜像覆盖值来解决这个问题。因此,azure-disk-csi-driver-controller 可以与 registryOverride 一起使用,不再影响 azure-disk-csi-driver data plane 镜像。(OCPBUGS-38183)
  • 在以前的版本中,在代理管理集群上运行的托管 control plane 中的 AWS 云控制器管理器不会将代理用于云 API 通信。在这个版本中,这个问题已被解决。(OCPBUGS-37832)
  • 在以前的版本中,在托管集群的 control plane 中运行的 Operator 代理是通过在 data plane 中运行的 Konnectity 代理 pod 上的代理设置执行的。无法区分需要基于应用程序协议的代理。

    对于 OpenShift Container Platform 的奇偶校验,通过 HTTPS 或 HTTP 的 IDP 通信应该会被代理,但 LDAP 通信不应被代理。这种类型的代理还忽略依赖于主机名的 NO_PROXY 条目,因为通过时间流量到达 Konnectity 代理,只有目标 IP 地址可用。

    在这个版本中,在托管的集群中,通过 konnectivity-https-proxykonnectivity-socks5-proxy 在 control plane 中调用代理,代理流量会从 Konnectivity 代理停止。因此,针对 LDAP 服务器的流量不再会被代理。其他 HTTPS 或 HTTPS 流量被正确代理。指定主机名时,会遵守 NO_PROXY 设置。(OCPBUGS-37052)

  • 在以前的版本中,Konnectity 代理中发生 IDP 通信的代理。通过时间流量达到 Konnectivity,其协议和主机名不再可用。因此,OAUTH 服务器 pod 无法正确进行代理。它无法区分需要代理的协议 (http/s) 和不需要代理的协议 (ldap://)。另外,它不遵循 HostedCluster.spec.configuration.proxy spec 中配置的 no_proxy 变量。

    在这个版本中,您可以在 OAUTH 服务器的 Konnectity sidecar 上配置代理,以便正确路由流量,并遵循您的 no_proxy 设置。因此,当为托管集群配置代理时,OAUTH 服务器可以与身份提供程序正确通信。(OCPBUGS-36932)

  • 在以前的版本中,在从 HostedCluster 对象中删除 ImageContentSources 字段后,托管 Cluster Config Operator (HCCO)不会删除 ImageDigestMirrorSet CR (IDMS)。因此,当 IDMS 不应该被保留在 HostedCluster 对象中,IDMS 会保留。在这个版本中,HCCO 管理从 HostedCluster 对象中删除 IDMS 资源。(OCPBUGS-34820)
  • 在以前的版本中,在断开连接的环境中部署 hostedCluster 需要设置 hypershift.openshift.io/control-plane-operator-image 注解。在这个版本中,不再需要注解。另外,元数据检查器在托管 Operator 协调过程中可以正常工作,OverrideImages 会如预期填充。(OCPBUGS-34734)
  • 在以前的版本中,AWS 上的托管集群利用其 VPC 的主 CIDR 范围在 data plane 上生成安全组规则。因此,如果您将托管集群安装到具有多个 CIDR 范围的 AWS VPC 中,则生成的安全组规则可能不足。在这个版本中,安全组规则根据提供的机器 CIDR 范围生成,解决了这个问题。(OCPBUGS-34274)
  • 在以前的版本中,OpenShift Cluster Manager 容器没有正确的 TLS 证书。因此,您无法在断开连接的部署中使用镜像流。在这个版本中,TLS 证书作为投射卷添加,解决了这个问题。(OCPBUGS-31446)
  • 在以前的版本中,OpenShift Virtualization 的 Kubernetes Operator 控制台的多集群引擎中的 bulk destroy 选项不会销毁托管集群。在这个版本中,这个问题已解决。(ACM-10165)

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
      • 运行以下命令验证集群中的 0 个节点:

        $ oc get nodes --kubeconfig
      • 运行以下命令验证 0 代理是否已报告为绑定到集群:

        $ oc get agents -A
  • 当您在使用双栈网络的环境中创建托管集群时,您可能会遇到以下与 DNS 相关的问题:

    • service-ca-operator pod 中的 CrashLoopBackOff 状态:当 pod 试图通过托管的 control plane 访问 Kubernetes API 服务器时,pod 无法访问服务器,因为 kube-system 命名空间中的 data plane 代理无法解析请求。出现这个问题的原因是,前端使用 IP 地址,后端使用 pod 无法解析的 DNS 名称。
    • Pod 处于 ContainerCreating 状态 :出现这个问题,因为 openshift-service-ca-operator 无法生成 DNS pod 需要 DNS 解析的 metrics-tls secret。因此,pod 无法解析 Kubernetes API 服务器。要解决这些问题,请配置双栈网络的 DNS 服务器设置。
  • 在 Agent 平台上,托管 control plane 功能定期轮转 Agent 用来拉取 ignition 的令牌。因此,如果您有一个创建一段时间的 Agent 资源,它可能无法拉取 ignition。作为临时解决方案,在 Agent 规格中,删除 IgnitionEndpointTokenReference 属性的 secret,然后在 Agent 资源上添加或修改任何标签。系统使用新令牌重新创建 secret。
  • 如果您在与其受管集群相同的命名空间中创建了托管集群,分离受管集群会删除受管集群命名空间中的所有所有集群(包括托管集群)。以下情况可在与受管集群相同的命名空间中创建托管集群:

    • 已使用默认托管集群集群命名空间,通过 multicluster engine for Kubernetes Operator 控制台在 Agent 平台上创建托管集群。
    • 您可以通过命令行界面或 API 创建托管集群,方法是指定托管集群命名空间与托管集群名称相同。

1.1.4. 正式发布(GA)和技术预览(TP)功能

正式发布(GA)的功能被完全支持,并适用于生产环境。技术预览功能为实验性功能,不适用于生产环境。有关 TP 功能的更多信息,请参阅红帽客户门户网站中的支持范围

下表了解托管 control plane GA 和 TP 功能:

表 1.1. 托管 control plane GA 和 TP tracker
功能4.154.164.17

在 Amazon Web Services (AWS) 上托管 OpenShift Container Platform 的 control plane。

技术预览

正式发布

正式发布

在裸机上托管 OpenShift Container Platform 的 control plane

公开发行

公开发行

公开发行

在 OpenShift Virtualization 上为 OpenShift Container Platform 托管 control plane

正式发布

正式发布

正式发布

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

技术预览

技术预览

技术预览

在 Amazon Web Services 上为 ARM64 OpenShift Container Platform 集群托管 control plane

技术预览

技术预览

正式发布

在 IBM Power 上托管 OpenShift Container Platform 的 control plane

技术预览

技术预览

正式发布

在 IBM Z 上托管 OpenShift Container Platform 的 control plane

技术预览

技术预览

正式发布

在 RHOSP 上托管 OpenShift Container Platform 的 control plane

不可用

不可用

开发者预览

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.