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

いずれかのクラスタで問題が発生した場合は、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: --service-account-key-file フラグを指定しなかった場合、bmctl は、環境変数 GOOGLE_APPLICATION_CREDENTIALS からサービス アカウントのキーファイルのパスを取得します。

  3. Google Cloud サポートがアップロードしたクラスタ スナップショットを表示するの説明に従ってサービス アカウントを作成し、Cloud カスタマーケアと共有します。

方法 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

スナップショットのシナリオ

bmctl check cluster --snapshot コマンドでは、2 つのシナリオがサポートされています。シナリオを指定するには、--scenario フラグを使用します。使用できる値は、次のリストのとおりです。

  • system: ログを含むシステム コンポーネントのスナップショットを収集します。

  • all: すべての Pod のスナップショット（ログを含む）を収集します。

管理クラスタまたはユーザー クラスタでこの 2 つのシナリオの両方を使用できます。たとえば、system シナリオを使用して管理クラスタのスナップショットを作成するには、次のコマンドを実行します。

bmctl check cluster --snapshot --snapshot-scenario system \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

all シナリオを使用して、ユーザー クラスタのスナップショットを作成する場合:

bmctl check cluster --snapshot --snapshot-scenario all \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_KUBECONFIG_PATH

スナップショットのドライランの実行

--snapshot-dry-run フラグを使用する場合、スナップショットは作成されません。代わりに、スナップショット コマンドが実行するアクションとスナップショット構成ファイルが出力されます。スナップショット構成ファイルについては、カスタマイズされたスナップショットの作成方法をご覧ください。

管理クラスタでスナップショットのドライランを実行するには、次のコマンドを入力します。

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

ユーザー クラスタでスナップショットのドライランを実行するには、次のコマンドを入力します。

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_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 check cluster --snapshot --cluster CLUSTER_NAME
    --node-ssh-key SSH_KEY_FILE
    --nodes NODE_1_IP_ADDRESS, NODE_2_IP_ADDRESS, ...

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

  • CLUSTER_NAME: スナップショットを取得するクラスタの名前。
  • SSH_KEY_FILE: ノード SSH 認証鍵ファイルのパス。
  • NODE_x_IP_ADDRESS: 情報を取得するクラスタノードの IP アドレス。

別の方法として、ノードの IP アドレスを別の行に一覧表示することもできます。

bmctl check cluster
    --snapshot --cluster CLUSTER_NAME \
    --node-ssh-key SSH_KEY_FILE \
    --nodes NODE_1_IP_ADDRESS \
    --nodes NODE_2_IP_ADDRESS
  ...