4.2. 正常でない etcd メンバーの置き換え
単一の異常な etcd メンバーを置き換えるプロセスは、etcd メンバーが異常な状態である理由が、マシンが実行されていないか、ノードの準備ができていないか、または etcd Pod がクラッシュループしているかどうかによって異なります。
コントロールプレーンホストの大部分を喪失した場合は、この手順ではなく、障害復旧手順に従って、以前のクラスター状態への復元 を行います。
コントロールプレーンの証明書が置き換えているメンバーで有効でない場合は、この手順ではなく、期限切れのコントロールプレーン証明書からの回復 手順を実行する必要があります。
コントロールプレーンノードが失われ、新規ノードが作成される場合、etcd クラスター Operator は新規 TLS 証明書の生成と、ノードの etcd メンバーとしての追加を処理します。
4.2.1. 正常でない 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.internaletcd メンバーが正常ではないことを示しています。
4.2.2. 正常でない 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 stopped1 - 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/unreachable1 - 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.31 - 1
- ノードが
NotReadyとしてリスト表示されている場合、ノードの準備はできていません。
ノードの準備ができていない 場合は、マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え の手順を実行します。
etcd Pod がクラッシュループしている かどうかを確認します。
マシンが実行され、ノードが準備できている場合は、etcd Pod がクラッシュループしているかどうかを確認します。
すべてのコントロールプレーンノードが
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.3etcd 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 6h9m1 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 メンバーの置き換え に関する手順を実行します。
4.2.3. 正常でない etcd メンバーの置き換え リンクのコピーリンクがクリップボードにコピーされました!
正常でない etcd メンバーの状態に応じて、以下のいずれかの手順を使用します。
- マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え
- 正常でないクラスターへのプライマリーコントロールプレーンノードのインストール
- etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
- 異常停止したベアメタル etcd メンバーの置き換え
4.2.3.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 メンバーの古いシークレットを削除します。
削除された正常でない etcd メンバーのシークレット一覧を表示します。
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal1 - 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削除された正常でない etcd メンバーのシークレットを削除します。
ピアシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internalサービングシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internalメトリクスシークレットを削除します。
$ 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 stopped1 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-01 - 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 running1 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 は自動的にスケールアップします。
インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン 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 stopped1 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: AWSMachineProviderStatusmetadata.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-01 - 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 runningnew-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 running1 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 が自動的に同期します。
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ 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=merge1 - 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 メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。
4.2.3.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え リンクのコピーリンクがクリップボードにコピーされました!
この手順では、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーを置き換える手順を説明します。
前提条件
- 正常でない etcd メンバーを特定している。
- etcd Pod がクラッシュループしていることを確認している。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。
手順
クラッシュループしている etcd Pod を停止します。
クラッシュループしているノードをデバッグします。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc debug node/ip-10-0-131-183.ec2.internal1 - 1
- これを正常でないノードの名前に置き換えます。
ルートディレクトリーを
/hostに変更します。sh-4.2# chroot /host既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
sh-4.2# mkdir /var/lib/etcd-backupsh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/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 メンバーの古いシークレットを削除します。
削除された正常でない etcd メンバーのシークレット一覧を表示します。
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal1 - 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削除された正常でない etcd メンバーのシークレットを削除します。
ピアシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internalサービングシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internalメトリクスシークレットを削除します。
$ 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=merge1 - 1
forceRedeploymentReason値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノードで etcd Pod が機能していることを確認します。
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ 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 コンテナーに接続します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internalすべてのメンバーが正常であることを確認します。
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
4.2.3.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 provisioned1 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-2BareMetalHostおよびMachineオブジェクトを削除すると、MachineコントローラーによりNodeオブジェクトが自動的に削除されます。何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除することで強制的に削除できます。
重要Ctrl+cを押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。
次のコマンドを実行して、マシン設定を編集します。
$ oc edit machine -n openshift-machine-api examplecluster-control-plane-2Machineカスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。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 provisioned1 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シングルノードの 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-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=merge1 - 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