このドキュメントでは、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 --sort-by='.lastTimestamp'NAMESPACEは名前空間の名前に置き換えます。
前の手順の結果に基づいて、リソース削除の原因に対処します。たとえば、競合する自動化の一時停止、誤った構成の修正、ユーザー権限の調整を行います。
次のいずれかの方法で、不足しているリソースを復元します。
マニフェスト ファイルを再適用する: 不足しているリソースのマニフェストがある場合は、正しい名前空間に再適用できます。
きめ細かい復元を実行する: きめ細かい復元オペレーションを実行して、同じバックアップから不足しているリソースのみを選択的に復元します。これにより、正しい名前空間を指定できます。きめ細かい復元オペレーションの実行方法については、きめ細かい復元を有効にするをご覧ください。
復元オペレーションを再試行します。復元オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。