搜索

第 1 章 带有多集群引擎 operator 的集群生命周期概述

download PDF

multicluster engine operator 是集群生命周期 Operator,它为 OpenShift Container Platform 和 Red Hat Advanced Cluster Management hub 集群提供集群管理功能。在 hub 集群中,您可以创建和管理集群,也可以销毁您创建的任何集群。您还可以休眠、恢复和分离集群。从以下文档了解更多有关集群生命周期功能的信息。

访问 支持列表,了解 hub 集群和受管集群要求和支持。

信息:

集群生命周期管理架构的组件包括在集群生命周期架构中。

1.1. 发行注记

了解当前版本。

注: Red Hat Advanced Cluster Management 的 2.6 和更早的版本已 从服务中删除,且不再被支持。2.6 及更早的版本文档没有更新。其文档可能仍然可用,但不再有任何新的勘误或其他更新。

如果您在当前支持的版本或产品文档时遇到问题,请访问 红帽支持,您可以在其中进行故障排除、查看知识库文章、与支持团队连接或创建一个问题单。您必须使用您的凭证登录。

您还可以访问红帽客户门户文档,Red Hat Customer Portal FAQ

1.1.1. multicluster engine operator 的集群生命周期新功能

重要:一些功能和组件作为技术预览发布。

了解更多本发行版本的新内容:

1.1.1.1. 集群生命周期

了解与 multicluster engine operator 的集群生命周期有关的新新功能。

1.1.1.2. 凭证

  • 现在,您可以使用集成的控制台在 VMware vSphere 上为断开连接的安装配置 Cluster OS image 字段来创建凭证。如需更多信息 ,请参阅使用控制台管理凭证

1.1.1.3. 托管 control plane

1.1.1.4. Red Hat Advanced Cluster Management 集成

如果在安装 Red Hat Advanced Cluster Management 后启用 Observability,您可以使用 Grafana 仪表板查看托管的 control plane 集群容量估计以及现有的托管的 control plane 资源使用率。请参阅 Red Hat Advanced Cluster Management 集成

1.1.2. 已知的与集群生命周期相关的问题

查看 multicluster engine operator 的集群生命周期的已知问题。以下列表包含本发行版本的已知问题,或从上一版本中继承的问题。对于 OpenShift Container Platform 集群,请参阅 OpenShift Container Platform 发行注记

1.1.2.1. 集群管理

集群生命周期已知问题和限制是 multicluster engine operator 文档的集群生命周期的一部分。

1.1.2.1.1. nmstate的限制

通过配置复制和粘贴功能来加快开发速度。要在 assisted-installer 中配置 copy-from-mac 功能,您必须将 mac-address 添加到 nmstate 定义接口和 mac-mapping 接口。mac-mapping 接口在 nmstate 定义接口之外提供。因此,您必须提供相同的 mac-address 两次。

1.1.2.1.2. prehook 失败不会出现托管集群创建失败

如果您使用自动化模板来创建托管集群,并且 prehook 任务失败,则托管集群创建仍然正在进行。这是正常的,因为托管集群的设计没有完全失败状态,因此它会继续尝试创建集群。

1.1.2.1.3. 删除附加组件时,手动删除受管集群上所需的 VolSync CSV

当您从 hub 集群中删除 VolSync ManagedClusterAddOn 时,它会删除受管集群上的 VolSync operator 订阅,但不会删除集群服务版本(CSV)。要从受管集群中删除 CSV,请在您要删除 VolSync 的每个受管集群中运行以下命令:

oc delete csv -n openshift-operators volsync-product.v0.6.0

如果您安装了不同版本的 VolSync,请将 v0.6.0 替换为您的安装版本。

1.1.2.1.4. 删除受管集群集不会自动删除其标签

删除 ManagedClusterSet 后,添加到每个受管集群的标签不会被自动删除。从已删除受管集群集中包含的每个受管集群手动删除该标签。该标签类似以下示例:cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name>

1.1.2.1.5. ClusterClaim 错误

如果您针对 ClusterPool 创建 Hive ClusterClaim 并手动将 ClusterClaimspec 生命周期字段设置为无效的 golang 时间值,则产品将停止实现并协调所有 ClusterClaims,而不仅仅是不正确的声明。

如果发生这个错误,您可以在 clusterclaim-controller pod 日志中看到以下内容,它是一个带有池名称和无效生命周期的特定示例:

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

您可以删除无效的声明。

如果删除了不正确的声明,则声明可以在不需要进一步交互的情况下再次成功进行协调。

1.1.2.1.6. 产品频道与置备的集群不同步

clusterimageset 处于 fast 频道,但置备的集群处于 stable 频道。目前,产品不会将 频道 同步到置备的 OpenShift Container Platform 集群。

进入 OpenShift Container Platform 控制台中的正确频道。点 Administration > Cluster Settings > Details Channel

1.1.2.1.7. 使用自定义 CA 证书恢复到其恢复的 hub 集群连接可能会失败

恢复受管集群使用自定义 CA 证书的 hub 集群的备份后,受管集群和 hub 集群之间的连接可能会失败。这是因为在恢复的 hub 集群上没有备份 CA 证书。要恢复连接,将受管集群的命名空间中自定义 CA 证书信息复制到恢复的 hub 集群上的 <managed_cluster>-admin-kubeconfig secret。

提示: 如果您在创建备份副本前将此 CA 证书复制到 hub 集群,备份副本会包括 secret 信息。当使用备份副本来恢复时,hub 和受管集群之间的连接会自动完成。

1.1.2.1.8. local-cluster 可能无法自动重新创建

如果在 disableHubSelfManagement 被设置为 false 时删除 local-cluster,则 MulticlusterHub operator 会重新创建 local-cluster。分离 local-cluster 后,可能不会自动重新创建 local-cluster。

  • 要解决这个问题,修改由 MulticlusterHub operator 监控的资源。请参见以下示例:

    oc delete deployment multiclusterhub-repo -n <namespace>
  • 要正确分离 local-cluster,在 MultiClusterHub 中将 disableHubSelfManagement 设置为 true。
1.1.2.1.9. 在创建内部集群时需要选择子网

使用控制台创建内部集群时,您必须为集群选择一个可用的子网。它没有标记为必填字段。

1.1.2.1.10. 使用 Infrastructure Operator 进行集群置备失败

当使用 Infrastructure Operator 创建 OpenShift Container Platform 集群时,ISO 镜像的文件名可能会太长。镜像名称长会导致镜像置备和集群置备失败。要确定这是否是问题,请完成以下步骤:

  1. 运行以下命令,查看您要置备的集群的裸机主机信息:

    oc get bmh -n <cluster_provisioning_namespace>
  2. 运行 describe 命令以查看错误信息:

    oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
  3. 类似以下示例的错误表示文件名的长度问题:

    Status:
      Error Count:    1
      Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...

如果出现问题,通常位于以下 OpenShift Container Platform 版本上,因为基础架构操作员不使用镜像服务:

  • 4.8.17 及更早版本
  • 4.9.6 及更早版本

为了避免这个错误,将 OpenShift Container Platform 升级到 4.8.18 或更高版本,或 4.9.7 或更高版本。

1.1.2.1.11. 使用不同名称重新导入后 local-cluster 状态为离线

当您意外尝试以不同名称的集群形式重新导入名为 local-cluster 的集群时,local-cluster 和重新导入的集群的状态将 离线

要从这个问题单中恢复,请完成以下步骤:

  1. 在 hub 集群中运行以下命令,以临时编辑 hub 集群的自助管理设置:

    oc edit mch -n open-cluster-management multiclusterhub
  2. 添加 spec.disableSelfManagement=true 设置。
  3. 在 hub 集群中运行以下命令以删除并重新部署 local-cluster:

    oc delete managedcluster local-cluster
  4. 输入以下命令删除 local-cluster 管理设置:

    oc edit mch -n open-cluster-management multiclusterhub
  5. 删除之前添加的 spec.disableSelfManagement=true
1.1.2.1.12. 在代理环境中使用 Ansible 自动化进行集群置备失败

当满足以下条件时,配置为自动置备受管集群的 Automation 模板可能会失败:

  • hub 集群启用了集群范围代理。
  • Ansible Automation Platform 只能通过代理访问。
1.1.2.1.13. klusterlet Operator 的版本必须与 hub 集群相同

如果您通过安装 klusterlet operator 导入受管集群,klusterlet Operator 的版本必须与 hub 集群的版本相同,或者 klusterlet Operator 将无法正常工作。

1.1.2.1.14. 无法手动删除受管集群命名空间

您无法手动删除受管集群的命名空间。受管集群命名空间会在受管集群分离后自动删除。如果在分离受管集群前手动删除受管集群命名空间,受管集群会在删除受管集群后显示持续终止状态。要删除此正在终止的受管集群,请从分离的受管集群中手动删除终结器。

1.1.2.1.15. hub 集群和受管集群的时钟未同步

hub 集群和管理集群的时间可能会不同步,在控制台中显示 unknown,当在几分钟内会变为 available。确保正确配置了 OpenShift Container Platform hub 集群时间。请参阅自定义节点

1.1.2.1.16. 不支持导入 IBM OpenShift Container Platform Kubernetes Service 集群的特定版本

您无法导入 IBM OpenShift Container Platform Kubernetes Service 版本 3.11 集群。支持 IBM OpenShift Kubernetes Service 的更新的版本。

1.1.2.1.17. 不支持为置备的集群进行自动 secret 更新

当您在云供应商一端更改云供应商访问密钥时,您还需要在 multicluster engine operator 的控制台中更新此云供应商的对应凭证。当凭证在托管受管集群的云供应商过期并尝试删除受管集群时,需要此项。

1.1.2.1.19. 销毁集群的进程没有完成

当销毁受管集群时,在一小时后仍然继续显示 Destroying 状态,且集群不会被销毁。要解决这个问题请完成以下步骤:

  1. 手动确保云中没有孤立的资源,,且清理与受管集群关联的所有供应商资源。
  2. 输入以下命令为正在删除的受管集群打开 ClusterDeployment

    oc edit clusterdeployment/<mycluster> -n <namespace>

    mycluster 替换为您要销毁的受管集群的名称。

    使用受管集群的命名空间替换 namespace

  3. 删除 hive.openshift.io/deprovision finalizer,以强制停止尝试清理云中的集群资源的进程。
  4. 保存您的更改,验证 ClusterDeployment 是否已不存在。
  5. 运行以下命令手动删除受管集群的命名空间:

    oc delete ns <namespace>

    使用受管集群的命名空间替换 namespace

1.1.2.1.20. 无法使用控制台在 OpenShift Container Platform Dedicated 上升级 OpenShift Container Platform 受管集群

您不能使用 Red Hat Advanced Cluster Management 控制台升级 OpenShift Container Platform Dedicated 环境中的 OpenShift Container Platform 受管集群。

1.1.2.1.22. 升级后,非 Red Hat OpenShift Container Platform 受管集群需要 ManagedServiceAccountLoadBalancer 用于 pod 日志

如果您使用全新的 Red Hat Advanced Cluster Management 2.10 或更新版本安装,Red Hat OpenShift Container Platform 和非 OpenShift Container Platform 集群都支持 pod 日志功能。

如果从 Red Hat Advanced Cluster Management 2.9 升级到 2.10,您必须手动启用 ManagedServiceAccount 附加组件,以便在非 OpenShift Container Platform 受管集群中使用 pod 日志功能。请参阅 ManagedServiceAccount 附加组件 以了解如何启用 ManagedServiceAccount

另外,您可以使用 LoadBalancer 而不是 ManagedServiceAccount 在非 OpenShift Container Platform 受管集群中启用 pod 日志功能。

完成以下步骤以启用 LoadBalancer

  1. 云供应商有不同的 LoadBalancer 配置。有关更多信息,请访问您的云供应商文档。
  2. 检查 loggingEndpoint 是否显示 managedClusterInfo 状态来验证 Red Hat Advanced Cluster Management 上是否启用了 LoadBalancer
  3. 运行以下命令,以检查 loggingEndpoint.IPloggingEndpoint.Host 是否具有有效的 IP 地址或主机名:

    oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'

如需有关 LoadBalancer 类型的更多信息,请参阅 Kubernetes 文档中的 Service 页面。

1.1.2.1.23. OpenShift Container Platform 4.10.z 不支持使用代理配置托管的 control plane 集群

当您在 OpenShift Container Platform 4.10.z 上使用集群范围代理配置创建托管服务集群时,nodeip-configuration.service 服务不会在 worker 节点上启动。

1.1.2.1.24. 无法在 Azure 上置备 OpenShift Container Platform 4.11 集群

因为身份验证 operator 超时错误,在 Azure 上置备 OpenShift Container Platform 4.11 集群会失败。要临时解决这个问题,在 install-config.yaml 文件中使用不同的 worker 节点类型,或者将 vmNetworkingType 参数设置为 Basic。请参阅以下 install-config.yaml 示例:

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'
1.1.2.1.25. 客户端无法访问 iPXE 脚本

iPXE 是开源网络引导固件。如需了解更多详细信息,请参阅 iPXE

引导节点时,一些 DHCP 服务器中的 URL 长度限制会关闭 InfraEnv 自定义资源定义中的 ipxeScript URL,从而导致在控制台中的以下错误消息:

no bootable devices

要临时解决这个问题,请完成以下步骤:

  1. 在使用辅助安装时应用 InfraEnv 自定义资源定义以公开 bootArtifacts,它可能类似以下文件:

    status:
      agentLabelSelector:
        matchLabels:
          infraenvs.agent-install.openshift.io: qe2
      bootArtifacts:
        initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
        ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
        kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-kernel-x86_64
        rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-rootfs.x86_64.img
  2. 创建代理服务器以使用短 URL 公开 bootArtifacts
  3. 运行以下命令复制 bootArtifacts 并将其添加到代理中:

    for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
    do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact
  4. ipxeScript 工件代理 URL 添加到 libvirt.xml 中的 bootp 参数。
1.1.2.1.26. 升级 Red Hat Advanced Cluster Management 后无法删除 ClusterDeployment

如果您在 Red Hat Advanced Cluster Management 2.6 中使用已删除的 BareMetalAssets API,则在升级到 Red Hat Advanced Cluster Management 2.7 后无法删除 ClusterDeployment,因为 BareMetalAssets API 绑定到 ClusterDeployment

要临时解决这个问题,请在升级到 Red Hat Advanced Cluster Management 2.7 前运行以下命令来删除 finalizers

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
1.1.2.1.27. 使用中央基础架构管理服务在断开连接的环境中部署的集群可能无法安装

当使用中央基础架构管理服务在断开连接的环境中部署集群时,集群节点可能无法开始安装。

这是因为集群使用从 OpenShift Container Platform 版本 4.12.0 到 4.12.2 提供的 Red Hat Enterprise Linux CoreOS live ISO 镜像创建的发现 ISO 镜像。该镜像包含一个限制性 /etc/containers/policy.json 文件,该文件需要来自 registry.redhat.ioregistry.access.redhat.com 的镜像的签名。在断开连接的环境中,mirror 的镜像可能没有 mirror 的签名,这会导致发现集群节点的镜像拉取失败。Agent 镜像无法与集群节点连接,这会导致与辅助服务的通信失败。

要临时解决这个问题,将 ignition 覆盖应用到集群,将 /etc/containers/policy.json 文件设置为 unrestrictive。ignition 覆盖可以在 InfraEnv 自定义资源定义中设置。以下示例显示了带有覆盖的 InfraEnv 自定义资源定义:

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: cluster
  namespace: cluster
spec:
  ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'

以下示例显示了创建的未限制文件:

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker-daemon": {
        "": [
        {
            "type": "insecureAcceptAnything"
        }
        ]
    }
    }
}

更改此设置后,集群可以安装。

1.1.2.1.28. 受管集群在部署后处于 Pending 状态

如果 Assisted Installer 代理启动缓慢,且部署受管集群,受管集群可能会处于 Pending 状态,且没有任何代理资源。您可以通过禁用聚合流来解决这个问题。完成以下步骤:

  1. 在 hub 集群中创建以下 ConfigMap:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-assisted-service-config
      namespace: multicluster-engine
    data:
      ALLOW_CONVERGED_FLOW: "false"
  2. 运行以下命令来应用 ConfigMap:

    oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config
1.1.2.1.29. ManagedClusterSet API 规格限制

使用 Clustersets API 时不支持 selectorType: LaberSelector 设置。支持 selectorType: ExclusiveClusterSetLabel 设置。

1.1.2.1.30. hub 集群通信限制

如果 hub 集群无法访问或与受管集群通信,则会出现以下限制:

  • 您不能使用控制台创建新的受管集群。您仍然可以使用命令行界面或使用控制台中的 手动运行 import 命令 导入受管集群。
  • 如果您使用控制台部署 Application 或 ApplicationSet,或者您将受管集群导入到 ArgoCD 中,hub 集群 ArgoCD 控制器会调用受管集群 API 服务器。您可以使用 AppSub 或 ArgoCD pull 模型来解决这个问题。
  • pod 日志的控制台页面无法正常工作,并显示类似如下的错误消息:

    Error querying resource logs:
    Service unavailable
1.1.2.1.31. 受管服务帐户附加组件限制

以下是 managed-serviceaccount 附加组件的已知问题和限制:

1.1.2.1.31.1. installNamespace 字段只能有一个值

启用 managed-serviceaccount 附加组件时,ManagedClusterAddOn 资源中的 installNamespace 字段必须有 open-cluster-management-agent-addon 值。其他值将被忽略。managed-serviceaccount 附加组件代理总是在受管集群上的 open-cluster-management-agent-addon 命名空间中部署。

1.1.2.1.31.2. tolerationsnodeSelector 设置不会影响 managed-serviceaccount 代理

MultiClusterEngineMultiClusterHub 资源中配置的 tolerationsnodeSelector 设置不会影响本地集群中部署的 managed-serviceaccount 代理。本地集群中并不总是需要 managed-serviceaccount 附加组件。

如果需要 managed-serviceaccount 附加组件,您可以通过完成以下步骤来临时解决这个问题:

  1. 创建 addonDeploymentConfig 自定义资源。
  2. 为本地集群和 managed-serviceaccount 代理设置 tolerationsnodeSelector 值。
  3. 更新本地集群命名空间中的 managed-serviceaccount ManagedClusterAddon,以使用您创建的 addonDeploymentConfig 自定义资源。

请参阅为 klusterlet 附加组件配置 nodeSelectors 和 tolerations,以了解如何使用 addonDeploymentConfig 自定义资源为附加组件配置 tolerations(容限)nodeSelector

1.1.2.1.32. KubeVirt 托管集群上的批量销毁选项不会销毁托管集群

在 KubeVirt 托管集群的控制台中使用批量销毁选项不会破坏 KubeVirt 托管的集群。

使用行操作下拉菜单来销毁 KubeVirt 托管的集群。

1.1.2.1.33. Cluster curator 不支持 OpenShift Container Platform Dedicated 集群

当使用 ClusterCurator 资源升级 OpenShift Container Platform Dedicated 集群时,升级会失败,因为 Cluster curator 不支持 OpenShift Container Platform Dedicated 集群。

1.1.2.1.34. 自定义入口域无法正确应用

您可以在安装受管集群时使用 ClusterDeployment 资源指定自定义 ingress 域,但更改仅在使用 SyncSet 资源安装后才会生效。因此,clusterdeployment.yaml 文件中的 spec 字段显示您指定的自定义入口域,但 status 仍然会显示默认域。

1.1.2.2. 托管 control plane

1.1.2.2.1. 控制台将托管集群显示为 Pending import

如果注解和 ManagedCluster 名称不匹配,控制台会将集群显示为 Pending import。集群不能被 multicluster engine operator 使用。如果没有注解,而 ManagedCluster 名称与 HostedCluster 资源的 Infra-ID 值不匹配时会出现相同的问题。"

1.1.2.2.2. 当将节点池添加到托管集群时,控制台可能会多次列出同一版本

当使用控制台向现有托管集群添加新节点池时,同一版本的 OpenShift Container Platform 可能会在选项列表中出现多次。您可以在列表中为您想要的版本选择任何实例。

1.1.2.2.3. Web 控制台列出了节点,即使它们从集群中移除并返回基础架构环境

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

  • 在控制台中,进入节点池,并验证它是否具有 0 个节点。
  • 在命令行界面中运行以下命令:

    • 运行以下命令,验证 0 节点是否在节点池中:

      oc get nodepool -A
    • 运行以下命令,验证 0 个节点是否在集群中:

      oc get nodes --kubeconfig
    • 运行以下命令,验证 0 代理是否报告为绑定到集群:
    oc get agents -A
1.1.2.2.4. 为双栈网络配置的托管集群中潜在的 DNS 问题

当您在使用双栈网络的环境中创建托管集群时,您可能会遇到以下与 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 中的指南来配置 DNS 服务器设置。

1.1.2.2.5. 在裸机平台上,代理资源可能无法拉取 ignition

在裸机(Agent)平台上,托管的 control plane 功能会定期轮转 Agent 用来拉取 ignition 的令牌。错误会导致不会传播新令牌。因此,如果您有一个在一些时间前创建的 Agent 资源,则可能无法拉取 ignition。

作为临时解决方案,在 Agent 规格中,删除 IgnitionEndpointTokenReference 属性引用的 secret,然后在 Agent 资源中添加或修改任何标签。然后,系统可以检测 Agent 资源是否已修改,并使用新令牌重新创建 secret。

1.1.3. 勘误更新

对于多集群引擎 operator,勘误更新会在发布时自动应用。

重要:为了参考,勘误 链接和 GitHub 号可能会添加到内容中并在内部使用。用户可能不能使用访问的链接。

1.1.3.1. Errata 2.5.3

  • 在 KubeVirt creation 向导中添加了一个字段,将托管 control plane 集群的默认模式设置为 HighAvailability 模式。(ACM-10580)
  • 为一个或多个产品容器镜像提供更新。

1.1.3.2. Errata 2.5.2

  • 修复了在运行备份恢复场景并为 Red Hat OpenShift Data Foundation (ODF)使用 Regional-DR 解决方案时可能会导致数据丢失的问题。(ACM-10407)
  • 为一个或多个产品容器镜像提供更新。

1.1.3.3. Errata 2.5.1

  • 为一个或多个产品容器镜像提供更新。

1.1.4. 弃用和删除集群生命周期

了解产品何时被弃用或从多集群引擎 operator 中删除。考虑推荐操作中的备选操作和详细信息,它们显示在当前版本的表中和之前两个版本。

1.1.4.1. API 弃用和删除

multicluster engine operator 遵循 API 的 Kubernetes 弃用指南。有关该策略的更多详细信息,请参阅 Kubernetes Deprecation Policy。多集群引擎 operator API 仅在以下时间表外已弃用或删除:

  • 所有 V1 API 已正式发布(GA),提供 12 个月或跨三个发行版本(以更长的时间为准)的支持。V1 API 没有被删除,但可能会在这个时间限制外被弃用。
  • 所有 beta API 通常在九个月或跨三个发行版本(以更长的时间为准)内可用。Beta API 不会在这个时间限制外被删除。
  • 所有 alpha API 都不是必需的,但如果对用户有好处,则可能会被列为已弃用或删除。
1.1.4.1.1. API 弃用
产品或类别受影响的项Version推荐的操作详情和链接

ManagedServiceAccount

v1alpha1 API 被升级到 v1beta1,因为 v1alpha1 已被弃用。

2.9

使用 v1beta1

None

1.1.4.1.2. API 删除

产品或类别

受影响的项

Version

推荐的操作

详情和链接

1.1.4.2. 启用

弃用(deprecated)组件、功能或服务会被支持,但不推荐使用,并可能在以后的版本中被删除。考虑使用推荐操作中的相应的替代操作,详情在下表中提供:

产品或类别受影响的项Version推荐的操作详情和链接

集群生命周期

在 Red Hat Virtualization 上创建集群

2.9

集群生命周期

klusterlet OLM Operator

2.4

1.1.4.3. 删除

一个删除(removed) 的项通常是在之前的版本中被弃用的功能,在该产品中不再可用。您必须将 alternatives 用于删除的功能。考虑使用推荐操作中的相应的替代操作,详情在下表中提供:

产品或类别

受影响的项

Version

推荐的操作

详情和链接

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.