安装双节点 OpenShift 集群

1. 当未启用并发多线程 (SMT) 或超线程时，一个 CPU 相当于一个物理内核。启用后，使用以下公式来计算对应的比例：（每个内核数的线程）× sockets = CPU。
2. OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感，建议使用更快的存储，特别是 control plane 节点上的 etcd。请注意，在许多云平台上，存储大小和 IOPS 可一起扩展，因此您可能需要过度分配存储卷来获取足够的性能。

流程

1. 将负载均衡器配置为转发以下端口的流量：

   • 6443: Kubernetes API 服务器

   • 80 和 443 ：应用程序入口

     您必须将流量转发到两个 control plane 节点。

2. 在负载平衡器上配置健康检查。您必须监控后端端点，以便负载均衡器仅将流量发送到响应的节点。

3. 配置负载均衡器，将流量转发到两个 control plane 节点。以下示例演示了如何配置两个 control plane 节点：

   frontend api_frontend
       bind *:6443
       mode tcp
       default_backend api_backend
   
   backend api_backend
       mode tcp
       balance roundrobin
       server cp0 <cp0_ip>:6443 check
       server cp1 <cp1_ip>:6443 check
   
   frontend ingress_frontend
       bind *:80
       bind *:443
       mode tcp
       default_backend ingress_backend
   
   backend ingress_backend
       mode tcp
       balance roundrobin
       server cp0 <cp0_ip>:80 check
       server cp1 <cp1_ip>:80 check
       server cp0 <cp0_ip>:443 check
       server cp1 <cp1_ip>:443 check

4. 验证负载均衡器配置：

   1. 在外部客户端中运行以下命令：

      $ curl -k https://api.<cluster_name>.<base_domain>:6443/version

   2. 从外部客户端，运行以下命令来访问应用程序路由：

      $ curl https://<app>.<cluster_name>.<base_domain>

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

流程

1. 更新隔离 secret：

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

      $ sudo pcs stonith update <node_name>_redfish username=<user_name> password=<password>

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

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

      $ oc project openshift-etcd

      $ oc edit secret <node_name>-fencing

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

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

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

      $ sudo pcs status --full

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

   2. 如果需要，运行以下命令：

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

      $ sudo pcs resource cleanup

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

      $ sudo journalctl -u pacemaker

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

      $ sudo journalctl -u pacemaker | grep podman-etcd

   3. 运行以下命令，查看节点的隔离配置：

      $ sudo pcs stonith config <node_name>_redfish

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

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

      $ sudo cp -r /var/lib/etcd-backup/* /var/lib/etcd/

      $ sudo chown -R etcd:etcd /var/lib/etcd

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

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

   1. 打开两个 control plane 节点。

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

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

      $ sudo pcs resource cleanup

   3. 运行以下命令检查资源启动顺序：

      $ sudo pcs status --full

   4. 运行以下命令，检查 kubelet 失败的 pacemaker 服务日志：

      $ sudo journalctl -u pacemaker

      $ sudo journalctl -u kubelet

   5. 处理不同步的 etcd。

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

      $ sudo pcs stonith config

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

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

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

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

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

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

流程

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

   $ sudo pcs quorum status

   输出示例

   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

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

      $ sudo pcs quorum unblock

   2. 如果只有一个节点失败，请运行以下命令验证 etcd 是否在 survivor 节点上运行：

      $ sudo pcs resource status etcd

   3. 如果 etcd 没有运行，请运行以下命令重启 etcd：

      $ sudo pcs resource cleanup etcd

      如果 etcd 仍然没有启动，手动在存活的节点上强制启动，跳过隔离：

      重要

      在运行此命令前，请确保被替换的节点无法访问。否则，会面临 etcd 被破坏的风险。

      $ sudo pcs resource debug-stop etcd

      $ sudo OCF_RESKEY_CRM_meta_notify_start_resource='etcd' pcs resource debug-start etcd

      恢复后，etcd 必须在存活的节点上成功运行。

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

   $ oc project openshift-etcd

   $ oc delete secret etcd-peer-<node_name>

   $ oc delete secret etcd-serving-<node_name>

   $ oc delete secret etcd-serving-metrics-<node_name>

   注意

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

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

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

      $ oc get bmh -n openshift-machine-api

   2. 运行以下命令，删除故障节点的 BMH 对象：

      $ oc delete bmh/<bmh_name> -n openshift-machine-api

   3. 运行以下命令，列出 Machine 对象来识别映射到您要替换的节点的对象：

      $ oc get machines.machine.openshift.io -n openshift-machine-api

   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"}'

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

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

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

      $ oc delete machines.machine.openshift.io/<machine_name>-<failed nodename> -n openshift-machine-api

      注意

      在删除 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

      • 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

      • 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

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

   注意

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

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

   $ oc get nodes

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

7. 运行以下命令，将 detached 注解应用到 BMH 对象以防止 Machine API 管理它：

   $ oc annotate bmh <bmh_name> -n openshift-machine-api baremetalhost.metal3.io/detached='' --overwrite

8. 运行以下命令，将替换节点重新加入到 pacemaker 集群中：

   注意

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

   $ sudo pcs cluster node remove <node_name>

   $ sudo pcs cluster node add <node_name> addr=<node_ip> --start --enable

9. 运行以下命令，删除故障节点的过时作业：

   $ oc project openshift-etcd

   $ oc delete job tnf-auth-job-<node_name>

   $ oc delete job tnf-after-setup-job-<node_name>

流程

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

   $ oc get nodes

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

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

   $ oc describe co/etcd

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

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

   $ oc rsh -n openshift-etcd <etcd_pod> etcdctl member list -w table

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

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

   $ sudo pcs status --full

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

   • 两个节点都在线。
   • kubelet 和 etcd 资源正在运行。
   • 两个节点的隔离都正确配置。