クラスタの問題の診断

Version 1.9 

• 最新バージョン
• バージョン 1.16
• 以前のバージョン（サポート対象外）

このドキュメントでは、gkectl diagnose を使用してクラスタの問題を診断する方法について説明します。

概要

gkectl ツールには、クラスタの問題を解決するために 2 つのコマンド（gkectl diagnose cluster と gkectl diagnose snapshot）が用意されています。これらのコマンドは、管理者クラスタとユーザー クラスタの両方で機能します。

gkectl diagnose cluster

クラスタでヘルスチェックを実行し、エラーを報告します。次のコンポーネントでヘルスチェックを実行します。

• VCenter
  • 認証情報
  • DRS
  • アンチ アフィニティ グループ
  • ネットワーク
  • バージョン
  • データセンター
  • データストア
  • リソースプール
  • フォルダ
  • ネットワーク
• ロードバランサ（F5、Seesaw、手動）
• ユーザー クラスタとノードプール
• クラスタ オブジェクト
• マシン オブジェクトと対応するクラスタノード
• kube-system と gke-system の Namespace にある Pod
• ターゲット クラスタがユーザー クラスタの場合のユーザー コントロール プレーン
• クラスタ内の vSphere 永続ボリューム
• ユーザーおよび管理クラスタの vCPU（仮想 CPU）とメモリの競合シグナル
• ユーザーおよび管理クラスタの ESXi のホスト CPU 使用率とメモリ使用量の事前構成アラーム。
• 1 日のうちの時間（TOD）
• Dataplane V2 が有効になっているクラスタのノード ネットワーク ポリシー

gkectl diagnose snapshot

クラスタのステータス、構成、ログを tarball ファイルに圧縮します。具体的には、このコマンドのデフォルト構成で、クラスタに関する次の情報が取得されます。

• Kubernetes のバージョン

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

• ターゲット クラスタがユーザー クラスタである場合のユーザー コントロール プレーンのステータス（ユーザー クラスタのコントロール プレーンは管理クラスタで実行されます）

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

• 管理クラスタのコントロール プレーン ノードから取得したコンテナログ。Kubernetes API サーバーを使用できない場合

• リソースプールに基づいた vSphere 情報（VM オブジェクトとそれらのイベントなど）。VM に関連付けられたデータセンター、クラスタ、ネットワーク、Datastore の各オブジェクトも含まれます。

• 仮想サーバー、仮想アドレス、プール、ノード、モニターなどの F5 BIG-IP ロードバランサ情報

• gkectl diagnose snapshot コマンドのログ

• スナップショット内のすべてのファイルの HTML インデックス ファイル

• 必要に応じて、クラスタのインストールとアップグレードに使用されるクラスタ構成ファイル

認証情報（vSphere と F5 の認証情報など）は、tarball が作成される前に削除されます。

クラスタの診断

gke diagnose cluster を実行すると、クラスタに関する一般的な問題を確認できます。

注: --kubeconfig フラグは必ず管理クラスタの kubeconfig ファイルを指す必要があります。ユーザー クラスタの kubeconfig を指定した場合、gkectl diagnose はエラーを返します。

注: ターゲット クラスタに VIP の問題がある場合は、--config を使用して、管理クラスタの構成ファイルを提供します。これにより、より詳細なデバッグ情報が得られます。

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

出力例:

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

管理クラスタの診断

管理クラスタは、その名前か kubeconfig を渡すだけで診断できます。

管理クラスタの kubeconfig の使用

管理クラスタの kubeconfig を渡すと、gkectl は自動的に管理クラスタを選択します。

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

管理クラスタ名の使用

管理クラスタ名を取得するには、次のコマンドを実行します。

kubectl get cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

次に、管理クラスタ名を gkectl diagnose cluster に渡します。

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[ADMIN_CLUSTER_NAME]

管理クラスタが正常に機能している場合は、gkectl diagnose cluster で次のような出力が返されます。

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

ユーザー クラスタの診断

クラスタを診断するには、まずユーザー クラスタの名前を取得します。

kubectl get cluster --kubeconfig=[USER_CLUSTER_KUBECONFIG]

次に、管理クラスタの kubeconfig とユーザー クラスタの名前を渡します。

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
  --cluster-name=[USER_CLUSTER_NAME]

注: ユーザー クラスタの kubeconfig を指定すると、gkectl diagnose はエラーを返します。

ユーザー クラスタが正常に機能している場合は、gkectl diagnose cluster で次のような出力が返されます。

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in 

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

原因が判明しているクラスタの問題のトラブルシューティング

gke diagnose cluster コマンドの実行時に次のような問題が発生した場合の解決策を次に示します。

.

事象	考えられる原因	解決策
管理クラスタおよびユーザー クラスタのどちらからも Kubernetes API サーバーにアクセスできない。	仮想マシンの OOB（すぐに使用できる）メモリ レイテンシ グラフを確認します。理想的なメモリ レイテンシはゼロに近いことです。また、メモリの競合により、CPU の競合が発生する可能性もあります。さらに、CPU readiness グラフは、スワップの増加に伴って急増する場合があります。	物理メモリを増やします。その他のオプションについては、VMware のトラブルシューティング ヒントをご覧ください。
ノードプールの作成でタイムアウトが発生する。	VMDK の読み取りと書き込みのレイテンシが高くなっています。仮想ディスクの読み取りと書き込みレイテンシの VM ヘルス OOB を確認します。VMware によると、レイテンシの合計が 20 ミリ秒を上回ると、問題が発生していることを意味します。	ディスク パフォーマンスの問題が発生した場合の VMware の解決策をご覧ください。

クラスタの状態のキャプチャ

gkectl diagnose cluster がエラーを見つけた場合、クラスタの状態をキャプチャし、Google に情報を提供する必要があります。そのためには、gkectl diagnose snapshot コマンドを使用します。

gkectl diagnose snapshot にはオプションのフラグ --config があります。クラスタに関する情報の収集に加えて、このフラグは、クラスタの作成またはアップグレードに使用された Anthos clusters on VMware 構成ファイルを収集します。

注: --kubeconfig フラグは必ず管理クラスタの kubeconfig ファイルを指す必要があります。ユーザー クラスタの kubeconfig を指定すると、gkectl diagnose はエラーを返します。

管理クラスタの状態のキャプチャ

管理クラスタの状態をキャプチャするには、次のコマンドを実行します。ここで、--config はオプションです。

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] --config

注: ターゲット クラスタに VIP の問題がある場合は、--config を使用して管理クラスタの構成ファイルを提供してください。これにより、より詳細なデバッグ情報が得られます。

出力には、ファイルの一覧と tarball ファイルの名前が含まれます。

Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"...
   Using default snapshot configuration...
   Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE
   Taking snapshots...
       commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       ...
       nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet
       nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log
       ...
   Snapshot succeeded. Output saved in [TARBALL_FILE_NAME].tar.gz.

tarball ファイルをディレクトリに抽出するには、次のコマンドを実行します。

tar -zxf [TARBALL_FILE_NAME] --directory [EXTRACTION_DIRECTORY_NAME]

スナップショットにより生成されたファイルのリストを表示するには、次のコマンドを実行します。

cd [EXTRACTION_DIRECTORY_NAME]/[EXTRACTED_SNAPSHOT_DIRECTORY]
ls kubectlCommands
ls nodes/[NODE_NAME]/commands
ls nodes/[NODE_NAME]/files

特定の操作の詳細を確認するには、表示されたファイルのいずれかを開きます。

管理クラスタの SSH 認証鍵の指定

管理クラスタのスナップショットを取得すると、gkectl は管理クラスタの秘密 SSH 認証鍵を自動的に検索します。--admin-ssh-key-path パラメータを使用して、鍵を明示的に指定することもできます。

SSH を使用してクラスタノードに接続するの手順に沿って、SSH 認証鍵をダウンロードします。

次に、gkectl diagnose snapshot コマンドで、--admin-ssh-key-path をデコードされた鍵ファイルパスに設定します。

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--admin-ssh-key-path=[PATH_TO_DECODED_KEY]

ユーザー クラスタの状態のキャプチャ

ユーザー クラスタの状態をキャプチャするには、次のコマンドを実行します。

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME]

出力には、ファイルの一覧と tarball ファイルの名前が含まれます。

Taking snapshot of user cluster "[USER_CLUSTER_NAME]"...
Using default snapshot configuration...
Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    ...
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    ...
    nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet
    nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log
    ...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

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

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

• system: （デフォルト）システム Namespace（kube-system と gke-system）のスナップショットを収集します。

• system-with-logs: ログを含む system スナップショットを収集します。

• all: すべての Namespace のスナップショットを収集します。

• all-with-logs: ログを含む all スナップショットを収集します。

4 つのシナリオはそれぞれ管理クラスタまたはユーザー クラスタで使用できるため、考えられる置換は 8 つあります。いくつかの方法を、次に例として示します。

system シナリオを使用して、管理クラスタのスナップショットを作成する場合:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=system

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

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=system-with-logs

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

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=all

all-with-logs シナリオを使用して、管理クラスタのスナップショットを作成する場合:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=all-with-logs

--log-since を使用してスナップショットを制限する

system-with-logs と all-with-logs のシナリオでは、--log-since フラグを使用してログ収集を最近の期間に制限できます。たとえば、過去 2 日間または過去 3 時間のログのみを収集できます。デフォルトでは、diagnose snapshot はすべてのログを収集します。

ログの収集期間を制限するには:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[CLUSTER_NAME] \
--scenario=system-with-logs \
--log-since=[DURATION]

[DURATION] は、120m や 48h などの値に置き換えます。

注:

• --log-since フラグは、kubectl ログと journalctl ログでのみサポートされます。
• カスタマイズされたスナップショット構成では、--log-since などのコマンドフラグは使用できません。

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

--dry-run フラグを使用して、実行するアクションとスナップショット構成を表示できます。

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

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[ADMIN_CLUSTER_NAME] \
--dry-run

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

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--dry-run

スナップショット構成の使用

4 つのシナリオがニーズを満たさない場合は、--snapshot-config フラグを使用してスナップショット構成ファイルを渡すことで、カスタマイズされたスナップショットを作成できます。

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--snapshot-config=[SNAPSHOT_CONFIG_FILE]

スナップショット構成の生成

特定のシナリオのスナップショット構成を生成するには、--scenario フラグと --dry-run フラグを渡します。たとえば、ユーザー クラスタのデフォルトのシナリオ（system）のスナップショット構成を表示するには、次のコマンドを入力します。

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=system
--dry-run

出力は次のようになります。

numOfParallelThreads: 10
excludeWords:
- password
kubectlCommands:
- commands:
  - kubectl get clusters -o wide
  - kubectl get machines -o wide
  - kubectl get clusters -o yaml
  - kubectl get machines -o yaml
  - kubectl describe clusters
  - kubectl describe machines
  namespaces:
  - default
- commands:
  - kubectl version
  - kubectl cluster-info
  - kubectl get nodes -o wide
  - kubectl get nodes -o yaml
  - kubectl describe nodes
  namespaces: []
- commands:
  - kubectl get pods -o wide
  - kubectl get deployments -o wide
  - kubectl get daemonsets -o wide
  - kubectl get statefulsets -o wide
  - kubectl get replicasets -o wide
  - kubectl get services -o wide
  - kubectl get jobs -o wide
  - kubectl get cronjobs -o wide
  - kubectl get endpoints -o wide
  - kubectl get configmaps -o wide
  - kubectl get pods -o yaml
  - kubectl get deployments -o yaml
  - kubectl get daemonsets -o yaml
  - kubectl get statefulsets -o yaml
  - kubectl get replicasets -o yaml
  - kubectl get services -o yaml
  - kubectl get jobs -o yaml
  - kubectl get cronjobs -o yaml
  - kubectl get endpoints -o yaml
  - kubectl get configmaps -o yaml
  - kubectl describe pods
  - kubectl describe deployments
  - kubectl describe daemonsets
  - kubectl describe statefulsets
  - kubectl describe replicasets
  - kubectl describe services
  - kubectl describe jobs
  - kubectl describe cronjobs
  - kubectl describe endpoints
  - kubectl describe configmaps
  namespaces:
  - kube-system
  - gke-system
  - gke-connect.*
prometheusRequests: []
nodeCommands:
- nodes: []
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - sudo iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1
  - sudo docker ps -a
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - sudo conntrack --count
nodeFiles:
- nodes: []
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/nf_conntrack_max
seesawCommands: []
seesawFiles: []
nodeCollectors:
- nodes: []
f5:
  enabled: true
vCenter:
  enabled: true

• numOfParallelThreads: スナップショットの作成に使用される並列スレッドの数。

• excludeWords: スナップショットから除外する単語のリスト（大文字と小文字は区別されません）。これらの単語を含む行はスナップショットの結果から削除されます。指定したかどうかにかかわらず、「パスワード」は常に除外されます。

• kubectlCommands: 実行する kubectl コマンドのリスト。結果は保存されます。コマンドは、対応する Namespace に対して実行されます。kubectl logs コマンドの場合、対応する Namespace 内のすべての Pod とコンテナが自動的に追加されます。正規表現が、Namespace の指定に使用されます。Namespace を指定しない場合は、default Namespace が使用されます。

• nodeCommands: 対応するノードで実行するコマンドのリスト。結果は保存されます。ノードが指定されていない場合、ターゲット クラスタ内のすべてのノードが考慮されます。

• nodeFiles: 対応するノードから収集されるファイルのリスト。ファイルは保存されます。ノードが指定されていない場合、ターゲット クラスタ内のすべてのノードが考慮されます。

• seesawCommands: Seesaw ロードバランサの情報を収集するために実行するコマンドのリスト。クラスタで Seesaw ロードバランサが使用されている場合は、結果が保存されます。

• seesawFiles: Seesaw ロードバランサに関して収集されるファイルのリスト。

• nodeCollectors: Cilium ノードで eBPF 情報を収集するために実行されるコレクタ。

• f5: F5 BIG-IP ロードバランサに関する情報の収集を有効にするフラグ。

• vCenter: vCenter に関する情報の収集を有効にするフラグ。

• prometheusRequests: Prometheus リクエストのリスト。結果は保存されます。

スナップショットを Google Cloud Storage バケットにアップロードする

特定のクラスタのすべてのスナップショットを Google Cloud Storage バケットにアップロードすると、レコードの保持、分析、保存が容易になります。これは、Google Cloud サポートの支援が必要な場合に特に役立ちます。

コマンドを実行する前に、これらの設定要件を満たしていることを確認してください。

• フリートホスト プロジェクトで storage-api.googleapis.com を有効にします。別のプロジェクトを使用することもできますが、フリートホスト プロジェクトをおすすめします。

gcloud services enable --project=PROJECT_ID \
storage-api.googleapis.com

• 親プロジェクトのサービス アカウントに roles/storage.admin を付与し、--service-account-key-file パラメータを使用してサービス アカウントの json キーファイルを渡します。任意のサービス アカウントを使用できますが、connect 登録サービス アカウントをおすすめします。詳細については、サービス アカウントをご覧ください。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \
    --role "roles/storage.admin"

CONNECT_REGISTER_SERVICE_ACCOUNT は、connect register サービス アカウントに置き換えます。

• まだ作成していない場合は、手順に沿って Google Cloud サービス アカウントを作成し、Google Cloud サポートとバケットへのアクセスを共有します。

これらの要件を満たしたら、次のコマンドでスナップショットをアップロードできます。

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name CLUSTER_NAME \
--upload-to BUCKET_NAME  \
--service-account-key-file SERVICE_ACCOUNT_KEY_FILE \
--share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

SERVICE_ACCOUNT_KEY_FILE は、サービス アカウント キーのファイル名に置き換えます。

--share-with フラグには、サービス アカウント名のリストを指定できます。GOOGLE_SUPPORT_SERVICE_ACCOUNT を、Google サポートが提供する他のサービス アカウントとともに、Google サポートが提供する Google サポート サービス アカウントに置き換えます。

使用する場合は、オプションの share-with フラグを --upload-to と --service-account-file と併用する必要があります。これにより、スナップショットを最初に Google Cloud Storage にアップロードし、読み取り権限を共有することが可能です。

出力例:

Using "system" snapshot configuration...
Taking snapshot of user cluster CLUSTER_NAME...
Setting up CLUSTER_NAME ssh key...DONE
Using the gke-connect register service account key...
Setting up Google Cloud Storage bucket for uploading the snapshot...DONE
Taking snapshots in 10 thread(s)...
   ...
Snapshot succeeded.
Snapshots saved in "SNAPSHOT_FILE_PATH".
Uploading snapshot to Google Cloud Storage......  DONE
Uploaded the snapshot successfully to gs://BUCKET_NAME/CLUSTER_NAME/xSNAPSHOT_FILE_NAME.
Shared successfully with service accounts:
GOOGLE_SUPPORT_SERVICE_ACCOUNT

既知の問題

バージョン 1.1.2-gke.0: パスが複数のデータセンターに解決される

Anthos clusters on VMware のリリースノートをご覧ください。

バージョン 1.1.x: Volume がマシンに接続されていない

Anthos clusters on VMware のリリースノートをご覧ください。