支持控制台（Console）开发人员开始试用联系人

12.7. control plane 机器集故障排除

使用本节中的信息从您可能会遇到的问题了解和恢复。

12.7.1. 检查 control plane 机器设置自定义资源状态

您可以验证 ControlPlaneMachineSet 自定义资源 (CR) 是否存在以及其状态。

流程

  • 运行以下命令确定 CR 的状态： 

    $ oc get controlplanemachineset.machine.openshift.io cluster \
  --namespace openshift-machine-api
    • Active 的结果表示 ControlPlaneMachineSet CR 存在并被激活。不需要管理员操作。
    • Inactive 表示 ControlPlaneMachineSet CR 存在但没有激活。
    • NotFound 表示没有现有的 ControlPlaneMachineSet CR。

后续步骤

要使用 control plane 机器集，您必须确保集群有正确设置的 ControlPlaneMachineSet CR。

  • 如果您的集群有一个现有的 CR，您必须验证 CR 中的配置是否正确。
  • 如果集群没有现有的 CR，则必须为集群创建一个带有正确配置的 CR。

其他资源

12.7.2. 添加缺少的 Azure 内部负载均衡器

Azure 的 ControlPlaneMachineSet 和 control plane Machine 自定义资源(CR) 都需要 internalLoadBalancer 参数。如果集群上没有预配置此参数，则必须将其添加到两个 CR 中。

有关此参数位于 Azure 供应商规格中的更多信息，请参阅 Azure 供应商规格示例。control plane Machine CR 中的放置类似。

流程

  1. 运行以下命令列出集群中的 control plane 机器： 

    $ oc get machines \
  -l machine.openshift.io/cluster-api-machine-role==master \
  -n openshift-machine-api

  2. 对于每个 control plane 机器，运行以下命令编辑 CR： 

    $ oc edit machine <control_plane_machine_name>
  3. 添加 internalLoadBalancer 参数，使其包含您的集群的正确详情，并保存您的更改。

  4. 运行以下命令来编辑 control plane 机器集 CR： 

    $ oc edit controlplanemachineset.machine.openshift.io cluster \
  -n openshift-machine-api
  5. 添加 internalLoadBalancer 参数，使其包含您的集群的正确详情，并保存您的更改。

后续步骤

  • 对于使用默认 RollingUpdate 更新策略的集群，Operator 会自动将更改传播到 control plane 配置。
  • 对于配置为使用 OnDelete 更新策略的集群，您必须手动替换 control plane 机器。

其他资源

12.7.3. 恢复降级的 etcd Operator

在某些情况下可能会导致 etcd Operator 降级。

例如，在执行补救时，机器健康检查可能会删除托管 etcd 的 control plane 机器。如果此时无法访问 etcd 成员，etcd Operator 会降级。

当 etcd Operator 降级时，需要人工干预才能强制 Operator 删除失败的成员并恢复集群状态。

流程

  1. 运行以下命令列出集群中的 control plane 机器： 

    $ oc get machines \
  -l machine.openshift.io/cluster-api-machine-role==master \
  -n openshift-machine-api \
  -o wide

    以下任何条件都可能表示 control plane 机器失败：

    • STATE 值为 stopped。
    • PHASE 值是 Failed。
    • PHASE 值为 Deleting 超过十分钟。
    重要

    在继续操作前，请确保集群有两个健康的 control plane 机器。对多个 control plane 机器执行操作可能会丢失 etcd 仲裁，并可能导致数据丢失。

    如果您丢失了大多数 control plane 主机，并导致 etcd 仲裁丢失，那么您必须遵循灾难恢复流程 "Restoring to a previous cluster state" 而不是此过程。

  2. 运行以下命令，编辑失败的 control plane 机器的机器 CR： 

    $ oc edit machine <control_plane_machine_name>

  3. 从失败的 control plane 机器中删除 lifecycleHooks 参数的内容并保存您的更改。

    etcd Operator 从集群中移除失败的机器，然后可以安全地添加新的 etcd 成员。

其他资源

12.7.4. 升级在 RHOSP 上运行的集群

对于使用 OpenShift Container Platform 4.13 或更早版本创建的 Red Hat OpenStack Platform (RHOSP) 运行的集群，您可能需要在使用 control plane 机器集前执行升级后的任务。

12.7.4.1. 升级后配置具有根卷可用区的 RHOSP 集群

对于在升级的 Red Hat OpenStack Platform (RHOSP) 上运行的一些集群，如果以下配置为 true，则必须手动更新机器资源：

  • 升级的集群使用 OpenShift Container Platform 4.13 或更早版本创建。
  • 集群基础架构是安装程序置备的基础架构 (installer-provisioned)。
  • 机器在多个可用区间分布。
  • 机器被配置为使用没有定义块存储可用区的 root 卷。

要了解为什么需要这个过程，请参阅解决方案 #7024383。

流程

  1. 对于所有 control plane 机器，编辑与环境匹配的所有 control plane 机器的 provider spec。例如，要编辑 master-0 机器，请输入以下命令： 

    $ oc edit machine/<cluster_id>-master-0 -n openshift-machine-api

    其中：

    <cluster_id>
    指定升级集群的 ID。

  2. 在供应商 spec 中，将属性 rootVolume.availabilityZone 的值设置为您要使用的可用区的卷。

    RHOSP 供应商规格示例

    providerSpec:
  value:
    apiVersion: machine.openshift.io/v1alpha1
    availabilityZone: az0
      cloudName: openstack
    cloudsSecret:
      name: openstack-cloud-credentials
      namespace: openshift-machine-api
    flavor: m1.xlarge
    image: rhcos-4.14
    kind: OpenstackProviderSpec
    metadata:
      creationTimestamp: null
    networks:
    - filter: {}
      subnets:
      - filter:
          name: refarch-lv7q9-nodes
          tags: openshiftClusterID=refarch-lv7q9
    rootVolume:
        availabilityZone: nova 1
        diskSize: 30
        sourceUUID: rhcos-4.12
        volumeType: fast-0
    securityGroups:
    - filter: {}
      name: refarch-lv7q9-master
    serverGroupName: refarch-lv7q9-master
    serverMetadata:
      Name: refarch-lv7q9-master
      openshiftClusterID: refarch-lv7q9
    tags:
    - openshiftClusterID=refarch-lv7q9
    trunk: true
    userDataSecret:
      name: master-user-data

    1
    将区域名称设置为这个值。
    注意

    如果在初始集群部署后编辑或重新创建了机器资源，您可能需要为配置调整这些步骤。

    在 RHOSP 集群中，为您的机器找到根卷的可用区，并将其用作值。

  3. 运行以下命令来检索 control plane 机器集资源的信息： 

    $ oc describe controlplanemachineset.machine.openshift.io/cluster --namespace openshift-machine-api

  4. 运行以下命令编辑资源： 

    $ oc edit controlplanemachineset.machine.openshift.io/cluster --namespace openshift-machine-api
  5. 对于该资源，将 spec.state 属性的值设置为 Active 以激活集群的 control plane 机器集。

您的 control plane 已准备好由 Cluster Control Plane Machine Set Operator 管理。

12.7.4.2. 升级后配置带有可用区的 control plane 机器的 RHOSP 集群

对于在升级的 Red Hat OpenStack Platform (RHOSP) 上运行的一些集群，如果以下配置为 true，则必须手动更新机器资源：

  • 升级的集群使用 OpenShift Container Platform 4.13 或更早版本创建。
  • 集群基础架构是安装程序置备的基础架构 (installer-provisioned)。
  • control plane 机器在多个计算可用区间分布。

要了解为什么需要这个过程，请参阅解决方案 #7013893。

流程

  1. 对于 master-1 和 master-2 control plane 机器，打开供应商规格进行编辑。例如，要编辑第一个机器，请输入以下命令： 

    $ oc edit machine/<cluster_id>-master-1 -n openshift-machine-api

    其中：

    <cluster_id>
    指定升级集群的 ID。

  2. 对于 master-1 和 master-2 control plane 机器，编辑其供应商 specs 中的 serverGroupName 属性的值，以匹配机器 master-0。

    RHOSP 供应商规格示例

    providerSpec:
  value:
    apiVersion: machine.openshift.io/v1alpha1
    availabilityZone: az0
      cloudName: openstack
    cloudsSecret:
      name: openstack-cloud-credentials
      namespace: openshift-machine-api
    flavor: m1.xlarge
    image: rhcos-4.15
    kind: OpenstackProviderSpec
    metadata:
      creationTimestamp: null
    networks:
    - filter: {}
      subnets:
      - filter:
          name: refarch-lv7q9-nodes
          tags: openshiftClusterID=refarch-lv7q9
    securityGroups:
    - filter: {}
      name: refarch-lv7q9-master
    serverGroupName: refarch-lv7q9-master-az0 1
    serverMetadata:
      Name: refarch-lv7q9-master
      openshiftClusterID: refarch-lv7q9
    tags:
    - openshiftClusterID=refarch-lv7q9
    trunk: true
    userDataSecret:
      name: master-user-data

    1
    这个值必须与 master-0、master-1 和 master-3 的机器匹配。
    注意

    如果在初始集群部署后编辑或重新创建了机器资源，您可能需要为配置调整这些步骤。

    在 RHOSP 集群中，找到 control plane 实例所在的服务器组，并将其用作值。

  3. 运行以下命令来检索 control plane 机器集资源的信息： 

    $ oc describe controlplanemachineset.machine.openshift.io/cluster --namespace openshift-machine-api

  4. 运行以下命令编辑资源： 

    $ oc edit controlplanemachineset.machine.openshift.io/cluster --namespace openshift-machine-api
  5. 对于该资源，将 spec.state 属性的值设置为 Active 以激活集群的 control plane 机器集。

您的 control plane 已准备好由 Cluster Control Plane Machine Set Operator 管理。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.