Backup for GKE のシステム エラーのトラブルシューティング

このページでは、Backup for GKE の使用時に発生する可能性のあるシステム関連のエラー、リソースのバックアップ時に考慮すべき事項、問題のトラブルシューティングの手順について説明します。

エラー 100020102: 厳密な許可モード - CRD のバックアップに失敗しました - サポートされていない v1beta1 API バージョン

100020102 エラーは、元々 apiextensions.k8s.io/v1beta1 バージョンとして適用された CustomResourceDefinition のバックアップの試行が、apiextensions.k8s.io/v1 API バージョンで必要な構造スキーマがないために失敗した場合に発生します。このエラーにより、次のエラー メッセージが表示されます: Strict permissive mode - Failed to backup CRD - Unsupported v1beta1 API Version。

このエラーは、Google Kubernetes Engine バージョン 1.22 で apiextensions.k8s.io/v1 API バージョンが削除されたために発生します。GKE バージョン 1.22 の API 削除の詳細については、GKE v1.22 の API 削除をご覧ください。

非 permissive モードでのバックアップ オペレーションの動作

制約なしモード以外の場合、または厳密なバックアップ プランでは、v1beta1 API で作成された CustomResourceDefinition など、バックアップできないリソースが検出されると、バックアップ オペレーションは失敗します。このエラーは、v1 API で必要な構造スキーマがリソースにないために発生します。この CustomResourceDefinition が存在すると、新しいクラスタに正しく復元されない可能性があるため、重大なエラーと見なされます。

このエラーを解決するには、次の手順で対応します。

  1. kubectl get crd コマンドを実行して、問題のある CustomResourceDefinition を特定します。

    kubectl get crd CRD_NAME

    CRD_NAME は、エラー メッセージの CustomResourceDefinition の名前に置き換えます。

  2. YAML 出力で、次の条件を見つけて、CustomResourceDefinition が vbeta1 API から v1 API に正しく変換されたかどうかを確認します。

    1. spec.versions: spec.versions フィールドに表示されている各バージョンを確認して、spec.versions 条件を見つけます。spec.versions のいずれかに schema.openAIV3Schema フィールドがない場合、CustomResourceDefinition にはそのバージョンの構造スキーマが定義されていません。

    2. status.conditions: type:NonStructuralSchema 条件を見つけて status.conditions 条件を見つけます。status.conditions の status が true の場合、スキーマが構造的でないことを明示的に確認します。

  3. 次の手順で CustomResourceDefinition を v1 API バージョンにアップグレードします。

    1. カスタム リソース内のすべてのフィールドとその型を定義する構造スキーマを追加して、既存の CustomResourceDefinition を編集し、v1 標準と互換性を持たせます。構造スキーマを追加する方法の詳細については、構造スキーマの指定をご覧ください。

    2. 互換性のある v1 マニフェストをクラスタに適用します。

  4. アップグレードが成功したら、バックアップ オペレーションを再試行します。それ以外の場合は、次のいずれかの方法で問題を解決します。

    • クラスタで CustomResourceDefinition が使用されていない場合は、kubectl delete crd コマンドを実行して CustomResourceDefinition を削除します。

      kubectl delete crd CRD_NAME

      CRD_NAME は、削除する CustomResourceDefinition の名前に置き換えます。

    • バックアップ プランで Permissive モードを有効にします。これにより、Backup for GKE はリソース（v1beta1 API バージョンの CustomResourceDefinitions を含む）をスキップし、残りのバックアップ オペレーションを続行できます。制約なしモードを有効にする方法については、バックアップ プランで制約なしモードを有効にするをご覧ください。

  5. バックアップ オペレーションを再試行します。オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。

エラー 100040102: Namespace not found

エラー 100040102 は、バックアップ スコープで指定された Namespace がクラスタ内で見つからないことが原因で、バックアップ オペレーションの実行が失敗した場合に発生します。Backup for GKE エージェントは、BackupPlan 構成の selectedNamespaces フィールドに明示的にリストされている 1 つ以上の Namespace を特定できませんでした。Backup for GKE では、バックアップ オペレーションの開始時に、指定されたすべての Namespace がクラスタに存在する必要があります。Namespace が見つからないと、次のエラー メッセージが表示されます。

Namespace [NAMESPACE_NAME] is not found.

この問題を解決するには、次の手順で対応します。

  1. BackupPlan 構成の selectedNamespaces リストを確認して、Namespace が正しく入力されていることを確認します。

  2. kubectl get namespace コマンドを実行して、エラー メッセージで報告された Namespace が存在することを確認します。

    kubectl get namespace NAMESPACE_NAME

    NAMESPACE_NAME は、エラー メッセージで報告された名前空間の名前に置き換えます。

    Namespace が存在しない場合は、Namespace が見つからなかったことを示すメッセージ（Error from server (NotFound): namespaces "[NAMESPACE_NAME]" not found など）が表示されます。

  3. BackupPlan を修正します。名前空間のスペルが間違っている場合は、BackupPlan を正しい名前空間名で更新します。Namespace が本当に存在せず、バックアップする必要がない場合は、BackupPlan 構成の selectedNamespaces リストから削除します。

  4. BackupPlan に必要な修正を加えてから、バックアップ オペレーションを再試行し、新しいバックアップを開始します。

オペレーションが引き続き失敗する場合は、Cloud カスタマーケアにお問い合わせください。

次のステップ