クラスタの問題の診断に活用できるスナップショットを作成する

いずれかのクラスタで問題が発生した場合は、Cloud カスタマーケアのヘルプを利用できます。カスタマーケアは、問題を診断するために使用できるクラスタのスナップショットをとるよう依頼することがありますスナップショットでは、クラスタとノードの構成ファイルがキャプチャされ、その情報が 1 つの tar ファイルにパッケージ化されます。

このドキュメントでは、クラスタのデフォルトのスナップショットか、よりカスタマイズされたスナップショットの作成方法について説明します。また、クラスタで特定のエラーが発生した場合に、スナップショットを作成する方法についても説明します。

デフォルトのスナップショット

この後のセクションでは、標準スナップショットの内容とその作成方法について説明します。カスタマイズしたスナップショットの詳細については、カスタマイズしたスナップショットのセクションをご覧ください。

デフォルトのスナップショットに含まれる情報

クラスタのスナップショットとは、クラスタに関する構成ファイルとログから成る tar ファイルのことです。具体的には、このコマンドのデフォルト構成で、クラスタに関する次の情報が取得されます。

  • Kubernetes のバージョン

  • kube-system と gke-system Namespace 内の Kubernetes リソースのステータス: クラスタ、マシン、ノード、Service、Endpoint、ConfigMap、ReplicaSet、CronJob、Pod とそのオーナー（Deployment、DaemonSet、StatefulSet を含む）

  • 各ノードの構成の詳細（IP アドレス、iptables ルール、マウント ポイント、ファイル システム、ネットワーク接続、実行中のプロセスなど）

  • bmctl check cluster --snapshot コマンドのログ

デフォルトのスナップショットには、クラスタの認証情報は含まれません。Cloud カスタマーケアによりその情報がリクエストされた場合は、クラスタ情報の取得をご覧ください。

スナップショット コマンドを実行したときに収集される情報の包括的なリストについては、構成ファイルの詳細に示されている構成ファイルをご覧ください。この構成ファイルには、デフォルトのスナップショットを作成するときに実行されるコマンドが示されています。

デフォルトのスナップショットの作成方法

クラスタのスナップショットは、bmctl check cluster コマンドで取得します。このコマンドを使用すると、次のいずれかの操作を行えます。 * スナップショットを作成し、そのスナップショットを Cloud Storage バケットに自動的にアップロードする。 * クラスタのスナップショットを作成し、ローカルマシンに保存してそのマシンでコマンドを実行する。

方法 1: デフォルトのスナップショットを作成して Cloud Storage バケットに自動的にアップロードする

スナップショットを作成して Cloud Storage バケットにアップロードするには、次のようにします。

  1. API とサービス アカウントを設定します。

    1. Google Cloud プロジェクト内で、Cloud Storage API を有効にします。
    2. サービス アカウントで Cloud Storage にデータをアップロードできるように、サービス アカウントに storage.admin ロールを付与します。
    3. サービス アカウント用の JSON キーをダウンロードします。

    詳細については、Google サービスとサービス アカウントを有効にするをご覧ください。

  2. 次の bmctl コマンドを実行して、スナップショットを作成し、Cloud Storage バケットに自動でアップロードします。

    bmctl check cluster --snapshot --cluster=CLUSTER_NAME
--kubeconfig=KUBECONFIG_PATH
--upload-to BUCKET_NAME
[--service-account-key-file SERVICE_ACCOUNT_KEY_FILE]

    このコマンド内で、次のエントリをクラスタ環境に固有の情報に置き換えます。

    • CLUSTER_NAME: スナップショットをとるクラスタの名前。
    • KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。（通常、kubeconfig ファイルのパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。ただし、WORKSPACE_DIR フラグでワークスペースを指定した場合は、WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig になります）。
    • BUCKET_NAME: 所有する Cloud Storage バケットの名前。
    • SERVICE_ACCOUNT_KEY_FILE_PATH: --service-account-key-file フラグを指定しなかった場合、bmctl は、環境変数 GOOGLE_APPLICATION_CREDENTIALS からサービス アカウントのキーファイルのパスを取得します。

  3. スナップショットを格納するバケットへの読み取りアクセス権を Cloud カスタマーケアに付与します。

    gsutil iam ch \
serviceAccount:service-PROJECT_ID@anthos-support.iam.gserviceaccount.com:roles/storage.objectViewer \
gs://BUCKET_NAME

方法 #2: ローカルマシンにデフォルトのスナップショットを作成する

作成したクラスタの状態を取得するには、次のコマンドを使用します。

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=KUBECONFIG_PATH

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

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

  • KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。（通常、kubeconfig ファイルのパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。ただし、WORKSPACE_DIR フラグでワークスペースを指定した場合は、WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig になります）。

このコマンドにより、tar ファイルがローカルマシンに出力されます。この tar ファイルの名前は、snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz の形式です。ここで、TIMESTAMP は、ファイルが作成された日時を意味します。この tar ファイルには、クラスタのシステム コンポーネントとマシンに関連するデバッグ情報が含まれています。

このコマンドを実行すると、次の名前空間からポッドに関する情報が収集されます。gke-system、gke-connect、capi-system、capi-webhook-system、cert-manager、capi-kubeadm-bootstrap-system

ただし、収集される診断情報の範囲は、--snapshot-scenario all フラグを使用して広げることができます。このフラグを使用すると、診断スナップショットの範囲が拡大され、クラスタ内のすべての Pod が含まれるようになります。

bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=CLUSTER_NAME \
--kubeconfig=KUBECONFIG_PATH

カスタマイズしたスナップショット

次のような場合は、カスタマイズしたクラスタのスナップショットを作成することをおすすめします。

カスタマイズしたスナップショットの作成方法

カスタマイズしたスナップショットを作成するには、スナップショット構成ファイルを使用する必要があります。次の手順では、構成ファイルを作成して変更し、それを使用してクラスタのカスタマイズしたスナップショットを作成する方法について説明しています。

  1. クラスタで次のコマンドを実行して、出力をファイルに書き込み、スナップショット構成ファイルを作成します。

     bmctl check cluster
--snapshot --snapshot-dry-run --cluster CLUSTER_NAME
--kubeconfig KUBECONFIG_PATH

  2. カスタマイズしたスナップショットに表示する情報の種類を定義します。これを行うには、手順 1 で作成したスナップショット構成ファイルを変更します。たとえば、特定のノードの実行時間など、スナップショットに追加情報を含める場合は、Linux コマンド uptime を構成ファイルの関連するセクションに追加します。構成ファイルの次のスニペットは、スナップショット コマンドがノード 10.200.0.3 に関する uptime 情報を提供する方法を示しています。この情報は、標準スナップショットでは表示されません。

    ...
nodeCommands:
- nodes:
  - 10.200.0.3
  commands:
  - uptime
...

  3. 構成ファイルを変更して必要なスナップショットの種類を定義したら、次のコマンドを実行してカスタマイズしたスナップショットを作成します。

     bmctl check cluster
--snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster
CLUSTER_NAME --kubeconfig KUBECONFIG_PATH

    --snapshot-config フラグの指示により、bmctl コマンドがスナップショット構成ファイルの内容を使用して、スナップショットに表示される情報を定義します。

構成ファイルの詳細

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

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

構成ファイル内の次のエントリは、上記のサンプル構成ファイルに表示されているエントリとは異なる場合があります。

  • nodeCommands セクションと nodeFiles セクション内のノードの IP アドレス
  • クラスタの nodeSSHKey のパス

構成ファイルのフィールド

スナップショット構成ファイルは、YAML 形式です。構成ファイルには、次のフィールドがあります。

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

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

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

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

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

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

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

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

  • nodeSSHKey: SSH 認証鍵ファイルへのパス。管理クラスタに接続できない場合、このフィールドは必須です。

特定のエラーが発生した場合にスナップショットを作成する

停滞しているインストールまたはアップグレード中にデフォルトのスナップショットを作成する方法

管理クラスタ、ハイブリッド クラスタ、またはスタンドアロン クラスタをインストールまたはアップグレードすると、次の出力が表示されて bmctl が停止することがあります。

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

インストールまたはアップグレードが停止している場合は、次のコマンドを実行することで、ブートストラップ クラスタでクラスタのスナップショットを作成できます。

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

停滞しているインストールまたはアップグレード中にカスタマイズされたスナップショットを作成する方法

次の手順では、インストールまたはアップグレードが停滞しているときに、クラスタのカスタマイズ スナップショットを作成する方法を説明します。

  1. アーカイブからクラスタのスナップショット構成ファイルを取得します。

  2. スナップショットに目的の情報が含まれるように、スナップショット構成ファイルを変更します。

  3. 次のコマンドを実行して、カスタマイズしたスナップショットを作成します。

    bmctl check cluster --snapshot
--snapshot-config=SNAPSHOT_CONFIG_FILE
--cluster=CLUSTER_NAME
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig

管理クラスタに到達できない場合にカスタマイズしたスナップショットを作成する方法

管理クラスタに到達できないことを示すエラーがクラスタで生成された場合、クラスタのデフォルトのスナップショットを作成することはできません。これは、特にデフォルトの bmctl コマンドが管理クラスタから情報の取得を試みるためです。デフォルトのコマンドで到達できない管理クラスタから情報を取得しようとすると、スナップショット コマンドは失敗します。

このため、管理クラスタに到達できない場合は、デフォルトのスナップショットではなく、クラスタのカスタマイズしたスナップショットを作成する必要があります。これにより、問題のある管理クラスタから情報をリクエストしない、カスタマイズしたスナップショットを作成できます。

次の手順では、管理クラスタに到達できない場合に、クラスタのカスタマイズしたスナップショットを作成する方法を示します。

  1. アーカイブからクラスタのスナップショット構成ファイルを取得します。

  2. ノード セクションには、情報を取得するノードの IP アドレスを記述しますが、必ず管理クラスタノードの IP アドレスは除外してください。

  3. 次のコマンドを実行して、カスタマイズしたスナップショットを作成します。

    bmctl check cluster
--snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE
--cluster=CLUSTER_NAME
--kubeconfig=KUBECONFIG_PATH

Ingress や Anthos Service Mesh の問題に関するログを収集する

bmctl スナップショットには、Ingress または Anthos Service Mesh の問題をトラブルシューティングする情報は含まれません。関連する診断ログを収集する方法の手順については、Anthos Service Mesh ドキュメントの Anthos Service Mesh のログの収集をご覧ください。