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 プロジェクトへのアクセス。
- モニタリング閲覧者 IAM ロール。Monitoring 指標を表示できます。
- （省略可）返された結果をフィルタリングするための、ターゲット Distributed Cloud 接続マシンの
machine_id値。
Metrics Explorer を使用して、クラスタの現在のソフトウェア バージョンとターゲット ソフトウェア バージョンを確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[構成] ページに移動します。
[指標を選択] をクリックします。
検索バーを使用して、クラスタ リソースタイプを検索します。完全なリソース ID
edgecontainer.googleapis.com/Clusterを使用することもできます。返された結果で、[クラスタ] リソースタイプをクリックします。
クラスタの現在のソフトウェア バージョンを取得します。
[指標] セクションで、
current_cluster_version値を検索します。[Machine Uptime] 指標を選択します。完全なパスは
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] の行に同じ値が表示されている場合、クラスタはソフトウェア アップグレード中ではありません。
次のコマンドを使用して、前の手順の結果を確認します。
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 でクラスタをモニタリングします。 |
スタック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）: デプロイ以降のターゲット マシンの再起動の合計数を示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- Google Cloud コンソールと、Distributed Cloud に接続された Google Cloud プロジェクトへのアクセス。
- モニタリング閲覧者 IAM ロール。Monitoring 指標を表示できます。
- （省略可）返された結果をフィルタリングするための、ターゲット Distributed Cloud 接続マシンの
machine_id値。
Metrics Explorer を使用してマシンの稼働時間と再起動回数を確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[構成] ページに移動します。
[指標を選択] をクリックします。
検索バーを使用して、マシンリソースタイプを検索します。完全なリソース ID
edgecontainer.googleapis.com/Machineを使用することもできます。返された結果で、[マシン] リソースタイプをクリックします。
マシンの稼働時間を確認します。
[指標] セクションで、
uptime値を検索します。[Machine Uptime] 指標を選択します。完全なパスは
edgecontainer.googleapis.com/machine/uptimeです。（省略可）[フィルタ] セクションを使用して、ターゲットの
machine_id値でフィルタします。表示されたタイムチャートで、稼働時間グラフが継続的に上昇していることを確認します。稼働時間の値がゼロに低下して再起動した場合は、マシンが再起動したことを示します。
マシンの再起動回数を確認します。
[指標] セクションで、
restart_count値を検索します。[Machine Restarts] 指標を選択します。完全なパスは
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）: マシンのプライマリ ネットワーク インターフェースにインターネット接続があるかどうかを示します。
このセクションの手順を完了するには、次の前提条件を満たす必要があります。
- Google Cloud コンソールと、Distributed Cloud に接続された Google Cloud プロジェクトへのアクセス。
- モニタリング閲覧者 IAM ロール。Monitoring 指標を表示できます。
- （省略可）返された結果をフィルタリングするための、ターゲット Distributed Cloud 接続マシンの
machine_id値。
Metrics Explorer を使用してマシンの接続性を確認する
Metrics Explorer に移動します。
Google Cloud コンソールで、[モニタリング] セクションに移動します。
左側のナビゲーション ツリーで、[Metrics Explorer] をクリックします。
ターゲット リソースタイプを選択します。
[Metrics Explorer] ページで、[クエリ] ページに移動します。
検索バーを使用して、マシンリソースタイプを検索します。完全なリソース ID
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%（異常）の場合、マシンは指定された時刻にインターネット接続を失っています。
結果を把握する
次の表に、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 時間、メモリ、ディスク容量など）を仮想マシンに割り当てることができません。
- 仮想マシンの構成に障害があります。
- 仮想マシンのストレージに障害がある。
- ターゲット ノードが 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 内の PersistentVolumeClaim（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 のスケジュール設定と復元が可能になります。
予約済みの名前空間を除外する
Webhook は、予約済み Namespace 内のリソースに対するリクエストをインターセプトしてはなりません。namespaceSelector フィールドを使用して、これらの Namespace を Webhook 構成から除外する必要があります。予約済みの Namespace の一覧については、管理 Namespace の制限をご覧ください。次に例を示します。
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 サーバーはリクエストの処理を再開し、デッドロックを解決して、ブロックされたプロセスを完了させます。