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 メンバーの古いシークレットを削除します。
削除された正常でない 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 メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。