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 Connected のターゲット バージョンを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- 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値でフィルタします。
表示されたグラフで、クラスタのソフトウェア アップグレードのステータスを確認します。
[現在のクラスタ バージョン] 行と [ターゲット クラスタ バージョン] 行にそれぞれ異なる値が表示されている場合、クラスタはソフトウェア アップグレード中です。
[現在のクラスタ バージョン] 行と [ターゲット クラスタ バージョン] 行に同じ値が表示されている場合、クラスタはソフトウェア アップグレードを行っていません。
次のコマンドを使用して、前の手順の結果を確認します。
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 コネクテッド ソフトウェアのターゲット バージョンにアップグレードされています。 | 現在のクラスタ バージョンとターゲット クラスタ バージョンの値が一致するまで、Metrics Explorer でクラスタをモニタリングします。 |
StuckcurrentVersion 値が targetVersion より低い状態が継続している`status` 値が UPDATING の状態が継続している |
クラスタ内の少なくとも 1 つのノードで、Distributed Cloud コネクテッド ソフトウェアのターゲット バージョンへのアップグレードが失敗しました。 | マシンの接続とシステムログを確認し、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が利用可能であることを確認する必要があります。
アドミッション Webhook の失敗によるスケジューリングのロックアップ
アドミッション Webhook を使用すると、オブジェクトが永続化される前に Kubernetes API サーバーへのリクエストをインターセプトできます。カスタム セキュリティ ポリシーの適用に役立ちますが、Webhook の構成が誤っていると、特にソフトウェア アップグレードや証明書の更新などの重要なオペレーション中に、クラスタ全体の停止が発生する可能性があります。具体的には、ブロックされた、または使用できないアドミッション Webhook により Kubernetes コントロール プレーンが停止し、クラスタでのワークロードのスケジュール設定がそれ以上できなくなる可能性があります。
コントロール プレーンのデッドロック
アドミッション Webhook が、Webhook 自体の復元に必要なリソースの検証を担当している場合、循環依存関係のデッドロックが発生する可能性があります。たとえば、Pod を検証するようにアドミッション Webhook が構成されていて、ノード ソフトウェアのアップグレード中にその Webhook Pod の再スケジュールが必要な場合、Kubernetes API サーバーは Webhook に接続して、新しい Pod の作成を承認しようとします。Webhook にアクセスできない場合、リクエストは失敗し、Pod は作成されません。クラスタはデッドロック状態になり、新しいワークロードをスケジュールできなくなります。
Webhook が failurePolicy: Fail で構成されている場合、API サーバーと Webhook 間の通信エラーまたはタイムアウトが発生すると、API リクエストが拒否されます。これにより、次の問題が発生します。
- ソフトウェア アップグレードが失敗する: ノード ソフトウェアのアップグレード中およびアップグレード後に、システム コンポーネントと VM をスケジュールできません。
- システム サービスを起動できない: Symcloud Storage や GDC 上の VM ランタイムなどのインフラストラクチャ Pod を起動できない。
- ノードがメンテナンス モードで停止している: コントローラがアドミッション ロジックによってブロックされているため、メンテナンス モードのノードを調整または終了できません。
Webhook 構成のベスト プラクティス
このセクションで説明するベスト プラクティスに従って、前述のコントロール プレーンのデッドロックを防ぎます。これらのベスト プラクティスは、すべての ValidatingWebhookConfiguration オブジェクトと MutatingWebhookConfiguration オブジェクトに適用されます。
failurePolicy: Ignore を使用する
ビジネス要件で、API リクエストを検証できない場合は失敗させることが必須とされている場合を除き、failurePolicy フィールドは常に Ignore に設定します。これにより、影響を受ける Webhook サービスがダウンした場合でも Kubernetes API サーバーが機能し続け、システム クリティカルな Pod のスケジュール設定と復元が可能になります。
予約済みの Namespace を除外する
Webhook は、予約済み Namespace のリソースに対するリクエストをインターセプトしてはなりません。namespaceSelector フィールドを使用して、Webhook 構成からこれらの名前空間を除外する必要があります。予約済み名前空間の一覧については、管理名前空間の制限事項をご覧ください。次に例を示します。
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
failurePolicy: Ignore
sideEffects: None
admissionReviewVersions: ["v1"]
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
- kube-node-lease
- kube-public
- capi-system
- capi-kubeadm-bootstrap-system
- gke-system
- gke-connect
- gke-operators
- gke-managed-metrics-server
- anthos-identity-service
- anthos-creds
- robinio
- robin-admin
- vm-system
- cert-manager
- cert-manager-cluster-resources
- dns-system
- g-istio-system
- nf-operator
- prom-monitoring
- gpu-system
- oclcm-system
- saas-system
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: ["*"]
apiVersions: ["*"]
resources: ["pods", "deployments"]
失敗した Webhook によってデッドロックされたクラスタを復元する
失敗した Webhook によってクラスタがデッドロックされ、リソースを作成するための kubectl コマンドがタイムアウトするか、エラーを返す場合、通常は Webhook の failurePolicy が Fail に設定されていることが原因です。このセクションの手順に沿って、クラスタをデッドロックから復元します。失敗した Webhook がミューテーション Webhook の場合は、validatingwebhookconfiguration ではなく mutatingwebhookconfiguration を使用します。
失敗した Webhook を特定します。
クラスタにデプロイされた検証 Webhook を一覧表示します。
kubectl get validatingwebhookconfigurations
クラスタにデプロイされた変更用 Webhook を一覧表示します。
kubectl get mutatingwebhookconfigurations
これらの Webhook をサポートする Pod が実行されているかどうかを確認します。
kubectl get pods -A | grep WEBHOOK_SERVICE
WEBHOOK_SERVICEは、ターゲット Webhook のサービスの名前に置き換えます。失敗した webhook の
failurePolicyをIgnoreに設定します。kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \ --type='json' \ -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'WEBHOOK_SERVICEは、ターゲット Webhook のサービスの名前に置き換えます。（省略可）前の手順が失敗した場合は、影響を受ける Webhook の構成を強制的に削除します。
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
WEBHOOK_CONFIGは、ターゲット Webhook の構成の名前に置き換えます。
Webhook の構成を変更または強制削除すると、Kubernetes API サーバーはリクエストの処理を再開し、デッドロックを解消して、ブロックされたプロセスを完了させます。