いずれかのクラスタで問題が発生した場合は、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 バケットにアップロードするには、次のようにします。
API とサービス アカウントを設定します。
- Google Cloud プロジェクト内で、Cloud Storage API を有効にします。
- クラスタ スナップショットを Cloud Storage バケットに自動的にアップロードするために、
bmctl check cluster --snapshotコマンドが使用するサービス アカウントを作成します。 - サービス アカウントで Cloud Storage にデータをアップロードできるように、サービス アカウントに
storage.adminロールを付与します。 - サービス アカウント用の JSON キーをダウンロードします。
詳細については、Google サービスとサービス アカウントを有効にするをご覧ください。
次の
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からサービス アカウントのキーファイルのパスを取得します。
スナップショットを格納するバケットへの読み取りアクセス権を 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
スナップショットのシナリオ
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
カスタマイズしたスナップショット
次のような場合は、カスタマイズしたクラスタのスナップショットを作成することをおすすめします。
- デフォルトのスナップショットよりも多くのクラスタに関する情報を含める場合。
- デフォルトのスナップショットにある一部の情報を除外する場合。
カスタマイズしたスナップショットの作成方法
カスタマイズしたスナップショットを作成するには、スナップショット構成ファイルを使用する必要があります。次の手順では、構成ファイルを作成して変更し、それを使用してクラスタのカスタマイズしたスナップショットを作成する方法について説明しています。
クラスタで次のコマンドを実行して、出力をファイルに書き込み、スナップショット構成ファイルを作成します。
bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --kubeconfig KUBECONFIG_PATH
カスタマイズしたスナップショットに表示する情報の種類を定義します。これを行うには、ステップ 1 で作成したスナップショット構成ファイルを変更します。たとえば、スナップショットに特定のノードの実行時間などの追加情報を含める場合は、Linux コマンド
uptimeを構成ファイルの該当するセクションに追加します。構成ファイルの次のスニペットでは、スナップショット コマンドでノード 10.200.0.3 に関するuptime情報を指定する方法を示します。標準スナップショットにこの情報は表示されません。... nodeCommands: - nodes: - 10.200.0.3 commands: - uptime ...構成ファイルを変更して必要なスナップショットの種類を定義したら、次のコマンドを実行してカスタマイズしたスナップショットを作成します。
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 アドレスのリスト。管理クラスタに到達できない場合にスナップショットを作成するには、ノード IP アドレスを少なくとも 1 つ指定します。commands: 各ノードで実行するコマンド（と引数）のリスト。各コマンドの出力はスナップショットに含まれます。
nodeFiles: このセクションでは、次の情報を指定します。nodes: ファイルを収集するクラスタノードの IP アドレスのリスト。管理クラスタに到達できない場合にスナップショットを作成するには、ノード IP アドレスを少なくとも 1 つ指定します。files: 各ノードから取得するファイルのリスト。指定したファイルがノードで見つかった場合は、スナップショットに含まれます。
nodeSSHKey: SSH 認証鍵ファイルへのパス。管理クラスタに接続できない場合、このフィールドは必須です。
特定のエラーが発生した場合にスナップショットを作成する
停滞しているインストールまたはアップグレード中にデフォルトのスナップショットを作成する方法
管理クラスタ、ハイブリッド クラスタ、またはスタンドアロン クラスタをインストールまたはアップグレードすると、次の出力が表示されて bmctl が停止することがあります。
- クラスタ kubeconfig の準備が完了するまで待機しています。
- クラスタの準備が完了するまで待機しています。
- ノードプールの準備が完了するまで待機するしています。
- アップグレードが完了するのを待機しています。
インストールまたはアップグレードが停止している場合は、次のコマンドを実行することで、ブートストラップ クラスタでクラスタのスナップショットを作成できます。
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig
停滞しているインストールまたはアップグレード中にカスタマイズされたスナップショットを作成する方法
次の手順では、インストールまたはアップグレードが停滞しているときに、クラスタのカスタマイズ スナップショットを作成する方法を説明します。
アーカイブからクラスタのスナップショット構成ファイルを取得します。
スナップショットに目的の情報が含まれるように、スナップショット構成ファイルを変更します。
次のコマンドを実行して、カスタマイズしたスナップショットを作成します。
bmctl check cluster --snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE --cluster=CLUSTER_NAME --kubeconfig=WORKSPACE_DIR/.kindkubeconfig
管理クラスタに到達できない場合にカスタマイズしたスナップショットを作成する方法
管理クラスタに到達できない場合は、クラスタのカスタマイズしたスナップショットを作成できます。次の手順では、管理クラスタに到達できない場合に、クラスタのカスタマイズしたスナップショットを作成する方法を示しています。
アーカイブからクラスタのスナップショット構成ファイルを取得します。
ノード セクションに、情報を取得するノードの IP アドレスを記載しますが、管理クラスタノードの IP アドレスは除外します。
次のコマンドを実行して、カスタマイズしたスナップショットを作成します。
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 のログの収集をご覧ください。