ストレージ、ネットワーク、OS の構成ミスが原因で発生する Google Distributed Cloud のノードで障害が発生した場合は、クラスタの健全性を効率的に復元する必要があります。クラスタの健全性を復元すると、ノード障害をトラブルシューティングできます。このドキュメントでは、ノードをリセットし、必要に応じてノードを強制的に削除することで、ノード障害のシナリオから復旧する方法について説明します。
ノードに障害が発生していない状況でクラスタに対してノードを追加または削除する場合は、クラスタを更新するをご覧ください。
さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。ノードのリセット
ノードに障害が発生した場合、ノードに到達できない可能性があるため、ノードでリセット コマンドを実行できない場合があります。その場合は、ノードをクラスタから強制的に削除する必要があります。
ノードを完全にリセットしてクラスタを更新すると、次のアクションが発生します。
kubeadm reset
と同様にノードがリセットされ、マシンはプリインストールされた状態に戻ります。- ノードへの関連する参照が、ノードプールとクラスタのカスタム リソースから削除されます。
ノードをリセットするための以下の bmctl
コマンドの中には、リセット コマンド(ステップ 1)がスキップされるかどうかを --force
パラメータで示すものがあります。--force
パラメータが使用されている場合、bmctl
は削除ステップ(ステップ 2)のみを実施し、リセット コマンドを実行しません。
ワーカーノードを削除する
クラスタからワーカーノードを削除するには、次の手順を行います。
ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。
bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
次のように置き換えます。
COMMA_SEPARATED_IP
: リセットするノードの IP アドレス(例:10.200.0.8,10.200.0.9
)。CLUSTER_NAME
: 障害が発生したノードを含むターゲット クラスタの名前。ADMIN_KUBECONFIG
: 管理クラスタのkubeconfig
ファイルのパス。
このコマンドが成功すると、ノードを診断し、初期障害の原因となった構成ミスを修正できます。このセクションの残りの手順はスキップします。
前述のノードリセット手順が失敗した場合は、ノードをクラスタから強制的に削除します。この強制削除は、前のステップ(リセットコマンドを実行する)をスキップし、ノードプールとクラスタのカスタム リソースからノードに関連する参照を削除する手順のみを以下のとおりに行います。
bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --force
これでノードを診断し、初期障害の原因となった構成ミスを修正できるようになりました。
前の手順でノードクラスタからノードを強制的に削除した場合は、
bmctl reset
コマンドを再度実行してノードをリセットします。bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
単一のコントロール プレーン ノードを削除する
このプロセスはワーカーノードの場合と同じです。コントロール プレーン ノードの場合、bmctl
は etcd
メンバーシップも削除します。
障害が発生したノードを削除すると、クラスタの高可用性(HA)状態が停止します。高可用性状態に戻すには、正常なノードをクラスタに追加します。
クラスタからノードを削除するには、次の手順を行います。
ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。
bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
次の値を置き換えます。
COMMA_SEPARATED_IP
: リセットするノードの IP アドレス(例:10.200.0.8,10.200.0.9
)。CLUSTER_NAME
: 障害が発生したノードを含むターゲット クラスタの名前。ADMIN_KUBECONFIG
: 管理クラスタのkubeconfig
ファイルのパス。
このコマンドが成功すると、ノードを診断し、初期障害の原因となった構成ミスを修正できます。このセクションの残りの手順はスキップします。
ノードをリセットする前の手順が失敗した場合は、クラスタからノードを強制的に削除できます。この強制削除は、前のステップ(リセットコマンドを実行する)をスキップし、ノードプールとクラスタのカスタム リソースからノードに関連する参照を削除する手順のみを実行します。
bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --force
これでノードを診断し、初期障害の原因となった構成ミスを修正できるようになりました。
前の手順でノードクラスタからノードを強制的に削除した場合は、
bmctl reset
コマンドを再度実行してノードをリセットします。bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
HA コントロール プレーンでのクォーラムの損失
HA クラスタ内のコントロール プレーン ノードが多すぎて失敗状態になると、クラスタはクォーラムを失い、使用できなくなります。
管理クラスタを復元する必要がある場合は、リセット コマンドで kubeconfig
ファイルを指定しないでください。管理クラスタに kubeconfig
ファイルを指定すると、新しいクラスタでリセット オペレーションが強制的に実行されます。ユーザー クラスタを復元する場合は、kubeconfig
ファイルのパスを指定します。
クォーラムを失ったクラスタを復元するには、残りの正常なノードで次のコマンドを実行します。
bmctl restore --control-plane-node CONTROL_PLANE_NODE \ --cluster CLUSTER_NAME \ [--kubeconfig KUBECONFIG_FILE]
次のように置き換えます。
CONTROL_PLANE_NODE
: クラスタの一部として残っている正常なノードの IP アドレス。CLUSTER_NAME
: 障害が発生したノードを含むターゲット クラスタの名前。KUBECONFIG_FILE
: ユーザー クラスタを復旧する場合、ユーザー クラスタのkubeconfig
ファイルのパス。
障害が発生したノードを復旧した後、
bmctl reset
コマンドを実行してノードをリセットします。bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ [--kubeconfig KUBECONFIG_FILE]
次のように置き換えます。
COMMA_SEPARATED_IP
: リセットするノードの IP アドレス(例:10.200.0.8,10.200.0.9
)。CLUSTER_NAME
: 障害が発生したノードを含むターゲット クラスタの名前。KUBECONFIG_FILE
: 管理クラスタのkubeconfig
ファイルのパス。
障害が発生したノードがロードバランサ ノードプールの一部である場合、ノードの復旧後にコントロール プレーンの仮想 IP アドレスと競合し、新しいクラスタが不安定になる可能性があります。ノードを復旧したら、できるだけ早く、障害が発生したノードに対してリセット コマンドを実行します。
このプロセスでは、3 つのノードからなるコントロール プレーンの HA デプロイの障害復旧のみを処理します。このプロセスでは、5 つ以上のノードの HA 設定の復元をサポートしていません。
次のステップ
障害がない場合にクラスタに対してノードを追加または削除してノードのステータスを確認する方法については、クラスタの更新をご覧ください。
- さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。