GKE on Bare Metal で障害が発生したノードをリセットする

ストレージ、ネットワーク、OS の構成ミスなどが原因で GKE on Bare Metal のノードで障害が発生した場合は、クラスタの健全性を効率的に復元する必要があります。クラスタの健全性を復元すると、ノード障害をトラブルシューティングできます。

このドキュメントでは、ノードをリセットし、必要に応じてノードを強制的に削除することで、ノード障害のシナリオから復旧する方法について説明します。

ノードに障害が発生していない通常の状況でクラスタを追加または削除する場合は、クラスタを更新するをご覧ください。

概要

ノードに障害が発生した場合、ノードに到達できない可能性があるため、ノードでリセットコマンドを実行できない場合があります。その場合は、ノードをクラスタから強制的に削除する必要があります。

ノードを完全にリセットしてクラスタを更新すると、次のアクションが発生します。

kubeadm reset と同様にノードがリセットされ、マシンはプリインストールされた状態に戻ります。
ノードへの関連する参照がノードプールとクラスタのカスタムリソースから削除されます。

ワーカーノード

クラスタからノードを削除するには、まずノードを完全に削除します。

ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。
```
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
```

1 つのコントロールプレーンノードの障害

このプロセスはワーカーノードの場合と同じです。コントロールプレーンノードの場合、bmctl は etcd メンバーシップも削除します。

クラスタからノードを削除するには、まずノードを完全に削除します。

ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。
```
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 クラスタ内のコントロールプレーンノードが多すぎて失敗状態になると、クラスタはクォーラムを失い、使用できなくなります。

クォーラムを失ったクラスタを復元するには、残りの正常なノードで次のコマンドを実行します。
```
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 アドレスと競合し、新しいクラスタが不安定になる可能性があります。ノードを復旧したら、できるだけ早く、障害が発生したノードに対してリセットコマンドを実行します。

次のステップ

障害がない場合にクラスタに対してノードを追加または削除してノードのステータスを確認する方法については、クラスタの更新をご覧ください。