2 ノード OpenShift クラスターのインストール

手順

1. 次のポートのトラフィックを転送するようにロードバランサーを設定します。

   • 6443: Kubernetes API サーバー

   • 80 および 443: アプリケーション Ingress

     両方のコントロールプレーンノードにトラフィックを転送する必要があります。

2. ロードバランサーのヘルスチェックを設定します。応答するノードにのみロードバランサーがトラフィックを送信するように、バックエンドのエンドポイントを監視する必要があります。

3. 両方のコントロールプレーンノードにトラフィックを転送するようにロードバランサーを設定します。次の例は、2 台のコントロールプレーンノードを設定する方法を示しています。

   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. フェンシングシークレットの更新: ベースボード管理コンソール (BMC) の認証情報が正しくないか古くなっている場合は更新します。
2. シングルノード障害からの回復: 1 台のコントロールプレーンノードのみがダウンした場合に機能を復元します。
3. 完全なノード障害からの回復: 両方のコントロールプレーンノードがダウンした場合に機能を復元します。
4. 回復できないコントロールプレーンノードの置き換え: ノードを置き換えてクラスターの機能を復元します。

手順

1. フェンシングシークレットを更新します。

   1. Cluster API が利用できない場合は、いずれかのクラスターノードで次のコマンドを実行して、フェンシングシークレットを更新します。

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

      Cluster API が回復した後、または Cluster API がすでに使用可能な場合は、次のステップで説明するように、クラスター内のフェンシングシークレットを更新して、同期が取れた状態にします。

   2. 次のコマンドを実行して、コントロールプレーンノードの既存のフェンシングシークレットのユーザー名とパスワードを編集します。

      $ oc project openshift-etcd

      $ oc edit secret <node_name>-fencing

      フェンシングシークレットを更新した後にクラスターが回復した場合、それ以上の操作は必要ありません。問題が解決しない場合は、次のステップに進みます。

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. 両方のコントロールプレーンノードの電源をオンにします。

      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. いずれかのノードが回復不能な場合にイベントから手動で回復する必要がある場合は、「2 ノード OpenShift クラスターのコントロールプレーンノードの置き換え」の手順に従ってください。

   クラスターが 1 台のノードを失うと、クラスターがデグレードモードになります。この状態になると、Pacemaker が自動的にクォーラムのブロックを解除し、クラスターが残りのノードで一時的に動作できるようにします。

   両方のノードに障害が発生した場合は、Pacemaker が通常のクラスター操作を再開できるように、両方のノードを再起動してクォーラムを再確立する必要があります。

   2 つのノードのうち 1 つしか再起動できない場合は、ノードの置き換え手順に従って、残りのノードでクォーラムを手動で再確立します。

   それでも手動での回復が必要な状況で、その回復作業にも失敗した場合は、must-gather レポートと SOS レポートを収集し、バグを報告してください。

手順

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. クォーラムが失われた状態で、1 台のコントロールプレーンノードがまだ実行されている場合は、次のコマンドを実行して、障害を免れたノードでクォーラムを手動で復元します。

      $ sudo pcs quorum unblock

   2. 1 台のノードでのみ障害が発生した場合は、次のコマンドを実行して、障害を免れたノードで etcd が実行されていることを確認します。

      $ sudo pcs resource status etcd

   3. etcd が実行されていない場合は、次のコマンドを実行して etcd を再起動します。

      $ sudo pcs resource cleanup etcd

      それでも 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 シークレットを削除します。

   $ 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 シークレットを削除する必要があります。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 アドレスを使用して、障害が発生したホストを再作成します。

   重要

   この手順を実行する必要があるのは、元のノードを作成するために installer-provisioned infrastructure または Machine API を使用している場合だけです。障害が発生したベアメタルコントロールプレーンノードの置き換えについては、「ベアメタル上の正常でない 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 オブジェクトと 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: シークレットの名前を指定します。
      • metadata.name: {bmh_name} は、削除した BMH オブジェクトの名前に置き換えます。
      • bmc.address: {uuid} は、作成したノードの UUID に置き換えます。
      • bmc.credentialsName: name は、作成したシークレットの名前に置き換えます。
      • bootMACAddress: プロビジョニングネットワークインターフェイスの MAC アドレスを指定します。これは、プロビジョニング中に Ironic と通信するときにノードが自身を識別するために使用する MAC アドレスです。

5. 次のコマンドを実行して、新しいノードが Provisioned 状態になっていることを確認します。

   $ oc get bmh -o wide

   このコマンドの出力で、STATUS 列の値が Provisioned である必要があります。

   注記

   プロビジョニングプロセスが完了するまでに 10 - 20 分かかる場合があります。

6. 次のコマンドを実行して、両方のコントロールプレーンノードが Ready 状態であることを確認します。

   $ oc get nodes

   このコマンドの出力で、両ノードの STATUS 列の値が Ready である必要があります。

7. 次のコマンドを実行して、Machine API による管理を防ぐために、BMH オブジェクトに detached アノテーションを適用します。

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

8. 次のコマンドを実行して、置き換え用のノードを Pacemaker クラスターに再度参加させます。

   注記

   置き換え対象のノードではなく、障害を免れたコントロールプレーンノードで次のコマンドを実行してください。

   $ 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

   このコマンドにより、両方のコントロールプレーンノードが 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. いずれかのコントロールプレーンノードで次のコマンドを実行して、Pacemaker リソースのステータスを確認します。

   $ sudo pcs status --full

   このコマンドにより、Pacemaker によって管理されるすべてのリソースの詳細な説明が提供されます。次の条件が満たされていることを確認する必要があります。

   • 両方のノードがオンラインである。
   • kubelet および etcd リソースが実行されている。
   • フェンシングが両方のノードに対して正しく設定されている。