トラブルシューティング: クラスタの診断とリセット

クラスタを診断またはチェックして、問題をデバッグし、クラスタの状態のスナップショットを取得できます。また、インストールの途中で失敗してクラスタからエラーが返された場合や、クラスタが正しく実行できない場合は、クラスタをリセットできます。

bmctl check cluster を使用したクラスタの診断

作成したクラスタの状態を取得するには、bmctl check cluster コマンドを使用します。コマンドのフラグを指定すると、コマンドの診断範囲を指定して、重要な情報を取得できます。

診断情報により、問題の検出とデプロイのデバッグを効率的に行うことができます。コマンドを実行すると、定義した範囲に関連するクラスタとノード構成ファイルがすべて収集され、1 つの tar アーカイブにパッケージ化されます。

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

以下を置き換えます。

  • CLUSTER_NAME: 対象とするクラスタの名前。

  • ADMIN_KUBECONFIG_PATH: 管理クラスタの kubeconfig kubeconfig ファイルのパス。

このコマンドは、指定したクラスタ内のすべてのシステム コンポーネントとマシンから収集したデバッグ情報を含む tar アーカイブを出力します。

収集する診断情報の範囲は、次のコマンドフラグで変更できます。

  • --snapshot-scenario all フラグを指定すると、指定したクラスタのすべての Pod が対象になるため、診断のスナップショットの範囲が広がります。
bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • --snapshot-dry-run フラグは、--snapshot-config string フラグと連携して機能します。--snapshot-dry-run フラグを使用すると、構成ファイルが出力されます。このファイルを変更して診断範囲をカスタマイズできます。診断範囲には特定の Pod、名前空間、ノードコマンドなどが含まれます。

--snapshot-dry-run フラグで作成した出力ファイルを変更したら、次のようにそのファイルを入力として使用し、--snapshot-config string フラグで指定した範囲を診断できます。このフラグを省略すると、デフォルト構成が適用されます。

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • --snapshot-config フラグを使用すると、bmctl コマンドはスナップショットの構成ファイルで指定された範囲オプションを使用します。通常は、--snapshot-dry-run フラグを使用してスナップショットの構成ファイルを作成します。
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

管理クラスタにアクセスできない場合のクラスタの診断

管理クラスタが停止しているか、到達できない場合は、スナップショット構成ファイルを使用してクラスタのスナップショットを作成します。スナップショット構成ファイルは、YAML 形式です。構成ファイルには、クラスタの情報をキャプチャする方法を指定する次のフィールドが含まれています。

  • numOfParallelThreads: 通常、スナップショット ルーティンは多くのコマンドを実行します。複数の並列スレッドは、ルーティンの実行の高速化に役立ちます。次の例に示すように、numOfParallelThreads を 10 に設定することをおすすめします。スナップショットに時間がかかりすぎる場合は、この値を増やしてください。

  • excludeWords: スナップショットにはクラスタノードの大量のデータが含まれています。excludeWords を使用して、スナップショットを共有する際のセキュリティ リスクを軽減します。たとえば、対応するパスワード文字列が特定されないように password を除外します。

  • nodeCommands: このセクションでは、次の情報を指定します。

    • nodes: 情報を収集するクラスタノードの IP アドレスのリスト。管理クラスタに到達できない場合にスナップショットを作成するには、少なくとも 1 つのノード IP アドレスを指定します。

    • commands: 各ノードで実行するコマンド（と引数）のリスト。各コマンドの出力はスナップショットに含まれます。

  • nodeFiles: このセクションでは、次の情報を指定します。

    • nodes: ファイルを収集するクラスタノードの IP アドレスのリスト。管理クラスタに到達できない場合にスナップショットを作成するには、少なくとも 1 つのノード IP アドレスを指定します。

    • files: 各ノードから取得するファイルのリスト。指定したファイルがノードで見つかった場合は、スナップショットに含まれます。

  • nodeSSHKey: ノードの SSH 認証鍵ファイルのパス。このフィールドは、管理クラスタに到達できない場合にスナップショットを作成する場合に必要です。

次のコマンドを使用して、スナップショット構成ファイルを使用してスナップショットを作成します。

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

SNAPSHOT_CONFIG は、スナップショット構成ファイルのパスに置き換えます。

次のスナップショット構成ファイルのサンプルは、スナップショットの作成に使用される標準のコマンドとファイルを示していますが、診断情報を追加する必要がある場合は、さらにコマンドやファイルを追加できます。

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file to each nodes

管理クラスタのインストール / アップグレードが停止した場合のスナップショットを作成する

管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタをインストールするときに、bmctl が次の出力でスタックする場合に

  • クラスタ kubeconfig の準備が完了するまで待機しています。
  • クラスタの準備が完了するまで待機しています。
  • ノードプールの準備が完了するまで待機する

または、管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタのアップグレード時に

  • アップグレードが完了するのを待機しています。

次のコマンドを実行して、ブートストラップ クラスタを使用してスナップショットを取得できます。

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

bmctl reset cluster によるクラスタのリセット

クラスタが正しくインストールされなかった場合、ノードをリセットしてクリーンな状態に戻すことができます。その後、構成を変更してクラスタを再インストールできます。

セルフマネージド クラスタのリセット

自己管理型のクラスタ（管理クラスタなど）をリセットするには、次のコマンドを実行します。

bmctl reset --cluster CLUSTER_NAME

CLUSTER_NAME は、リセットするクラスタの名前に置き換えます。

ユーザー クラスタのリセット

ユーザー クラスタをリセットするには、次のコマンドを実行します。

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

CLUSTER_NAME をリセットするユーザー クラスタの名前に置き換え、ADMIN_KUBECONFIG_PATH を関連する管理クラスタの kubeconfig ファイルへのパスに置き換えます。bmctl では、--admin-kubeconfig フラグのエイリアスとして --kubeconfig の使用がサポートされます。

クラスタの詳細のリセット

クラスタのタイプに関係なく、リセット コマンドはクラスタ全体に適用されます。クラスタ内のノードのサブセットを対象にするオプションはありません。

bmctl cluster reset コマンドからの出力は、次のサンプルのようになります。

bmctl reset --cluster cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

リセット オペレーションで、bmctl はまず GKE Hub メンバーシップの登録を削除して、影響を受けるノードのクリーンアップを行います。リセット中、ストレージのマウントと anthos-system StorageClass からのデータも削除されます。

bcmctl は、すべてのノードに kubeadm reset を実行し、クラスタ ネットワーキングに使用されているトンネル インターフェースを削除して、次のディレクトリを削除します。

  • /etc/kubernetes
  • /etc/cni/net.d
  • /root/.kube
  • /var/lib/kubelet

ロードバランサ ノードの場合、bmctl は次のアクションも実行します。

  • keepalived サービスと haproxy サービスを無効にします。
  • keepalived と haproxy の構成ファイルを削除します。

リセットツールは、クラスタの構成ファイルが現在の作業ディレクトリの次の場所にあることを前提としています。

bmctl-workspace/cluster name/cluster name.yaml