このドキュメントでは、Backup for GKE を使用して復元オペレーションを実行するときに発生する可能性のあるエラーとその対応するコードについて説明します。各セクションには、復元エラーを解決するためのアクションを実行する際に考慮すべき事項と、復元オペレーション エラーを解決する方法の手順が含まれています。
エラー 200010301: アドミッション Webhook サービスを利用できないため、復元オペレーションを完了できませんでした
エラー 200010301 は、アドミッション Webhook サービス（HTTP コールバックとも呼ばれます）が使用できないために復元オペレーションの完了が失敗した場合に発生します。この場合、次のエラー メッセージが表示されます。このエラー メッセージは、リソースの復元中に GKE API サーバーがアドミッション Webhook に接続しようとしたものの、Webhook をサポートするサービスが使用できないか見つからなかったことを示しています。
resource [/example-group/ClusterSecretStore/example-store] restore failed:
Internal error occurred: failed calling webhook "example-webhook.io":
failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.
このエラーは、ターゲット クラスタで ValidatingAdmissionWebhook または MutatingAdmissionWebhook GKE リソースがアクティブになっているにもかかわらず、GKE API サーバーが Webhook で構成されたエンドポイントに到達できない場合に発生します。アドミッション Webhook は GKE API サーバーへのリクエストをインターセプトし、その構成で GKE API サーバーがリクエストをクエリする方法を指定します。
Webhook の clientConfig は、アドミッション リクエストを処理するバックエンドを指定します。これは、内部クラスタ サービスまたは外部 URL になります。これらの 2 つのオプションのどちらを選択するかは、Webhook の特定の運用要件とアーキテクチャ要件によって異なります。オプションのタイプによっては、次の理由で復元オペレーションが失敗する可能性があります。
クラスタ内サービス: GKE API サーバーが Webhook の呼び出しを試みたときに、GKE サービスとそのバッキング Pod が復元されていないか、準備されていません。これは、名前空間が指定されたサービスが完全に
ready状態になる前に、クラスタ スコープの Webhook 構成が適用される復元オペレーション中に発生します。外部 URL: GKE クラスタと外部エンドポイントの間のネットワーク接続の問題、DNS 解決の問題、ファイアウォール ルールにより、外部エンドポイントが一時的に使用できません。
このエラーを解決するには、次の手順で対応します。
エラー メッセージに記載されている失敗した Webhook を特定します。例:
failed calling webhook "..."kubectl get validatingwebhookconfigurationsコマンドを実行して、Webhook を検査します。kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yamlWEBHOOK_NAMEは、エラー メッセージで特定された Webhook の名前に置き換えます。kubectl get mutatingwebhookconfigurationsコマンドを実行して、Webhook を検査することもできます。kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yamlWEBHOOK_NAMEは、エラー メッセージで特定された Webhook の名前に置き換えます。構成タイプに応じて、次のトラブルシューティングの手順を行います。
サービスベース
clientConfigRestorePlanリソースを変更して、GroupKindDependencyエントリを含むRestoreOrderを含めることで、カスタム復元順序を定義します。これにより、ValidatingWebhookConfigurationまたはMutatingWebhookConfigurationの前に、Deployment、StatefulSet、Serviceなどの Webhook をサポートするコンポーネントを復元して準備できます。カスタム復元順序を定義する手順については、復元中にリソースの復元順序を指定するをご覧ください。
このアプローチは、
Serviceオブジェクトが作成された後でも、サービスの Pod が完全にready状態にならないため、失敗する可能性があります。失敗のもう 1 つの理由として、別のアプリケーションによって Webhook 構成が予期せず作成された可能性があります。または、次の手順で 2 段階の復元オペレーションを実行することもできます。バックアップを使用して
Restoreリソースを作成します。これを行うには、Webhook が機能するために必要な特定のリソース（Namespaces、Deployments、StatefulSets、Servicesなど）を含むきめ細かい復元フィルタを使用して、復元オペレーションを構成します。きめ細かい復元フィルタを使用して復元を構成する方法については、きめ細かい復元を有効にするをご覧ください。
バックアップ オペレーション用の別の
Restoreリソースを作成し、選択した残りのリソースを構成します。
URL ベース
clientConfig外部 HTTPS エンドポイントを確認し、アクティブで、到達可能で、正しく機能していることを確認します。
GKE クラスタのノードとコントロール プレーンから外部 URL へのネットワーク接続があることを確認します。また、Virtual Private Cloud、オンプレミス、または Webhook、ネットワーク ポリシー、DNS 解決をホストするクラウド プロバイダを使用している場合は、ファイアウォール ルールを確認する必要がある場合があります。
復元オペレーションを再試行します。オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。
エラー 200010302: リソース作成リクエストが拒否されたため、復元オペレーションを完了できませんでした
エラー 200010302 は、アドミッション Webhook がリソース作成リクエストを拒否したために復元オペレーションの完了が失敗した場合に発生します。これにより、アクティブなアドミッション Webhook がリクエストをインターセプトし、カスタム ポリシーに基づいてリクエストを拒否したため、バックアップのリソースをターゲット クラスタに作成できなかったことを示す次のエラー メッセージが表示されます。
[KubeError]; e.g. resource
[/example-namespace/example-api/ExampleResource/example-name]
restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}
このエラーは、ターゲット GKE クラスタで設定された構成が原因で発生します。この構成には、リソースの作成と変更に特定のルールを適用し、リソース作成リクエストをブロックする ValidatingAdmissionWebhook または MutatingAdmissionWebhook が含まれています。たとえば、関連しているものの、競合しているリソースがクラスタにすでに存在するため、Webhook はリソースの作成を防止します。たとえば、Webhook は、HorizontalPodAutoscaler GKE API リソースによってすでに管理されている場合、デプロイの作成を拒否する可能性があります。
このエラーを解決するには、次の手順で対応します。
復元オペレーションが失敗したときに発生するエラー メッセージを使用して、リクエストを拒否している Webhook を特定します。たとえば、
webhook WEBHOOK_NAME denied the requestエラー メッセージには次の情報が含まれます。Webhook 名: リクエストを拒否した Webhook の名前。
拒否の理由: リクエストを拒否した具体的な理由。
kubectl get validatingwebhookconfigurationsコマンドを実行して、Webhook を検査します。kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yamlWEBHOOK_NAMEは、エラー メッセージで特定した Webhook の名前に置き換えます。kubectl get mutatingwebhookconfigurationsコマンドを実行して、Webhook を検査することもできます。kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yamlWEBHOOK_NAMEは、エラー メッセージから特定した Webhook の名前に置き換えます。ターゲット クラスタの根本的な問題を解決します。是正措置は、特定のエラーによって異なります。たとえば、
HorizontalPodAutoscalerの競合がある場合は、バックアップされたワークロードと関連リソースを作成できるように、復元を実行する前にターゲット クラスタ内の既存のHorizontalPodAutoscalerを削除する必要があります。復元オペレーションを再試行します。復元オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。
エラー 200060202: ワークロードの検証中に GKE リソースが見つからなかったため、復元オペレーションを完了できませんでした
エラー 200060202 は、復元オペレーションのワークロード検証フェーズで、Backup for GKE が検証を想定している GKE リソースがターゲット クラスタで見つからない場合に発生します。これにより、次のエラー メッセージが表示されます。
Workload Validation Error: [KIND] "[NAME]" not found
例: Example: Workload Validation Error: pods "jenkins-0" not found
このエラーは、Backup for GKE が復元オペレーションのプロセスの一環として GKE リソースを正常に作成または更新したものの、検証ステージの開始時に、GKE リソースのワークロード検証が完了する前に、リソースが復元プロセスによって最初に作成または更新された後に削除されたため、1 つ以上の GKE リソースがターゲット クラスタに存在しなくなった場合に発生します。このようなエラーは、次の理由で発生する可能性があります。
手動削除: ユーザーまたは管理者が
kubectlまたはその他の Google Cloud ツールを使用してリソースを手動で削除しました。外部自動化: Config Sync、ArgoCD、Flux などの GitOps コントローラ、カスタム スクリプト、その他のクラスタ管理ツールが、リポジトリ内の望ましい状態に合わせてリソースを元に戻すか、削除しました。
GKE コントローラ: リソースが他のリソースやポリシーと競合しているか、
OwnerReferenceチェーンによってガベージ コレクションが発生したか、ownerリソースが削除されたときに依存リソースを削除する GKE による自動クリーンアップ プロセスのために、そのリソースが GKE コントローラによって削除されました。
このエラーを解決するには、次の手順で対応します。
復元オペレーションが完了しなかったときに表示されるエラー メッセージを使用して、不足しているリソースを特定します。
次のいずれかの方法で、リソースが属している名前空間を特定します。
GKE 監査ログ: 復元オペレーションを試行したときに生成された GKE 監査ログを確認します。リソース
KindとNameに対する削除オペレーションのログをフィルタできます。監査ログエントリに、元の名前空間が含まれています。バックアップの詳細: 復元オペレーションのスコープとバックアップの内容を確認します。バックアップ インデックスには、リソースの元の名前空間が表示されます。また、
RestorePlanに、選択した名前空間内のリソースを復元するルールを指定するTransformationRuleが含まれているかどうかを確認することもできます。名前空間をまたいで検索する:
kubectl getコマンドを実行して、すべての名前空間でリソースを検索します。kubectl get KIND --all-namespaces | grep NAMEKINDとNAMEは、エラー メッセージの値に置き換えます。リソースがまだ存在する場合は、このコマンドでその名前空間が表示されます。
kubectl getコマンドを実行して、削除を確認します。kubectl get KIND NAME -n [NAMESPACE]KINDとNAMEは、エラー メッセージの値に置き換えます。not foundエラー メッセージが表示されます。次のいずれかの方法で、削除の原因を調査します。
GKE 監査ログ: 削除リクエストを発行したエンティティを特定します。たとえば、ユーザー、サービス アカウント、コントローラなどです。
構成された自動化を確認する: GitOps などの自動化ツールを使用している場合は、復元されたリソースに干渉していないかどうかをログとステータスで確認します。
関連するイベントを確認する:
kubectl get eventsコマンドを実行して、特定された名前空間の GKE イベントを確認します。kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'NAMESPACE_NAMEは Namespace の名前に置き換えます。
前の手順の結果に基づいて、リソース削除の原因に対処します。たとえば、競合する自動化の一時停止、誤った構成の修正、ユーザー権限の調整を行います。
次のいずれかの方法で、不足しているリソースを復元します。
マニフェスト ファイルを再適用する: 不足しているリソースのマニフェストがある場合は、正しい名前空間に再適用できます。
きめ細かい復元を実行する: きめ細かい復元オペレーションを実行して、同じバックアップから不足しているリソースのみを選択的に復元します。これにより、正しい名前空間を指定できます。きめ細かい復元オペレーションの実行方法については、きめ細かい復元を有効にするをご覧ください。
復元オペレーションを再試行します。復元オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。
エラー 200060201: ワークロードの検証がタイムアウトしたため、復元オペレーションを完了できませんでした
エラー 200060201 は、クラスタにリソースが作成された後、復元オペレーションの想定される制限時間内に、復元された 1 つ以上のワークロードが完全に ready にならない場合に発生します。これにより、次のエラー メッセージが表示されます。
Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]
このエラーは、Backup for GKE が GKE リソース構成の復元後に検証ステップを実行し、重要なワークロードが正しく機能していることを確認するために発生します。Backup for GKE は、特定のワークロードが ready 状態になるのを待機しますが、割り当てられたタイムアウト期間内に次の準備完了条件を満たしていないワークロードが少なくとも 1 つあります。
Podsの場合:status.PhaseはRunningDeploymentsの場合:status.ReadyReplicasはspec.Replicasと等しいStatefulSetsの場合:status.ReadyReplicasはspec.Replicasと等しいDaemonSetsの場合:status.NumberReadyはstatus.DesiredNumberScheduledと等しい
このエラーを解決するには、次の手順で対応します。
ワークロードとその名前空間が
ready状態にならなかったことを示すエラー メッセージで、ready状態になっていないワークロードを特定します。kubectl describeコマンドを実行して、ワークロードのステータスを調べ、失敗したワークロードの詳細とイベントを取得します。kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD次のように置き換えます。
WORKLOAD_TYPE: ワークロードのタイプ（Deployment、StatefulSet、DaemonSetなど）。WORKLOAD_NAME: 特定のワークロード インスタンスの名前。NAMESPACE_NAME: ワークロードが配置されている Namespace。SELECTOR_FOR_WORKLOAD: ワークロードに関連付けられているPodsを見つけるためのラベルセレクタ。例:app=my-app
DeploymentsまたはStatefulSetsワークロード タイプの Pod の場合は、kubectl describe podコマンドを実行して、個々の Pod のステータスを確認します。kubectl describe pod POD_NAME -n NAMESPACE_NAME次のように置き換えます。
POD_NAME: 特定の Pod の名前。NAMESPACE_NAME: Pod が配置されている Namespace。
Eventsセクションで、describe出力のイベントとログを分析し、次の情報を特定します。ImagePullBackOff / ErrImagePull: コンテナ イメージの取得に問題があることを示します。CrashLoopBackOff: コンテナが起動してクラッシュしていることを示します。
Containersセクションで、describe出力のコンテナログを分析し、kubectl logsコマンドを実行してコンテナ名を見つけます。kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME次のように置き換えます。
POD_NAME: 特定の Pod の名前。NAMESPACE_NAME: Pod が配置されている Namespace。CONTAINER_NAME: Pod 内のコンテナの名前。
describeの出力によると、Pod がリソース出力に表示されない理由として、次のような原因が考えられます。readiness プローブの失敗: コンテナの readiness プローブが成功していません。
リソースの問題: クラスタ内の CPU、メモリ、その他のリソースが不足しているか、割り当て上限に達しています。
初期コンテナの問題: 初期コンテナの障害により、メイン コンテナの起動がブロックされます。
構成エラー:
ConfigMaps、Secrets、または環境変数のエラー。ネットワークの問題:
Podsが必要なサービスと通信できません。
GKE クラスタのリソースを確認して、復元されたワークロードを実行するのに十分なノード容量、CPU、メモリが GKE クラスタにあることを確認します。Autopilot クラスタでは、ノードの自動プロビジョニングに時間がかかることがあります。そのため、ノードのスケーリングの制限やエラーを確認することをおすすめします。調査結果に基づいて根本的な問題に対処し、ワークロードが
ready状態になるのを妨げている問題を解決します。このアプローチでは、マニフェストの修正、リソース リクエストまたは上限の調整、ネットワーク ポリシーの修正、依存関係の確保などを行うことができます。根本的な問題が解決したら、ワークロードが
ready状態になるまで待ちます。復元オペレーションを再度実行する必要はありません。
問題が解決しない場合は、Cloud カスタマーケアにお問い合わせください。
エラー 200060102: ボリューム検証エラーのため、復元オペレーションを完了できませんでした
エラー 200060102 は、VolumeBackup から PersistentVolume へのデータ復元のプロセスを管理する 1 つ以上の VolumeRestore リソースが、復元オペレーションのボリューム検証フェーズで failed 状態または deleting 状態になったために発生します。ボリュームの復元に失敗すると、復元リソースの stateReason フィールドに次のエラー メッセージが表示されます。
Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]
エラー メッセージには、ターゲットの PersistentVolumeClaim 名と Namespace を含む、失敗した VolumeRestore の完全なリソース名が一覧表示されます。このエラー メッセージは、Backup for GKE が VolumeBackups から PersistentVolumes をプロビジョニングするために VolumeRestore リソースを開始したときに、影響を受ける PersistentVolumeClaim のデータ復元プロセスが正常に完了せず、スナップショットからの基盤となる Persistent Disk の作成が失敗したことを示しています。VolumeRestore の障害は、次の理由で発生する可能性があります。
割り当てが不足している: プロジェクトまたはリージョンに割り当てられている Persistent Disk 割り当てが不足しています（例:
SSD_TOTAL_GB）。権限の問題: Backup for GKE で使用されるサービス アカウントに、ディスクの作成やスナップショットへのアクセスに必要な権限がありません。
ネットワークの問題: ディスクの作成プロセスを中断する一時的または永続的なネットワークの問題があります。
無効なスナップショット: ソース
VolumeBackupまたは基盤となる Persistent Disk スナップショットが破損しているか、アクセスできません。リソースの制約: 他のクラスタ リソースの制約により、ボリュームのプロビジョニングが妨げられています。
内部エラー: Persistent Disk サービス内で内部的な問題が発生しています。
このエラーを解決するには、次の手順で対応します。
エラー メッセージに表示されている失敗した
PersistentVolumeClaimsを特定します。エラー メッセージには、失敗したVolumeRestoreオブジェクトの完全なリソース名が一覧表示されます。gcloud beta container backup-restore volume-restores describeコマンドを実行して、失敗した各VolumeRestoreリソースの詳細を取得します。gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_ID \ --restore=RESTORE_ID次のように置き換えます。
VOLUME_RESTORE_ID: 失敗したVolumeRestoreリソースの ID。PROJECT_ID: 実際の Google Cloud プロジェクト ID。LOCATION: 復元の Google Cloud ロケーション。RESTORE_PLAN_ID: 復元プランの ID。RESTORE_ID: 復元オペレーションの ID。
出力の
stateフィールドとstateMessageフィールドで、障害の詳細を確認します。kubectl get pvcコマンドを実行して、ターゲットPersistentVolumeClaimの状態を確認します。kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml次のように置き換えます。
PVC_NAME:PersistentVolumeClaimリソースの名前。NAMESPACE_NAME:PersistentVolumeClaimが配置されている Namespace。
出力の
status.phaseセクションにPendingフェーズが示されていることを確認します。このフェーズは、PersistentVolumeClaimがPersistentVolumeにまだバインドされていないことを意味します。これは、VolumeRestoreが失敗した場合に想定される状態です。YAML 出力の
Eventsセクションで、プロビジョニングの失敗に関連するメッセージ（ProvisioningFailedなど）を確認します。Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).出力は、ディスクの作成中に暗号鍵にアクセスする際に権限の問題が発生したことを示しています。鍵にアクセスするための
compute service agent関連の権限を付与するには、Backup for GKE ドキュメントの CMEK 暗号化の有効化に関する説明の手順に沿って操作します。kubectl get eventsコマンドを実行して、PersistentVolumeClaim名前空間の GKE イベントを確認します。このイベントには、PersistentVolumeコントローラまたは CSI ドライバからの詳細なエラー メッセージが含まれています。kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'NAMESPACE_NAMEはPersistentVolumeClaimの Namespace に置き換えます。PersistentVolumeClaim名に関連するイベントを特定します。この名前には、FailedProvisioningやExternalProvisioningなどのキーワードが含まれています。イベントには、pd.csi.storage.gke.ioなどのストレージ プロビジョナーのエラーが含まれることもあります。Cloud Logging の Cloud Audit Logs と Persistent Disk ログで、障害発生時のディスク作成オペレーションに関連するエラーがないか確認し、Persistent Disk ログを調べます。
生成されたエラー メッセージに基づいて、次の根本的な問題に対処します。
(QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceededなどの指示がある場合は、Persistent Disk の割り当てを増やします。IAM 権限を確認して修正します。
ネットワークの問題を調査して解決する。
スナップショットまたは Persistent Disk サービスに関する問題を解決するには、Cloud カスタマーケアにお問い合わせください。
PersistentVolumeClaimはPending状態のままです。復元オペレーション プロセスでは、
VolumeRestoreが自動的に再試行されません。この問題を解決するには、影響を受けるPersistentVolumeClaimを使用するDeploymentまたはStatefulSetワークロードの復元オペレーションをトリガーする必要があります。きめ細かい復元を使用して、失敗した
PersistentVolumeClaimに関連付けられているDeploymentまたはStatefulSetワークロードを選択的に復元します。このアプローチにより、基盤となる問題が解決された場合、標準の GKE メカニズムでPersistentVolumeClaimの作成とバインディングのプロセスを再度処理できます。きめ細かい復元の詳細については、きめ細かい復元を有効にするをご覧ください。
問題が解決しない場合や、VolumeRestore の失敗の原因が不明な場合は、Cloud カスタマーケアにお問い合わせください。
エラー 200060101: ボリュームの検証がタイムアウトしたため、復元オペレーションを完了できませんでした
エラー 200060101 は、復元オペレーションのボリューム検証フェーズで、VolumeBackup からのデータの復元を管理する 1 つ以上の VolumeRestore リソースが割り当てられたタイムアウト期間内に succeeded 状態に達しなかったため、Backup for GKE が待機を停止した場合に発生します。他の VolumeRestore リソースも不完全である可能性があります。
Restore リソースの stateReason フィールドのエラー メッセージには、タイムアウトがチェックされたときにまだ succeeded 状態になっていなかった最初の VolumeRestore リソースが表示されます。これには、その特定の VolumeRestore のターゲット PersistentVolumeClaim 名と Namespace が含まれます。次に例を示します。
Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]
Backup for GKE は VolumeRestore リソースを開始して、VolumeBackups から PersistentVolumes をプロビジョニングします。このエラーは、スナップショットからの基盤となる Persistent Disk の作成と、それに続く PersistentVolumeClaim の PersistentVolume へのバインドに、引用された VolumeRestore の計算されたタイムアウトよりも時間がかかったことを示しています。同じ復元オペレーションの他の VolumeRestores も完了していない状態になっている可能性があります。
Backup for GKE の観点からはタイムアウトに達していても、前述の VolumeRestore リソース、場合によっては VolumeRestore リソースの基盤となるディスク作成プロセスがまだ進行中であるか、失敗している可能性があります。
この問題を解決するには、次の手順で対応します。
エラー メッセージで、タイムアウトした
PersistentVolumeClaimの名前と名前空間を特定します（例:(PVC: PVC_NAMESPACE/PVC_NAME)）。gcloud beta container backup-restore volume-restores listコマンドを実行して、復元オペレーションに関連付けられているすべてのVolumeRestoresを一覧表示し、現在の状態を確認します。gcloud beta container backup-restore volume-restores list \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_NAME \ --restore=RESTORE_NAME次のように置き換えます。
PROJECT_ID: Google Cloud プロジェクトの IDLOCATION: 復元の Google Cloud ロケーション。RESTORE_PLAN_NAME: 復元プランの名前。RESTORE_NAME: 復元オペレーションの名前。
succeeded状態ではないVolumeRestoresを見つけます。gcloud beta container backup-restore volume-restores describeコマンドを実行して、エラーで言及されているVolumeRestoreと、succeeded状態ではない他のVolumeRestoresの詳細を取得します。gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_NAME \ --restore=RESTORE_NAME次のように置き換えます。
VOLUME_RESTORE_ID:VolumeRestoreリソースの ID。PROJECT_ID: 実際の Google Cloud プロジェクト ID。LOCATION: 復元の Google Cloud ロケーション。RESTORE_PLAN_NAME: 復元プランの名前。RESTORE_NAME: 復元オペレーションの名前。
stateフィールドとstateMessageフィールドを確認します。stateフィールドの値はcreatingまたはrestoringである可能性があります。stateMessageフィールドには、より多くのコンテキストが提供され、ターゲットPersistentVolumeClaimの詳細が含まれている場合があります。kubectl get pvcコマンドを実行して、特定されたターゲットPersistentVolumeClaimsの状態を調べます。kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml次のように置き換えます。
PVC_NAME:PersistentVolumeClaimの名前。PVC_NAMESPACE:PersistentVolumeClaimの名前空間。
PersistentVolumeClaim'sstatus.phaseの値はPendingになる可能性があります。Eventsセクションで次のエラーを確認します。Waiting for first consumer to be created before binding:StorageClassにvolumeBindingMode: WaitForFirstConsumerがあることを示します。PersistentVolumeClaimを使用するPodが作成されてスケジュールされるまで、PersistentVolumeのプロビジョニングは遅延します。この問題は、ボリューム プロビジョニング自体ではなく、Podスケジューリングに関連している可能性があります。そのため、PersistentVolumeClaimを使用するPodsがスケジュールされていない理由や開始されていない理由を確認することをおすすめします。FailedProvisioningまたはストレージ プロビジョナーからのエラー: たとえば、pd.csi.storage.gke.io。
kubectl get eventsコマンドを実行して、関連する Namespace の GKE イベントを確認します。kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'PVC_NAMESPACEは、PersistentVolumeClaimの Namespace に置き換えます。プロビジョニング メッセージやエラーなど、
PersistentVolumeClaim名に関連するイベントを探します。Cloud Logging で Cloud Audit Logs と Persistent Disk のログを確認します。
creating状態とrestoring状態のすべてのVolumeRestoresのステータスをモニタリングします。問題が解決すると、
VolumeRestoresのステータスはsucceededまたはfailedのいずれかの状態に移行できます。VolumeRestoresがsucceeded状態に達すると、PersistentVolumeClaimsはBoundになり、ワークロードは機能します。VolumeRestoreがfailed状態になった場合は、トラブルシューティングの手順を実施して、ボリュームの検証エラーを解決する必要があります。詳細については、エラー 200060102: ボリューム検証エラーのため、復元オペレーションを完了できませんでしたをご覧ください。
VolumeRestores が creating 状態または restoring 状態のまま長時間経過している場合は、Cloud カスタマーケアにお問い合わせください。