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 コネクテッド のターゲット バージョンを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- コンソールと Distributed Cloud コネクテッド プロジェクトにアクセスできること。 Google 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値を検索します。[ターゲット クラスタ バージョン] 指標を選択します。完全パスは
edgecontainer.googleapis.com/edge_cluster/target_cluster_versionです。（省略可）[フィルタ] セクションを使用して、ターゲット
machine_id値でフィルタします。
表示されたグラフで、クラスタのソフトウェア アップグレードのステータスを確認します。
[現在のクラスタ バージョン] 行と [ターゲット クラスタ バージョン] 行に異なる値が表示されている場合、クラスタはソフトウェア アップグレード中です。
[現在のクラスタ バージョン] 行と [ターゲット クラスタ バージョン] 行に同じ値が表示されている場合、クラスタはソフトウェア アップグレード中ではありません。
次のコマンドを使用して、前の手順の結果を確認します。
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 コネクテッド ソフトウェアのターゲット バージョンを実行しています。 | なし |
| アップグレード中 値が より小さい targetVersion`status` 値が UPDATINGcurrentVersion |
クラスタは、Distributed Cloud コネクテッド ソフトウェアのターゲット バージョンにアップグレードしています。 | 現在のクラスタ バージョンとターゲット クラスタ バージョンの値が一致するまで、Metrics Explorer でクラスタをモニタリングします。 |
停止currentVersion 値が targetVersion より小さい状態が続く`status` 値が UPDATING の状態が続く |
クラスタ内の少なくとも 1 つのノードで、Distributed Cloud コネクテッド ソフトウェアのターゲット バージョンへのアップグレードが失敗しました 。 | マシンの接続とシステムログを確認し、Google にお問い合わせください。 |
ロールバック中currentVersion 値が targetVersion`status` 値が UPDATING |
クラスタは、Distributed Cloud コネクテッド ソフトウェアの以前のバージョンにロールバックしています。 | Google にお問い合わせのうえ、ロールバックの理由を特定してください。 |
クラスタでのソフトウェア アップグレードが失敗した場合、またはクラスタが以前のソフトウェア バージョンにロールバックした場合は、次の点を確認してください。
- ノードのヘルス 。次のセクションで説明するように、各物理 Distributed Cloud コネクテッド マシンにネットワーク接続があり、稼働時間が報告されていることを確認します。
- メンテナンスの時間枠 。メンテナンス除外の時間枠が原因でソフトウェア アップグレードが一時停止されているかどうかを確認します。
- システムログ 。システムログを調べて、Pod の強制排除のタイムアウトなど、ソフトウェア アップグレードの失敗の原因を特定します。
表に記載されている解決策で問題が解決しない場合は、影響を受けるマシンの machine_id 値と停止のタイムスタンプを添えて
Google サポート
にお問い合わせください。
Distributed Cloud コネクテッド マシンの再起動
このセクションでは、Metrics Explorer を使用して、Distributed Cloud コネクテッド 物理マシンが再起動したかどうかを確認し、再起動の理由を特定する方法について説明します。再起動をモニタリングすることで、計画的なメンテナンスの一環として再起動されたのか、ハードウェアの障害や電源の停止が原因で再起動されたのかを判断できます。
この手順では、次の Monitoring 指標を使用します。
マシン稼働時間 （
/machine/uptime）: 前回の再起動からの経過時間（秒単位）を示します。マシンの再起動 （
/machine/restart_count）: デプロイ以降のターゲット マシンの再起動の合計回数を示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- コンソールと Distributed Cloud コネクテッド プロジェクトにアクセスできること。 Google 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): マシンが に接続されているかどうかを示します Google Cloud。ネットワーク接続 （
/machine/network/connectivity）: マシンのプライマリ ネットワーク インターフェースがインターネットに接続されているかどうかを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- コンソールと Distributed Cloud コネクテッド プロジェクトにアクセスできること。 Google 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値を検索します。[マシン接続] 指標を選択します。完全パスは
edgecontainer.googleapis.com/machine/connectedです。（省略可）[フィルタ] セクションを使用して、ターゲット
machine_id値でフィルタします。表示された時間グラフで、[正常] 行が 100% のままになっていることを確認します。この値が 0% または [異常] になった場合、マシンは 示された時間に との接続を失っています Google Cloud 。
マシンのインターネット接続を確認します。
[指標] セクションで、
connectivity値を検索します。[ネットワーク接続] 指標を選択します。完全パスは
edgecontainer.googleapis.com/machine/network/connectivityです。（省略可）[フィルタ] セクションを使用して、ターゲット
machine_id値でフィルタします。表示された時間グラフで、[正常] 行が 100% のままになっていることを確認します。この値が 0% または [異常] になった場合、マシンは 示された時間にインターネット接続を失っています。
結果を把握する
次の表に、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 コネクテッド が、CPU 時間、メモリ、ディスク容量などのリクエストされたリソースを仮想マシンに割り当てることができない。
- 仮想マシンの構成に障害がある。
- 仮想マシンのストレージに障害がある。
- ターゲット ノードが Taint されている。
この問題を解決するには、次の操作を行います。
クラスタの認証情報を取得するの説明に従って、クラスタの認証情報を取得します。
影響を受ける仮想マシンに関する情報を取得します。
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 されたノード
ターゲット ノードが 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が使用可能であることを確認する必要があります。