Google Distributed Cloud で障害が発生したノードをリセットする

Google Distributed Cloud のノードに障害が発生した場合(ストレージ、ネットワーク、OS の構成ミスなどにより発生する可能性があります)、クラスタの状態を効率的に復元する必要があります。クラスタの健全性を復元すると、ノード障害をトラブルシューティングできます。このドキュメントでは、ノードをリセットして、必要に応じてノードを強制的に削除することにより、ノードの障害シナリオから復旧する方法について説明します。

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

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

ノードをリセットする

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

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

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

ノードをリセットするための以下の bmctl コマンドの中には、リセット コマンド(ステップ 1)がスキップされるかどうかを --force パラメータで設定するものがあります。--force パラメータが使用されている場合、bmctl は削除ステップ(ステップ 2)のみを実行し、リセット コマンドを実行しません。

ワーカーノードを削除する

クラスタからワーカーノードを削除する手順は次のとおりです。

  1. ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。

    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 ファイルのパス。

    このコマンドが成功した場合は、ノードを診断し、初期障害の原因となった構成ミスを修正できます。このセクションの残りの手順はスキップします。

  2. 前述のノードリセット手順が失敗した場合は、ノードをクラスタから強制的に削除します。この強制削除は、前のステップ(リセット コマンドを実行する)をスキップし、ノードプールとクラスタのカスタム リソースからノードに関連する参照を削除する手順のみを実行します。

    bmctl reset nodes \
        --addresses COMMA_SEPARATED_IPS \
        --cluster CLUSTER_NAME \
        --kubeconfig ADMIN_KUBECONFIG \
        --force
    

    これでノードを診断し、初期障害の原因となった構成ミスを修正できるようになりました。

  3. 前の手順でノードクラスタからノードを強制的に削除した場合は、bmctl reset コマンドを再度実行してノードをリセットします。

    bmctl reset nodes \
        --addresses COMMA_SEPARATED_IPS \
        --cluster CLUSTER_NAME \
        --kubeconfig ADMIN_KUBECONFIG
    

単一のコントロール プレーン ノードを削除する

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

障害が発生したノードを削除すると、クラスタの高可用性(HA)状態が停止します。HA 状態に戻すには、正常なノードをクラスタに追加します。

クラスタからノードを削除するには、次の操作を行います。

  1. ノードを完全にリセットしてみます。ノードがリセットされると、ノードはクラスタから削除されます。

    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 ファイルのパス。

    このコマンドが成功した場合は、ノードを診断し、初期障害の原因となった構成ミスを修正できます。このセクションの残りの手順はスキップします。

  2. ノードをリセットする前の手順が失敗した場合は、クラスタからノードを強制的に削除できます。この強制削除は、前のステップ(リセット コマンドを実行する)をスキップし、ノードプールとクラスタのカスタム リソースからノードに関連する参照を削除する手順のみを実行します。

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG \
      --force
    

    これでノードを診断し、初期障害の原因となった構成ミスを修正できるようになりました。

  3. 前の手順でノードクラスタからノードを強制的に削除した場合は、bmctl reset コマンドを再度実行してノードをリセットします。

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG
    

HA コントロール プレーンでのクォーラムの損失

HA クラスタ内のコントロール プレーン ノードが多すぎて失敗状態になると、クラスタはクォーラムを失い、使用できなくなります。

管理クラスタを復元する必要がある場合は、リセット コマンドに kubeconfig ファイルを指定しないでください。管理クラスタに kubeconfig ファイルを指定すると、新しいクラスタでリセット オペレーションが強制的に実行されます。ユーザー クラスタを復元する場合は、kubeconfig ファイルのパスを指定します。

  1. クォーラムを失ったクラスタを復元するには、残りの正常なノードで次のコマンドを実行します。

    bmctl restore --control-plane-node CONTROL_PLANE_NODE \
        --cluster CLUSTER_NAME \
        [--kubeconfig KUBECONFIG_FILE]
    

    次のように置き換えます。

    • CONTROL_PLANE_NODE: クラスタの一部として残る正常なノードの IP アドレス。
    • CLUSTER_NAME: 障害が発生したノードを含むターゲット クラスタの名前。
    • KUBECONFIG_FILE: ユーザー クラスタを復旧する場合は、ユーザー クラスタの kubeconfig ファイルのパス。
  2. 障害が発生したノードを復旧した後、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 カスタマーケアにお問い合わせください。