Google は、Google Distributed Cloud コネクテッド ハードウェアをリモートでモニタリングし、メンテナンスします。このため、Google エンジニアは Distributed Cloud 接続ハードウェアへの Secure Shell（SSH）アクセス権を持っています。Google が問題を検出すると、Google のエンジニアからお客様に連絡して、トラブルシューティングと解決を行います。問題をご自身で特定した場合は、直ちに Google サポートにお問い合わせのうえ、診断と解決を依頼してください。
Distributed Cloud コネクテッドのソフトウェア アップグレード
このセクションでは、Metrics Explorer を使用して、Distributed Cloud 接続クラスタでソフトウェア アップグレードが実行されているかどうかを確認する方法について説明します。
この手順では、次の Monitoring 指標を使用します。
現在のクラスタ バージョン（
/edge_cluster/current_cluster_version）: クラスタで実行されている Distributed Cloud 接続ソフトウェアの現在のバージョンを示します。ターゲット クラスタ バージョン（
/edge_cluster/target_cluster_version）: クラスタがアップグレードする Distributed Cloud 接続のターゲット バージョンを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- Google Cloud コンソールと Distributed Cloud 接続 Google Cloud プロジェクトへのアクセス権。
- Monitoring 指標を表示できる Monitoring 閲覧者 IAM ロール。
- （省略可）返される結果をフィルタリングするための、ターゲットの Distributed Cloud コネクテッド マシンの
machine_id値。
Metrics Explorer を使用して、クラスタの現在のソフトウェア バージョンとターゲット ソフトウェア バージョンを確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[構成] ページに移動します。
[指標を選択] をクリックします。
検索バーを使用して、クラスタ リソースタイプを検索します。完全なリソース識別子
edgecontainer.googleapis.com/Clusterを使用することもできます。返された結果で、[クラスタ] リソースタイプをクリックします。
クラスタの現在のソフトウェア バージョンを取得します。
[指標] セクションで、
current_cluster_version値を検索します。[マシンの稼働時間] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/edge_cluster/current_cluster_versionです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。
クラスタのターゲット ソフトウェア バージョンを取得します。
[クエリを追加] をクリックします。
[指標] セクションで、
target_cluster_version値を検索します。[Target Cluster Version] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/edge_cluster/target_cluster_versionです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。
表示されたグラフで、クラスタのソフトウェア アップグレードのステータスを確認します。
[Current Cluster Version] 行と [Target Cluster Version] 行に異なる値が表示されている場合、クラスタはソフトウェア アップグレード中です。
[Current Cluster Version] 行と [Target Cluster Version] 行に同じ値が表示されている場合、クラスタはソフトウェア アップグレードを行っていません。
次のコマンドを使用して、前の手順の結果を確認します。
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
次のように置き換えます。
CLUSTER_ID: ターゲット クラスタの ID。REGION: クラスタが作成された Google Cloud リージョン。
コマンドの出力で、次のフィールドの値をメモします。
statusフィールドの値がUPDATINGの場合、クラスタはソフトウェア アップグレード中です。clusterVersionフィールドとtargetVersionフィールドの値が異なる場合は、Metrics Explorer から返された値と照らし合わせて確認します。
結果を把握する
次の表に、Metrics Explorer と gcloud コマンドから返される結果を示します。
| クラスタの状態 | 診断 | 解決策 |
|---|---|---|
正常currentVersion と targetVersion の値が一致する`status` 値が RUNNING |
クラスタで Distributed Cloud コネクテッド ソフトウェアのターゲット バージョンが実行されている。 | なし |
アップグレードcurrentVersion 値が targetVersion より小さい`status` 値が UPDATING |
クラスタが Distributed Cloud Connected ソフトウェアのターゲット バージョンにアップグレードされています。 | 現在のクラスタ バージョンとターゲット クラスタ バージョンの値が一致するまで、Metrics Explorer でクラスタをモニタリングします。 |
StuckcurrentVersion 値が targetVersion より低い状態が続く`status` 値が UPDATING の状態が続く |
クラスタ内の少なくとも 1 つのノードで、Distributed Cloud Connected ソフトウェアのターゲット バージョンへのアップグレードが失敗しました。 | マシンの接続とシステムログを確認し、Google にお問い合わせください。 |
ロールバックcurrentVersion 値が targetVersion より大きい`status` 値が UPDATING |
luster は、以前のバージョンの Distributed Cloud コネクテッド ソフトウェアにロールバックしています。 | ロールバックの理由を特定するには、Google にお問い合わせください。 |
クラスタのソフトウェア アップグレードが失敗した場合、またはクラスタが以前のソフトウェア バージョンにロールバックされた場合は、次のことを確認します。
- ノードの健全性。次のセクションで説明するように、各物理 Distributed Cloud 接続マシンにネットワーク接続があり、稼働時間が報告されていることを確認します。
- メンテナンスの時間枠。メンテナンスの除外期間が原因でソフトウェア アップグレードが一時停止されているかどうかを確認します。
- システムログ。システムログを調べて、Pod の強制排除のタイムアウトなど、ソフトウェア アップグレードの失敗の原因を特定します。
表に記載されている解決手順で問題が解決しない場合は、影響を受けるマシンの machine_id 値と停止のタイムスタンプを添えて Google サポートにお問い合わせください。
Distributed Cloud コネクテッド マシンの再起動
このセクションでは、Metrics Explorer を使用して、Distributed Cloud に接続された物理マシンが再起動したかどうかを確認し、再起動の原因を特定する方法について説明します。モニタリングの再起動は、計画的なメンテナンスの一環として行われたのか、ハードウェア障害や停電の結果として行われたのかを判断するのに役立ちます。
この手順では、次の Monitoring 指標を使用します。
マシンの稼働時間（
/machine/uptime）: 前回の再起動からの経過時間（秒単位）を示します。マシンの再起動（
/machine/restart_count）: ターゲット マシンのデプロイ以降の再起動の合計数を示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- Google Cloud コンソールと Distributed Cloud 接続 Google Cloud プロジェクトへのアクセス権。
- Monitoring 指標を表示できる Monitoring 閲覧者 IAM ロール。
- （省略可）返される結果をフィルタリングするための、ターゲットの Distributed Cloud コネクテッド マシンの
machine_id値。
Metrics Explorer を使用してマシンの稼働時間と再起動回数を確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[構成] ページに移動します。
[指標を選択] をクリックします。
検索バーを使用して、マシン リソースタイプを検索します。完全なリソース識別子
edgecontainer.googleapis.com/Machineを使用することもできます。返された結果で、[マシン] リソースタイプをクリックします。
マシンの稼働時間を確認します。
[指標] セクションで、
uptime値を検索します。[マシンの稼働時間] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/machine/uptimeです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。表示された時間グラフで、稼働時間グラフが継続的に上昇していることを確認します。稼働時間がゼロに減少し、再起動した場合は、マシンが再起動したことを示します。
マシンの再起動回数を確認します。
[指標] セクションで、
restart_count値を検索します。[マシンの再起動] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/machine/restart_countです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。表示された時間グラフで、グラフの線が
0のままであることを確認します。これは、再起動が発生していないことを示しています。この線が1に急上昇した場合は、マシンが再起動したことを示します。再起動の正確なタイムスタンプをメモして、トラブルシューティングに役立ててください。（省略可）グラフではなく個々のイベントを表示するには、ページの [集計] セクションに移動し、[調整期間] フィールドを
1 minuteに、[系列ごとのアライナー] フィールドを [差分] に設定します。
結果を把握する
次の表に、Metrics Explorer から返される結果を示します。
| マシンの状態 | 診断 | 解決策 |
|---|---|---|
| 安定 「マシンの稼働時間」の指標が着実に増加している 「マシンの再起動」の指標の差分が 0 である |
マシンが再起動されていません。 | なし |
| クリーン再起動 「マシンの稼働時間」指標が 0 に低下「マシンの再起動」指標が 1 に急増 |
マシンが正常に再起動し、 Google Cloudに再接続されました。 | システムログを確認して、再起動の理由を特定します。 |
| 停電 「マシンの稼働時間」指標のグラフにデータがない中断がある 「マシンの再起動」指標は、マシンの稼働時間の中断中に変化していない |
再起動する前に、マシンの電源またはネットワーク接続が切断された。 | 電源ケーブルとネットワーク ケーブル、ローカル ネットワーク構成、LED インジケーターのステータスを確認します。 |
| 断続的 「マシン接続」指標の値が 0 と 1 の間で交互に変化する「ネットワーク接続」指標の値が 0 と 1 の間で交互に変化する |
ネットワーク接続が不安定である、パケットロスが発生している、レイテンシが過剰である。 | ローカル ネットワークで輻輳やハードウェアの障害が発生していないか確認します。 |
表に記載されている解決手順で問題が解決しない場合は、影響を受けるマシンの machine_id 値と停止のタイムスタンプを添えて Google サポートにお問い合わせください。
Distributed Cloud コネクテッド マシンの接続
このセクションでは、Cloud Monitoring の Metrics Explorer 機能を使用して、Distributed Cloud に接続されたマシンのインターネットと Google Cloud の接続を確認する方法について説明します。
この手順では、次の Monitoring 指標を使用します。
Machine Connected（
/machine/connected）: マシンが Google Cloudに接続されているかどうかを示します。ネットワーク接続（
/machine/network/connectivity）: マシンのプライマリ ネットワーク インターフェースにインターネット接続があるかどうかを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- Google Cloud コンソールと Distributed Cloud 接続 Google Cloud プロジェクトへのアクセス権。
- Monitoring 指標を表示できる Monitoring 閲覧者 IAM ロール。
- （省略可）返される結果をフィルタリングするための、ターゲットの Distributed Cloud コネクテッド マシンの
machine_id値。
Metrics Explorer を使用してマシンの接続を確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[クエリ] ページに移動します。
検索バーを使用して、マシン リソースタイプを検索します。完全なリソース識別子
edgecontainer.googleapis.com/Machineを使用することもできます。返された結果で、[マシン] リソースタイプをクリックします。
マシンと Google Cloudの接続を確認します。
[指標] セクションで、
connected値を検索します。[Machine Connected] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/machine/connectedです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。表示された時間グラフで、[正常] の線が 100% のままになっていることを確認します。この値が 0% または [Unhealthy] になった場合、マシンは示された時点で Google Cloud との接続を失っています。
マシンのインターネット接続を確認します。
[指標] セクションで、
connectivity値を検索します。[ネットワーク接続] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/machine/network/connectivityです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。表示された時間グラフで、[正常] の線が 100% のままになっていることを確認します。この値が 0% Unhealthy になった場合、マシンは示された時間にインターネット接続を失っています。
結果を把握する
次の表に、Metrics Explorer から返される結果を示します。
| マシンの状態 | 診断 | 解決策 |
|---|---|---|
| 正常 「マシン接続」指標の値は 1「ネットワーク接続」指標の値は 1 |
通常のオペレーション。 | なし |
| 切断 「マシン接続」指標の値は 0「ネットワーク接続」指標の値は 1 |
マシンはインターネットに接続されているが、 Google Cloudに接続できない。 | Google サービスと API エンドポイントのファイアウォール ルールを確認します。Distributed Cloud 接続エージェントがマシンで実行されていることを確認します。 |
| 分離 「マシン接続」指標の値は 0「ネットワーク接続」指標の値は 0 |
マシンがインターネットに接続されていない。 | 電源ケーブルとネットワーク ケーブル、ローカル ネットワーク構成、LED インジケーターのステータスを確認します。VLAN とルーティングの構成を確認します。 |
| 断続的 「マシン接続」指標の値が 0 と 1 の間で交互に変化する「ネットワーク接続」指標の値が 0 と 1 の間で交互に変化する |
ネットワーク接続が不安定である、パケットロスが発生している、レイテンシが過剰である。 | ローカル ネットワークで輻輳やハードウェアの障害が発生していないか確認します。 |
いずれかの指標で 0 の値が継続的に確認された場合は、表に記載されているトラブルシューティングの手順に沿って問題を解決してください。問題が解決しない場合は、影響を受けるマシンの machine_id 値と停止のタイムスタンプを添えて、Google サポートにお問い合わせください。
仮想マシンが Pending 状態のままになる
次のいずれかの状況が発生すると、仮想マシン ワークロードが Pending 状態で停止し、ノードでスケジュール設定に失敗する可能性があります。
- Distributed Cloud Connected は、リクエストされたリソース（CPU 時間、メモリ、ディスク容量など）を仮想マシンに割り当てることができません。
- 仮想マシンの構成に障害があります。
- 仮想マシンのストレージに障害が発生しています。
- ターゲット ノードが汚染されています。
この問題を解決するには、次の操作を行います。
クラスタの認証情報を取得するの説明に沿って、クラスタの認証情報を取得します。
影響を受ける仮想マシンに関する情報を取得します。
kubectl describe virtualmachine VM_NAME -n NAMESPACE
次のように置き換えます。
VM_NAME: ターゲット仮想マシンの名前。NAMESPACE: ターゲット仮想マシンの Namespace。
このコマンドでは、次のような出力が返されます。
Status: ... State: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 15m virtualmachine-controller Created virtual machine my-stuck-vm Warning DiskProvisioningFailed 14m virtualmachine-controller Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready Warning PVCNotBound 14m virtualmachine-controller PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending Warning VMINotCreated 10m virtualmachine-controller VirtualMachineInstance cannot be created: dependencies not readyコマンドの出力には、リソースの制約、スケジューリングの失敗、ストレージ障害などの問題を示すメッセージが含まれています。
出力で、次のセクションで説明するように、スケジューリングの失敗の原因を特定します。
リソースの不足
CPU、メモリ、ディスク容量などのリソースが不足していることを示すメッセージが表示されることがあります。次に例を示します。
5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.
この問題を解決するには、影響を受ける仮想マシンとノードでスケジュールされている他のワークロードに割り当てられているリソースを確認し、ビジネスニーズに応じて次の操作を行います。
- ノードでスケジュールされている他のワークロードをスケールダウンする。
- 影響を受ける仮想マシンに割り当てられているリソースの量を減らします。
- 影響を受けるクラスタにマシンを追加します。
taint を追加したノード
ターゲット ノードが汚染されていることを示すメッセージが表示されることがあります。次に例を示します。
5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.
この問題を解決するには、次の操作を行います。
次のコマンドを使用して、ノードの taint を確認します。
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
このコマンドでは、次のような出力が返されます。
NAME TAINTS node-name-1 [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]] node-name-2 <none>次のいずれかを行います。
- 予期しない taint がある場合は、taint と toleration の説明に従って削除します。
- 想定される taint については、taint と toleration で説明されているように、対応する toleration を仮想マシンの構成に追加します。
ストレージの障害
仮想マシンのストレージに障害があることを示すメッセージが表示されることがあります。次に例を示します。
5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.
このメッセージは、対応する永続ボリュームがターゲット ノードにマウントされていないことを示している可能性があります。
この問題を解決するには、次の操作を行います。
次のコマンドを使用して、影響を受ける仮想マシンの Namespace 内の永続ボリューム クレーム（PVC）のステータスを取得します。
kubectl get pvc -n NAMESPACE
NAMESPACEは、ターゲット Namespace の名前に置き換えます。このコマンドでは、次のような出力が返されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE windows-robin-disk-0 Bound pvc-b1a1d264-84bf-4e58-857d-f37f629d5082 25Gi RWX robin-block-immediate 30h windows-robin-disk-1 Bound pvc-0130b9a8-7fed-4df0-8226-d79273792a16 25Gi RWX robin-block-immediate 30h windows-robin-vm-0-restored-windows-robin-disk-0 Pending gce-pd-gkebackup-in 26m対応する PVC のステータスが
Boundであることを確認します。ステータスがPendingの場合、ストレージ サブシステムはボリュームのプロビジョニングに失敗しています。このような場合は、ストレージ サブシステムの構成をトラブルシューティングし、適切なStorageClassが利用可能であることを確認する必要があります。