4.3. 障害復旧

手順

1. リカバリーホストとして使用するコントロールプレーンホストを選択します。このホストで復元操作を実行します。

   1. 次のコマンドを実行して、実行中の etcd Pod をリスト表示します。

      $ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"

   2. Pod を 1 つ選択し、次のコマンドを実行してその IP アドレスを取得します。

      $ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table

      Raft インデックスが最も大きく、Learner ではないメンバーの IP アドレスをメモします。

   3. 次のコマンドを実行し、選択した etcd メンバーの IP アドレスに対応するノード名をメモします。

      $ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'

2. SSH を使用して、選択したリカバリーノードに接続し、次のコマンドを実行して etcd クォーラムを復元します。

   $ sudo -E /usr/local/bin/quorum-restore.sh

   数分後、ダウンしたノードが、リカバリースクリプトを実行したノードと自動的に同期されます。残りのオンラインのノードは、quorum-restore.sh スクリプトによって作成された新しい etcd クラスターに自動的に再参加します。このプロセスには数分かかります。

3. SSH セッションを終了します。

4. いずれかのノードがオフラインの場合は、3 ノード設定に戻ります。オフラインになっているノードごとに次の手順を繰り返して、ノードを削除し、再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

   • ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。

     警告

     リカバリーホストのマシンを削除し、再作成しないでください。

   • installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。

     警告

     リカバリーホストのマシンを削除し、再作成しないでください。

     installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

     1. いずれかのオフラインノードのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 

        1

        
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1

        これは、オフラインノード ip-10-0-131-183.ec2.internal のコントロールプレーンマシンです。

     2. 次のコマンドを実行して、オフラインノードのマシンを削除します。

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 

        1

        1

        オフラインノードのコントロールプレーンマシンの名前を指定します。

        オフラインノードのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

5. 以下を実行して、新しいマシンが作成されたことを確認します。

   $ oc get machines -n openshift-machine-api -o wide

   出力例

   NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
   clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
   clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
   clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 

   1

   
   clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
   clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
   clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

   1

   新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

   新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

   1. オフラインになっているノードごとに上記の手順を繰り返します。

6. 次のコマンドを実行して、コントロールプレーンが回復するまで待ちます。

   $ oc adm wait-for-stable-cluster

   注記

   コントロールプレーンが回復するまでに最大 15 分かかります。

手順

1. SSH を使用してシングルノードに接続し、次のコマンドを実行して etcd バックアップを /home/core ディレクトリーにコピーします。

   $ cp <etcd_backup_directory> /home/core

2. シングルノードで次のコマンドを実行し、以前のバックアップからクラスターを復元します。

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd_backup_directory>

3. SSH セッションを終了します。

4. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。

   $ oc adm wait-for-stable-cluster

   注記

   コントロールプレーンが回復するまでに最大 15 分かかります。

手順

1. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作の実行対象とするホストです。

2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

   kube-apiserver は復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。

   重要

   この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

3. SSH を使用して各コントロールプレーンノードに接続し、次のコマンドを実行して etcd を無効にします。

   $ sudo -E /usr/local/bin/disable-etcd.sh

4. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

   この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。

5. SSH を使用してリカバリーホストに接続し、次のコマンドを実行して以前のバックアップからクラスターを復元します。

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>

6. SSH セッションを終了します。

7. API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

8. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。

   $ oc adm wait-for-stable-cluster

   注記

   コントロールプレーンが回復するまでに最大 15 分かかります。

9. 回復したら、次のコマンドを実行してクォーラムガードを有効にします。

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

手順

1. SSH を使用して各コントロールプレーンノードに接続します。

   Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、アクセスするコントロールプレーンホストごとに、別のターミナルで SSH 接続を使用することを推奨します。

   重要

   この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

2. etcd バックアップディレクトリーを各コントロールプレーンホストにコピーします。

   この手順では、etcd スナップショットと静的 Pod のリソースを含む backup ディレクトリーを各コントロールプレーンホストの /home/core/assets ディレクトリーにコピーしていることを前提としています。この assets フォルダーがまだ存在しない場合は、作成する必要がある場合があります。

3. すべてのコントロールプレーンノード上の静的 Pod を、一度に 1 つのホストずつ停止します。

   1. 既存の Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーから移動します。

      $ mkdir -p /root/manifests-backup

      $ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/

   2. 次のコマンドを使用して、Kubernetes API Server コンテナーが停止したことを確認します。

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

   3. Kubernetes API サーバーコンテナーがまだ実行中の場合は、次のコマンドを使用して手動で終了します。

      $ crictl stop <container_id>

   4. 同じ手順を、kube-controller-manager-pod.yaml、kube-scheduler-pod.yaml、最後に etcd-pod.yaml に対して繰り返します。

      1. 次のコマンドで kube-controller-manager Pod を停止します。

         $ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/

      2. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

         $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"

      3. 次のコマンドを使用して、kube-scheduler Pod を停止します。

         $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/

      4. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

         $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"

      5. 次のコマンドを使用して etcd Pod を停止します。

         $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/

      6. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

         $ crictl ps | grep etcd | grep -E -v "operator|guard"

4. 各コントロールプレーンホストで、現在の etcd データを backup フォルダーに移動して保存します。

   $ mkdir /home/core/assets/old-member-data

   $ mv /var/lib/etcd/member /home/core/assets/old-member-data

   このデータは、etcd バックアップの復元が機能せず、etcd クラスターを現在の状態に復元する必要がある場合に役立ちます。

5. 各コントロールプレーンホストの正しい etcd パラメーターを確認します。

   1. <ETCD_NAME> の値は、各コントロールプレーンホストごとに一意であり、特定のコントロールプレーンホストのマニフェスト /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml ファイル内にある ETCD_NAME 変数の値と同じです。次のコマンドで確認できます。

      RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml"
      cat $RESTORE_ETCD_POD_YAML | \
        grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \
        grep -Po '(?<=value: ").+(?=")'

   2. <UUID> の値は、次のコマンドを使用してコントロールプレーンホストで生成できます。

      $ uuidgen

      注記

      <UUID> の値は 1 回だけ生成する必要があります。1 つのコントロールプレーンホストで UUID を生成した後あ、他のホストで再度生成しないでください。次の手順では、すべてのコントロールプレーンホストで同じ UUID を使用します。

   3. ETCD_NODE_PEER_URL の値は、次の例のように設定する必要があります。

      https://<IP_CURRENT_HOST>:2380

      正しい IP は、次のコマンドを使用して、特定のコントロールプレーンホストの <ETCD_NAME> から確認できます。

      $ echo <ETCD_NAME> | \
        sed -E 's/[.-]/_/g' | \
        xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
        grep "IP" | grep -Po '(?<=").+(?=")'

   4. <ETCD_INITIAL_CLUSTER> の値は、次のように設定する必要があります。<ETCD_NAME_n> は各コントロールプレーンホストの <ETCD_NAME> です。

      注記

      使用するポートは 2379 ではなく 2380 である必要があります。ポート 2379 は etcd データベース管理に使用され、コンテナー内の etcd 起動コマンドで直接設定されます。

      出力例

      <ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2> 

      1

      1

      各コントロールプレーンホストの ETCD_NODE_PEER_URL 値を指定します。

      <ETCD_INITIAL_CLUSTER> 値は、すべてのコントロールプレーンホストで同じです。次の手順では、すべてのコントロールプレーンホストで同じ値が必要です。

6. バックアップから etcd データベースを再生成します。

   この操作は、各コントロールプレーンホストで実行する必要があります。

   1. 次のコマンドを使用して、etcd バックアップを /var/lib/etcd ディレクトリーにコピーします。

      $ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd

   2. 続行する前に、正しい etcdctl イメージを特定します。次のコマンドを使用して、Pod マニフェストのバックアップからイメージを取得します。

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml

      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>

   3. etcdctl ツールのバージョンが、バックアップが作成された etcd サーバーのバージョンであることを確認します。

      $ etcdctl version

   4. 現在のホストの正しい値を使用して次のコマンドを実行し、etcd データベースを再生成します。

      $ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \
        --name "<ETCD_NAME>" \
        --initial-cluster="<ETCD_INITIAL_CLUSTER>" \
        --initial-cluster-token "openshift-etcd-<UUID>" \
        --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \
        --data-dir="/var/lib/etcd/restore-<UUID>" \
        --skip-hash-check=true

      注記

      etcd データベースを再生成する場合、引用符は必須です。

7. added member ログに出力される値を記録します。次に例を示します。

   出力例

   2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false}
   2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false}
   2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}

   1. コンテナーから出ます。
   2. この手順を他のコントロールプレーンホストでも繰り返し、added member ログに出力される値がすべてのコントロールプレーンホストで同じであることを確認します。

8. 再生成された etcd データベースをデフォルトの場所に移動します。

   この操作は、各コントロールプレーンホストで実行する必要があります。

   1. 再生成されたデータベース (以前の etcdctl snapshot restore コマンドによって作成された member フォルダー) を、デフォルトの etcd の場所 /var/lib/etcd に移動します。

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd

   2. /var/lib/etcd ディレクトリーの /var/lib/etcd/member フォルダーの SELinux コンテキストを復元します。

      $ restorecon -vR /var/lib/etcd/

   3. 残りのファイルとディレクトリーを削除します。

      $ rm -rf /var/lib/etcd/restore-<UUID>

      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db

      重要

      完了すると、/var/lib/etcd ディレクトリーに含まれるフォルダーが member だけになります。

   4. 他のコントロールプレーンホストでもこの手順を繰り返します。

9. etcd クラスターを再起動します。

   1. 次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ 実行する必要があります。

   2. kubelet が関連コンテナーを起動するように、etcd 静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻します。

      $ mv /root/manifests-backup/etcd-pod.yaml /etc/kubernetes/manifests

   3. すべての etcd コンテナーが起動していることを確認します。

      $ crictl ps | grep etcd | grep -v operator

      出力例

      38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
      e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
      08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
      2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl

      このコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

10. etcd クラスターのステータスを確認します。

    1. いずれかのコントロールプレーンホストで、次のコマンドを使用して etcd クラスターのステータスを確認します。

       $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table

       出力例

       +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
       |         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
       +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
       | https://10.0.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
       |  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
       | https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
       +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

11. 他の静的 Pod を再起動します。

    次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ実行する必要があります。

    1. 次のコマンドを使用して、Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻し、kubelet が関連するコンテナーを起動するようにします。

       $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests

    2. すべての Kubernetes API サーバーコンテナーが起動したことを確認します。

       $ crictl ps | grep kube-apiserver | grep -v operator

       注記

       次のコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

    3. 同じ手順を、kube-controller-manager-pod.yaml ファイルと kube-scheduler-pod.yaml ファイルに対して繰り返します。

       1. 次のコマンドを使用して、すべてのノードで kubelet を再起動します。

          $ systemctl restart kubelet

       2. 次のコマンドを使用して、残りのコントロールプレーン Pod を起動します。

          $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/

       3. kube-apiserver、kube-scheduler、および kube-controller-manager Pod が正しく起動しているかどうかを確認します。

          $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'

       4. 次のコマンドを使用して OVN データベースをワイプします。

          for NODE in  $(oc get node -o name | sed 's:node/::g')
          do
            oc debug node/${NODE} -- chroot /host /bin/bash -c  'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'
            oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait
            oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s
          done