2.3. 安装后进行故障排除和恢复


重要

带有隔离的双节点 OpenShift 集群只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

使用以下小节帮助您通过隔离在双节点 OpenShift 集群中恢复问题。

2.3.1. 自动恢复不可用时从中断事件手动恢复

如果中断事件阻止隔离正常工作,您可能需要执行手动恢复步骤。在这种情况下,您可以在 control plane 节点上直接运行命令来恢复集群。有四个主要恢复场景,应该按照以下顺序尝试:

  1. 更新隔离 secret :如果 Baseboard Management Console (BMC)凭证不正确或过期,则刷新它们。
  2. 从单节点故障中恢复:当只有一个 control plane 节点停机时,恢复功能。
  3. 从完整的节点故障中恢复:当两个 control plane 节点都停机时恢复功能。
  4. 替换无法恢复的 control plane 节点:替换节点以恢复集群功能。

先决条件

  • 有对 control plane 节点的管理访问权限。
  • 您可以使用 SSH 连接到节点。
注意

在继续操作前进行 etcd 备份,以确保在出现问题时可以恢复集群。

流程

  1. 更新隔离 secret:

    1. 如果 Cluster API 不可访问,请在其中一个集群节点上运行以下命令来更新隔离 secret:

      $ sudo pcs stonith update <node_name>_redfish username=<user_name> password=<password>
      Copy to Clipboard Toggle word wrap

      在 Cluster API 恢复或 Cluster API 已可用后,更新集群中的隔离 secret,以确保它保持同步,如以下步骤所述。

    2. 运行以下命令,编辑 control plane 节点的现有隔离 secret 的用户名和密码:

      $ oc project openshift-etcd
      Copy to Clipboard Toggle word wrap
      $ oc edit secret <node_name>-fencing
      Copy to Clipboard Toggle word wrap

      如果在更新隔离 secret 后集群恢复,则不需要进一步的操作。如果问题仍然存在,请继续下一步。

  2. 从单节点故障中恢复:

    1. 运行以下命令来收集初始诊断:

      $ sudo pcs status --full
      Copy to Clipboard Toggle word wrap

      此命令提供当前集群和资源状态的详细视图。您可以使用输出来识别隔离或 etcd 启动的问题。

    2. 如果需要,运行以下命令:

      运行以下命令重置集群中的资源,并指示 Pacemaker 尝试再次启动它们:

      $ sudo pcs resource cleanup
      Copy to Clipboard Toggle word wrap

      运行以下命令,查看节点上的所有 Pacemaker 活动:

      $ sudo journalctl -u pacemaker
      Copy to Clipboard Toggle word wrap

      运行以下命令来诊断 etcd 资源启动问题:

      $ sudo journalctl -u pacemaker | grep podman-etcd
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,查看节点的隔离配置:

      $ sudo pcs stonith config <node_name>_redfish
      Copy to Clipboard Toggle word wrap

      如果需要隔离,但无法正常工作,请确保可以访问 Redfish 隔离端点,并验证凭证是否正确。

    4. 如果 etcd 没有启动隔离功能,请运行以下命令从备份中恢复 etcd:

      $ sudo cp -r /var/lib/etcd-backup/* /var/lib/etcd/
      Copy to Clipboard Toggle word wrap
      $ sudo chown -R etcd:etcd /var/lib/etcd
      Copy to Clipboard Toggle word wrap

      如果恢复成功,则不需要进一步的操作。如果问题仍然存在,请继续下一步。

  3. 从完整的节点故障中恢复:

    1. 打开两个 control plane 节点。

      Pacemaker 在检测到两个节点在线时自动启动恢复操作。如果恢复没有按预期启动,请使用上一步中描述的诊断命令来调查问题。

    2. 运行以下命令重置集群中的资源,并指示 Pacemaker 尝试再次启动它们:

      $ sudo pcs resource cleanup
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令检查资源启动顺序:

      $ sudo pcs status --full
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令,检查 kubelet 失败的 pacemaker 服务日志:

      $ sudo journalctl -u pacemaker
      Copy to Clipboard Toggle word wrap
      $ sudo journalctl -u kubelet
      Copy to Clipboard Toggle word wrap
    5. 处理不同步的 etcd。

      如果一个节点具有更新的 etcd,Pacemaker 会尝试隔离滞后的节点,并将其作为学员启动。如果这个进程停滞,请运行以下命令验证 Redfish 隔离端点和凭证:

      $ sudo pcs stonith config
      Copy to Clipboard Toggle word wrap

      如果恢复成功,则不需要进一步的操作。如果问题仍然存在,请执行手动恢复,如下一步所述。

  4. 如果您需要在一个节点无法恢复时从事件手动恢复,请按照以下步骤"替换 control plane 节点到双节点 OpenShift 集群中"。

    当集群丢失某个节点时,它会进入降级模式。在这个状态中,Pacemaker 会自动取消阻塞仲裁,并允许集群在剩余的节点上临时操作。

    如果两个节点都失败,您必须重启两个节点来重新建立仲裁,以便 Pacemaker 可以恢复正常的集群操作。

    如果只有两个节点中的一个可以重启,请按照以下步骤在存活的节点上手动重新建立仲裁。

    如果仍需要手动恢复,且失败,收集 must-gather 和 SOS 报告,并提交一个 bug。

验证

有关验证 control plane 节点和 etcd 是否正常运行的详情,请参考"使用隔离在双节点 OpenShift 集群中验证 etcd 健康状况"。

您可以替换双节点 OpenShift 集群中失败的 control plane 节点。替换节点必须使用与故障节点相同的主机名和 IP 地址。

先决条件

  • 您有一个可正常工作的 survivor control plane 节点。
  • 您已确认机器没有运行,或者该节点未就绪。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您知道故障节点的主机名和 IP 地址。
注意

在继续操作前进行 etcd 备份,以确保在出现问题时可以恢复集群。

流程

  1. 运行以下命令检查仲裁状态:

    $ sudo pcs quorum status
    Copy to Clipboard Toggle word wrap

    输出示例

    Quorum information
    ------------------
    Date:             Fri Oct  3 14:15:31 2025
    Quorum provider:  corosync_votequorum
    Nodes:            2
    Node ID:          1
    Ring ID:          1.16
    Quorate:          Yes
    
    Votequorum information
    ----------------------
    Expected votes:   2
    Highest expected: 2
    Total votes:      2
    Quorum:           1
    Flags:            2Node Quorate WaitForAll
    
    Membership information
    ----------------------
        Nodeid      Votes    Qdevice Name
             1          1         NR master-0 (local)
             2          1         NR master-1
    Copy to Clipboard Toggle word wrap

    1. 如果 quorum 丢失,且一个 control plane 节点仍在运行,请运行以下命令在 survivor 节点上手动恢复仲裁:

      $ sudo pcs quorum unblock
      Copy to Clipboard Toggle word wrap
    2. 如果只有一个节点失败,请运行以下命令验证 etcd 是否在 survivor 节点上运行:

      $ sudo pcs resource status etcd
      Copy to Clipboard Toggle word wrap
    3. 如果 etcd 没有运行,请运行以下命令重启 etcd:

      $ sudo pcs resource cleanup etcd
      Copy to Clipboard Toggle word wrap

      如果 etcd 仍然没有启动,请手动在 survivor 节点上强制进行隔离,跳过隔离:

      重要

      在运行此命令前,请确保被替换的节点无法访问。否则,您面临 etcd 崩溃的风险。

      $ sudo pcs resource debug-stop etcd
      Copy to Clipboard Toggle word wrap
      $ sudo OCF_RESKEY_CRM_meta_notify_start_resource='etcd' pcs resource debug-start etcd
      Copy to Clipboard Toggle word wrap

      恢复后,etcd 必须在 survivor 节点上成功运行。

  2. 运行以下命令,为故障节点删除 etcd secret:

    $ oc project openshift-etcd
    Copy to Clipboard Toggle word wrap
    $ oc delete secret etcd-peer-<node_name>
    Copy to Clipboard Toggle word wrap
    $ oc delete secret etcd-serving-<node_name>
    Copy to Clipboard Toggle word wrap
    $ oc delete secret etcd-serving-metrics-<node_name>
    Copy to Clipboard Toggle word wrap
    注意

    要替换失败的节点,您必须首先删除其 etcd secret。当 etcd 运行时,API 服务器可能需要一些时间才能响应这些命令。

  3. 删除故障节点的资源:

    1. 如果您有 BareMetalHost (BMH)对象,请运行以下命令来识别您要替换的主机:

      $ oc get bmh -n openshift-machine-api
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令,删除故障节点的 BMH 对象:

      $ oc delete bmh/<bmh_name> -n openshift-machine-api
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,列出 Machine 对象来识别映射到您要替换的节点的对象:

      $ oc get machines.machine.openshift.io -n openshift-machine-api
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令,从 Machine 对象获取带有机器哈希值的标签:

      $ oc get machines.machine.openshift.io/<machine_name> -n openshift-machine-api \
        -o jsonpath='Machine hash label: {.metadata.labels.machine\.openshift\.io/cluster-api-cluster}{"\n"}'
      Copy to Clipboard Toggle word wrap

      <machine_name > 替换为集群中的 Machine 对象的名称。例如: ostest-bfs7w-ctrlplane-0

      您需要此标签来置备新的 Machine 对象。

    5. 运行以下命令,删除故障节点的 Machine 对象:

      $ oc delete machines.machine.openshift.io/<machine_name>-<failed nodename> -n openshift-machine-api
      Copy to Clipboard Toggle word wrap
      注意

      在删除 Machine 对象后,节点对象会被自动删除。

  4. 使用相同的名称和 IP 地址重新创建失败的主机:

    重要

    只有在使用安装程序置备的基础架构或 Machine API 创建原始节点时,才需要执行此步骤。有关替换失败的裸机 control plane 节点的详情,请参考"在裸机中替换不健康的 etcd 成员"。

    1. 删除 BMH 和 Machine 对象。机器控制器自动删除节点对象。
    2. 使用以下示例配置置备新机器:

      Machine 对象配置示例

      apiVersion: machine.openshift.io/v1beta1
      kind: Machine
      metadata:
        annotations:
          metal3.io/BareMetalHost: openshift-machine-api/{bmh_name}
        finalizers:
        - machine.machine.openshift.io
        labels:
          machine.openshift.io/cluster-api-cluster: {machine_hash_label}
          machine.openshift.io/cluster-api-machine-role: master
          machine.openshift.io/cluster-api-machine-type: master
        name: {machine_name}
        namespace: openshift-machine-api
      spec:
        authoritativeAPI: MachineAPI
        metadata: {}
        providerSpec:
          value:
            apiVersion: baremetal.cluster.k8s.io/v1alpha1
            customDeploy:
              method: install_coreos
            hostSelector: {}
            image:
              checksum: ""
              url: ""
            kind: BareMetalMachineProviderSpec
            metadata:
              creationTimestamp: null
            userData:
              name: master-user-data-managed
      Copy to Clipboard Toggle word wrap

      • metadata.annotations.metal3.io/BareMetalHost: 将 {bmh_name} 替换为与您要替换的主机关联的 BMH 对象的名称。
      • labels.machine.openshift.io/cluster-api-cluster: 将 {machine_hash_label} 替换为从您删除的机器中获取的标签。
      • metadata.name :将 {machine_name} 替换为您删除的机器的名称。
    3. 运行以下命令,创建新的 BMH 对象和 secret 来存储 BMC 凭证:

      cat <<EOF | oc apply -f -
      apiVersion: v1
      kind: Secret
      metadata:
        name: <secret_name>
        namespace: openshift-machine-api
      data:
        password: <password>
        username: <username>
      type: Opaque
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: {bmh_name}
        namespace: openshift-machine-api
      spec:
        automatedCleaningMode: disabled
        bmc:
          address: <redfish_url>/{uuid}
          credentialsName: <name>
          disableCertificateVerification: true
        bootMACAddress: {boot_mac_address}
        bootMode: UEFI
        externallyProvisioned: false
        online: true
        rootDeviceHints:
          deviceName: /dev/disk/by-id/scsi-<serial_number>
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api
      EOF
      Copy to Clipboard Toggle word wrap
      • metadata.name :指定 secret 的名称。
      • metadata.name :将 {bmh_name} 替换为您删除的 BMH 对象的名称。
      • BMC.address: 将 {uuid} 替换为您创建的节点的 UUID。
      • BMC.credentialsName :将 name 替换为您创建的 secret 的名称。
      • bootMACAddress :指定 provisioning 网络接口的 MAC 地址。这是节点在调配期间与 Ironic 通信时使用的 MAC 地址。
  5. 运行以下命令验证新节点是否已达到 Provisioned 状态:

    $ oc get bmh -o wide
    Copy to Clipboard Toggle word wrap

    此命令输出中的 STATUS 列的值必须是 Provisioned

    注意

    完成置备过程可能需要 10 到 20 分钟。

  6. 运行以下命令,验证两个 control plane 节点都处于 Ready 状态:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    此命令输出中的 STATUS 列值对于两个节点都必须是 Ready

  7. 运行以下命令,将 分离 注解应用到 BMH 对象以防止 Machine API 管理它:

    $ oc annotate bmh <bmh_name> -n openshift-machine-api baremetalhost.metal3.io/detached='' --overwrite
    Copy to Clipboard Toggle word wrap
  8. 运行以下命令,将替换节点重新加入到 pacemaker 集群中:

    注意

    在 survivor control plane 节点上运行以下命令,而不是被替换的节点。

    $ sudo pcs cluster node remove <node_name>
    Copy to Clipboard Toggle word wrap
    $ sudo pcs cluster node add <node_name> addr=<node_ip> --start --enable
    Copy to Clipboard Toggle word wrap
  9. 运行以下命令,删除故障节点的过时作业:

    $ oc project openshift-etcd
    Copy to Clipboard Toggle word wrap
    $ oc delete job tnf-auth-job-<node_name>
    Copy to Clipboard Toggle word wrap
    $ oc delete job tnf-after-setup-job-<node_name>
    Copy to Clipboard Toggle word wrap

验证

有关验证 control plane 节点和 etcd 是否正常运行的详情,请参考"使用隔离在双节点 OpenShift 集群中验证 etcd 健康状况"。

完成节点恢复或维护过程后,验证 control plane 节点和 etcd 是否在正确运行。

先决条件

  • 您可以使用具有 cluster-admin 权限的用户访问集群。
  • 您可以通过 SSH 访问至少一个 control plane 节点。

流程

  1. 运行以下命令检查整个节点状态:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    此命令验证 control plane 节点是否处于 Ready 状态,表示它们是否可以接收调度的工作负载。

  2. 运行以下命令,验证 cluster-etcd-operator 的状态:

    $ oc describe co/etcd
    Copy to Clipboard Toggle word wrap

    cluster-etcd-operator 管理并报告 etcd 设置的健康状况。查看其状态可帮助您识别任何持续的问题或降级条件。

  3. 运行以下命令来查看 etcd 成员列表:

    $ oc rsh -n openshift-etcd <etcd_pod> etcdctl member list -w table
    Copy to Clipboard Toggle word wrap

    此命令显示当前的 etcd 成员及其角色。查找标记为 learner 的任何节点,这表示它们正在成为投票成员。

  4. 在 control plane 节点上运行以下命令来查看 Pacemaker 资源状态:

    $ sudo pcs status --full
    Copy to Clipboard Toggle word wrap

    此命令提供 Pacemaker 管理的所有资源的详细概述。您必须确保满足以下条件:

    • 两个节点都在线。
    • kubeletetcd 资源正在运行。
    • 两个节点的隔离都正确配置。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat