ホーム
製品
OpenShift Container Platform
4.19
バックアップおよび復元
6.2. 正常でない etcd メンバーの置き換え

6.2. 正常でない etcd メンバーの置き換え

このドキュメントでは、単一の正常でない etcd メンバーを置き換えるプロセスを説明します。

このプロセスは、マシンが実行されていないか、ノードが準備状態にないことによって etcd メンバーが正常な状態にないか、etcd Pod がクラッシュループしているためにこれが正常な状態にないかによって異なります。

注記

コントロールプレーンホストの大部分を損失した場合は、この手順ではなく、ディザスターリカバリー手順に従って、以前のクラスター状態への復元を行います。

置き換えられるメンバー上のコントロールプレーン証明書が有効でない場合は、この手順ではなく、期限切れのコントロールプレーン証明書から回復する手順を実行する必要があります。

コントロールプレーンノードが失われ、新規ノードが作成される場合、etcd クラスター Operator は新規 TLS 証明書の生成と、ノードの etcd メンバーとしての追加を処理します。

6.2.1. 前提条件
リンクのコピー

正常でない etcd メンバーを置き換える前に、etcd のバックアップを作成する。

6.2.2. 正常でない etcd メンバーの特定
リンクのコピー

クラスターに正常でない etcd メンバーがあるかどうかを特定することができます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
etcd のバックアップを取得している。詳細は、「etcd データのバックアップ」を参照してください。

手順

以下のコマンドを使用して EtcdMembersAvailable ステータス条件のステータスを確認します。

$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}{end}'

出力を確認します。
```
2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
```
この出力例は、ip-10-0-131-183.ec2.internal etcd メンバーが正常ではないことを示しています。

6.2.3. 正常でない etcd メンバーの状態の判別
リンクのコピー

正常でない etcd メンバーを置き換える手順は、etcd メンバーが以下のどの状態にあるかによって異なります。

マシンが実行されていないか、ノードが準備状態にない
etcd Pod がクラッシュループしている。

以下の手順では、etcd メンバーがどの状態にあるかを判別します。これにより、正常でない etcd メンバーを置き換えるために実行する必要のある手順を確認できます。

注記

マシンが実行されていないか、ノードが準備状態にないものの、すぐに正常な状態に戻ることが予想される場合は、etcd メンバーを置き換える手順を実行する必要はありません。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
正常でない etcd メンバーを特定している。

手順

マシンが実行されていない かどうかを確認します。
```
$ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
```
出力例
```
ip-10-0-131-183.ec2.internal  stopped 
```
1
1
この出力には、ノードおよびノードのマシンのステータスをリスト表示されます。ステータスが running 以外の場合は、マシンは実行されていません。
マシンが実行されていない 場合は、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換え の手順を実行します。
ノードの準備ができていない かどうかを確認します。
以下のシナリオのいずれかが true の場合、ノードは準備状態にありません。
- マシンが実行されている場合は、ノードに到達できないかどうかを確認します。
  $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
  出力例
  ip-10-0-131-183.ec2.internal node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable
  1
  1
  ノードが unreachable テイントと共にリスト表示される場合、ノードの準備はできていません。
- ノードにまだ到達可能な場合は、ノードが NotReady としてリストされるかどうかを確認します。
  $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
  出力例
  ip-10-0-131-183.ec2.internal NotReady master 122m v1.32.3
  1
  1
  ノードが NotReady としてリスト表示されている場合、ノードの準備はできていません。
ノードの準備ができていない 場合は、マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え の手順を実行します。
etcd Pod がクラッシュループしている かどうかを確認します。
マシンが実行され、ノードが準備できている場合は、etcd Pod がクラッシュループしているかどうかを確認します。
1. すべてのコントロールプレーンノードが Ready としてリスト表示されていることを確認します。
  $ oc get nodes -l node-role.kubernetes.io/master
  出力例
  NAME STATUS ROLES AGE VERSION ip-10-0-131-183.ec2.internal Ready master 6h13m v1.32.3 ip-10-0-164-97.ec2.internal Ready master 6h13m v1.32.3 ip-10-0-154-204.ec2.internal Ready master 6h13m v1.32.3
2. etcd Pod のステータスが Error または CrashloopBackoff のいずれかであるかどうかを確認します。
  $ oc -n openshift-etcd get pods -l k8s-app=etcd
  出力例
  etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m
  1
  etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
  1
  この Pod のこのステータスは Error であるため、etcd Pod はクラッシュループしています。
etcd Pod がクラッシュループしている 場合、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え に関する手順を実行します。

6.2.4. 正常でない etcd メンバーの置き換え
リンクのコピー

正常でない etcd メンバーの状態に応じて、以下のいずれかの手順を使用します。

6.2.4.1. マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え
リンクのコピー

マシンが実行されていない、またはノードの準備ができていない、正常ではない etcd メンバーを置き換える手順を説明します。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。

前提条件

正常でない etcd メンバーを特定している。
マシンが実行されていないか、ノードが準備状態にないことを確認している。
重要
他のコントロールプレーンノードの電源をオフにする場合は、待機する必要があります。異常な etcd メンバーの交換が完了するまで、コントロールプレーンノードの電源をオフのままにしておく必要があります。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
etcd のバックアップを取得している。
重要
この手順を実行する前に、問題が発生した場合にクラスターを復元できるように、etcd のバックアップを作成してください。

手順

正常でないメンバーを削除します。

影響を受けるノード上にない Pod を選択します。

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

$ oc -n openshift-etcd get pods -l k8s-app=etcd

出力例

etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
```

メンバーのリストを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

正常でない etcd メンバーの ID と名前をメモしてください。これらの値はこの手順で後ほど必要になります。$ etcdctl endpoint health コマンドは、補充手順が完了し、新しいメンバーが追加されるまで、削除されたメンバーをリスト表示します。

ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。
```
sh-4.2# etcdctl member remove 6fc1e7c9db35841d
```
出力例
```
Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
```

メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

これでノードシェルを終了できます。

次のコマンドを入力して、クォーラムガードをオフにします。
```
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
```
このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
重要
クォーラムガードをオフにすると、設定の変更を反映するために残りの etcd インスタンスが再起動するまで、短時間クラスターにアクセスできなくなる可能性があります。
注記
etcd は、2 つのメンバーで実行されている場合、新たなメンバー障害を許容できません。残りのメンバーのいずれかを再起動すると、クォーラムが破棄され、クラスターでダウンタイムが発生します。クォーラムガードによって、ダウンタイムを引き起こす可能性のある設定変更による再起動から etcd が保護されるため、この手順を完了するには、クォーラムガードを無効にする必要があります。
次のコマンドを実行して、影響を受けるノードを削除します。
```
$ oc delete node <node_name>
```
コマンドの例
```
$ oc delete node ip-10-0-131-183.ec2.internal
```
削除された正常でない etcd メンバーの古いシークレットを削除します。
1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。
  $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
  1
  1
  この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
  以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
  出力例
  etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
2. 削除された正常でない etcd メンバーのシークレットを削除します。
  1. ピアシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
  2. サービングシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
  3. メトリクスシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

次のコマンドを入力して、コントロールプレーンマシンセットが存在するかどうかを確認します。

$ oc -n openshift-machine-api get controlplanemachineset

コントロールプレーンマシンセットが存在する場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。詳細は、「マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え」を参照してください。

インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初にコントロールプレーンを作成したときと同じ方法を使用して、新しいコントロールプレーンを作成する必要があります。

正常でないメンバーのマシンを取得します。

クラスターにアクセスできるターミナルで、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


clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.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-164-97.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)。

正常でないメンバーのマシンを削除します。
```
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
```
1
1
正常でないノードのコントロールプレーンマシンの名前を指定します。
正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

新しいマシンが作成されたことを確認します。

$ 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-154-204.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-164-97.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-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   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: 新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

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

注記

マシンセットに使用しているサブネット ID を確認し、それが正しいアベイラビリティーゾーン内にあることを確認してください。

コントロールプレーンマシンセットが存在しない場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。

正常でないメンバーのマシンを取得します。

クラスターにアクセスできるターミナルで、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


clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.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-164-97.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)。

マシン設定をファイルシステムのファイルに保存します。
```
$ oc get machine clustername-8qw5l-master-0 \ 
```
1
```
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
```
1
正常でないノードのコントロールプレーンマシンの名前を指定します。

直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

status セクション全体を削除します。

status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus

metadata.name フィールドを新規の名前に変更します。
古いマシンと同じベース名を維持し、最後の番号を次の使用可能な番号に変更します。この例では、clustername-8qw5l-master-0 は clustername-8qw5l-master-3 に変更されています。
以下に例を示します。
```
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
```

spec.providerID フィールドを削除します。

  providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

正常でないメンバーのマシンを削除します。
```
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
```
1
1
正常でないノードのコントロールプレーンマシンの名前を指定します。

マシンが削除されたことを確認します。

$ 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-154-204.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-164-97.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

new-master-machine.yaml ファイルを使用して新しいマシンを作成します。
```
$ oc apply -f new-master-machine.yaml
```

新しいマシンが作成されたことを確認します。

$ 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-154-204.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-164-97.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-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   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: 新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

次のコマンドを入力して、クォーラムガードをオンに戻します。

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

次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。
```
$ oc get etcd/cluster -oyaml
```

シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

出力例

EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

すべての etcd Pod が適切に実行されていることを確認します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
出力例
```
etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
```
直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
```
1
1
forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

3 つの etcd メンバーがあることを確認します。

実行中の etcd コンテナーに接続し、影響を受けるノードになかった Pod の名前を渡します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
```

メンバーのリストを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

警告

必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。

6.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
リンクのコピー

この手順では、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーを置き換える手順を説明します。

前提条件

正常でない etcd メンバーを特定している。
etcd Pod がクラッシュループしていることを確認している。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
etcd のバックアップを取得している。
重要
問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。

手順

クラッシュループしている etcd Pod を停止します。
1. クラッシュループしているノードをデバッグします。
  クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
  $ oc debug node/ip-10-0-131-183.ec2.internal
  1
  1
  これを正常でないノードの名前に置き換えます。
2. ルートディレクトリーを /host に変更します。
  sh-4.2# chroot /host
3. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
  sh-4.2# mkdir /var/lib/etcd-backup
  sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
4. etcd データディレクトリーを別の場所に移動します。
  sh-4.2# mv /var/lib/etcd/ /tmp
  これでノードシェルを終了できます。

正常でないメンバーを削除します。

影響を受けるノード上にない Pod を選択します。

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

$ oc -n openshift-etcd get pods -l k8s-app=etcd

出力例

etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
```

メンバーのリストを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。

ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。
```
sh-4.2# etcdctl member remove 62bcf33650a7170a
```
出力例
```
Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
```

メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

これでノードシェルを終了できます。

次のコマンドを入力して、クォーラムガードをオフにします。
```
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
```
このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
削除された正常でない etcd メンバーの古いシークレットを削除します。
1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。
  $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
  1
  1
  この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
  以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
  出力例
  etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
2. 削除された正常でない etcd メンバーのシークレットを削除します。
  1. ピアシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
  2. サービングシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
  3. メトリクスシークレットを削除します。
    
    $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
etcd の再デプロイメントを強制的に実行します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
```
1
1
forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノードで etcd Pod が機能していることを確認します。

次のコマンドを入力して、クォーラムガードをオンに戻します。

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

次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。
```
$ oc get etcd/cluster -oyaml
```

出力例

EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

新しいメンバーが利用可能で、正常な状態にあることを確認します。
1. 再度実行中の etcd コンテナーに接続します。
  クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
  $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
2. すべてのメンバーが正常であることを確認します。
  sh-4.2# etcdctl endpoint health
  出力例
  https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms

6.2.4.3. マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーの置き換え
リンクのコピー

以下の手順では、マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーを置き換える手順を説明します。

インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。

前提条件

正常でないベアメタル etcd メンバーを特定している。
マシンが実行されていないか、ノードが準備状態にないことを確認している。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
etcd のバックアップを取得している。
重要
問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておく。

手順

正常でないメンバーを確認し、削除します。

影響を受けるノード上にない Pod を選択します。

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

$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

出力例

etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
```

メンバーのリストを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。etcdctl endpoint health コマンドは、置き換えの手順が完了し、新規メンバーが追加されるまで、削除されたメンバーをリスト表示します。

ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。
警告
必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。
```
sh-4.2# etcdctl member remove 7a8197040a5126c8
```
出力例
```
Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
```

メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

これでノードシェルを終了できます。

重要

メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。

次のコマンドを入力して、クォーラムガードをオフにします。
```
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
```
このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

以下のコマンドを実行して、削除された正常でない etcd メンバーの古いシークレットを削除します。

削除された正常でない etcd メンバーのシークレット一覧を表示します。
```
$ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
```
この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
```
etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
```

削除された正常でない etcd メンバーのシークレットを削除します。

ピアシークレットを削除します。

$ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted

サービングシークレットを削除します。

$ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted

メトリクスシークレットを削除します。

$ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted

正常でないメンバーのマシンを取得します。

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

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

出力例

NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned


examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

1: これは正常でないノードのコントロールプレーンマシンです (examplecluster-control-plane-2)。

以下のコマンドを実行して、Bare Metal Operator が利用可能であることを確認します。

$ oc get clusteroperator baremetal

出力例

NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.19.0    True        False         False      3d15h

次のコマンドを実行して、古い BareMetalHost オブジェクトを削除します。

$ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

出力例

baremetalhost.metal3.io "openshift-control-plane-2" deleted

次のコマンドを実行して、異常なメンバーのマシンを削除します。
```
$ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
```
BareMetalHost および Machine オブジェクトを削除すると、Machine コントローラーにより Node オブジェクトが自動的に削除されます。
何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除することで強制的に削除できます。
重要
Ctrl+c を押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。
正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。
1. 次のコマンドを実行して、マシン設定を編集します。
  $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
2. Machine カスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。
  finalizers: - machine.machine.openshift.io
  出力例
  machine.machine.openshift.io/examplecluster-control-plane-2 edited

以下のコマンドを実行して、マシンが削除されていることを確認します。

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

出力例

NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

次のコマンドを実行して、ノードが削除されたことを確認します。

$ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.32.3
openshift-control-plane-1 Ready master 3h24m v1.32.3
openshift-compute-0       Ready worker 176m v1.32.3
openshift-compute-1       Ready worker 176m v1.32.3

新しい BareMetalHost オブジェクトとシークレットを作成して BMC 認証情報を保存します。
```
$ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: openshift-control-plane-2-bmc-secret
  namespace: openshift-machine-api
data:
  password: <password>
  username: <username>
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    credentialsName: openshift-control-plane-2-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:b0:8a:a0
  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
```
注記
ユーザー名とパスワードは、他のベアメタルホストのシークレットで確認できます。bmc:address で使用するプロトコルは、他の bmh オブジェクトから取得できます。
重要
既存のコントロールプレーンホストから BareMetalHost オブジェクト定義を再利用する場合は、externallyProvisioned フィールドを true に設定したままにしないでください。
既存のコントロールプレーン BareMetalHost オブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisioned フラグが true に設定されている可能性があります。
検査が完了すると、BareMetalHost オブジェクトが作成され、プロビジョニングできるようになります。

利用可能な BareMetalHost オブジェクトを使用して作成プロセスを確認します。

$ oc get bmh -n openshift-machine-api

NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

新しいマシンが作成されたことを確認します。

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

出力例

NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned


examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

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

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

以下のコマンドを実行して、ベアメタルホストがプロビジョニングされ、エラーが報告されていないことを確認します。

$ oc get bmh -n openshift-machine-api

出力例

$ oc get bmh -n openshift-machine-api
NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

以下のコマンドを実行して、新規ノードが追加され、Ready の状態であることを確認します。

$ oc get nodes

出力例

$ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.32.3
openshift-control-plane-1 Ready master 4h26m v1.32.3
openshift-control-plane-2 Ready master 12m   v1.32.3
openshift-compute-0       Ready worker 3h58m v1.32.3
openshift-compute-1       Ready worker 3h58m v1.32.3

次のコマンドを入力して、クォーラムガードをオンに戻します。

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

次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。
```
$ oc get etcd/cluster -oyaml
```

出力例

EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

すべての etcd Pod が適切に実行されていることを確認します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
出力例
```
etcd-openshift-control-plane-0      5/5     Running     0     105m
etcd-openshift-control-plane-1      5/5     Running     0     107m
etcd-openshift-control-plane-2      5/5     Running     0     103m
```
直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
```
1
1
forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd メンバーがちょうど 3 つあることを確認するには、実行中の etcd コンテナーに接続し、影響を受けたノード上になかった Pod の名前を渡します。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
```
$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
```

メンバーのリストを確認します。

sh-4.2# etcdctl member list -w table

出力例

+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

注記

直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

以下のコマンドを実行して、すべての etcd メンバーが正常であることを確認します。

# etcdctl endpoint health --cluster

出力例

https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms

以下のコマンドを実行して、すべてのノードが最新のリビジョンであることを確認します。

$ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

AllNodesAtLatestRevision

6.2. 正常でない etcd メンバーの置き換え

6.2.1. 前提条件
リンクのコピー

6.2.2. 正常でない etcd メンバーの特定
リンクのコピー

6.2.3. 正常でない etcd メンバーの状態の判別
リンクのコピー

6.2.4. 正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.1. マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.3. マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーの置き換え
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2. 正常でない etcd メンバーの置き換え

6.2.1. 前提条件リンクのコピーリンクがクリップボードにコピーされました!

6.2.2. 正常でない etcd メンバーの特定リンクのコピーリンクがクリップボードにコピーされました!

6.2.3. 正常でない etcd メンバーの状態の判別リンクのコピーリンクがクリップボードにコピーされました!

6.2.4. 正常でない etcd メンバーの置き換えリンクのコピーリンクがクリップボードにコピーされました!

6.2.4.1. マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換えリンクのコピーリンクがクリップボードにコピーされました!

6.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換えリンクのコピーリンクがクリップボードにコピーされました!

6.2.4.3. マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーの置き換えリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.2.1. 前提条件
リンクのコピー

6.2.2. 正常でない etcd メンバーの特定
リンクのコピー

6.2.3. 正常でない etcd メンバーの状態の判別
リンクのコピー

6.2.4. 正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.1. マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
リンクのコピー

6.2.4.3. マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーの置き換え
リンクのコピー