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

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

エラー 100010105: PersistentVolumeClaim のバックアップに失敗しました - PersistentVolume で参照されているディスクが存在しません

100010105 エラーは、存在しないディスクを参照していることが原因で PersistentVolumeClaim のバックアップの試行が失敗した場合に発生します。この場合、Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist というエラー メッセージが表示されます。

Google Kubernetes Engine では、PersistentVolumeClaims が PersistentVolumes からストレージをリクエストします。PersistentVolume は、ストレージの一部（多くの場合、基盤となる Compute Engine 永続ディスク）を表します。PersistentVolumeClaim が PersistentVolume にバインドされ、PersistentVolume の構成で Compute Engine 永続ディスクが指定されている場合、エラーが発生することがあります。ただし、PersistentVolume 構成で指定された名前と場所の実際のディスクが Cloud de Confiance by S3NS プロジェクトに見つかりません。そのため、Backup for GKE は存在しないディスクのバックアップを続行できず、エラーが発生します。

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

  1. 問題のある PersistentVolumeClaim と PersistentVolume を特定します。問題のある PersistentVolumeClaim とそれに関連付けられた PersistentVolume の両方の名前が、失敗した Backup for GKE オペレーションの state reason フィールドに表示されます。PersistentVolumeClaim の名前と名前空間、PersistentVolume の名前の両方を文書化することをおすすめします。

  2. PersistentVolume を調べます。PersistentVolume について説明するには、次のコマンドで状態理由フィールドから特定した PersistentVolume 名を使用します。

    kubectl describe pv PERSISTENTVOLUME_NAME

    PERSISTENTVOLUME_NAME は、PersistentVolume の名前に置き換えます。

  3. 出力で、source セクション（特に csi）を確認します。このセクションでは、PersistentVolume が参照しようとしている VolumeHandle について説明します。例:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    この例では、VolumeHandle にディスクのフルパス（名前とロケーションを含む）が含まれています。例: projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name

  4. PersistentVolume の説明から取得した VolumeHandle を使用して、ディスク名とゾーンを特定します。

  5. 次のいずれかの方法で、ディスクが Cloud de Confiance by S3NS プロジェクトに存在することを確認します。

    ゾーンディスク

    ゾーンディスクを使用している場合は、Google Cloud CLI を使用して gcloud compute disks describe コマンドを実行します。

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

    次のように置き換えます。

    • DISK_NAME: PersistentVolume の説明から取得したディスクの名前。

    • ZONE_NAME: PersistentVolume の説明から取得したディスクのゾーン。

    • PROJECT_ID: 実際の Cloud de Confiance by S3NS プロジェクト ID。

    リージョン ディスク

    リージョン ディスクを使用している場合は、Google Cloud CLI を使用して gcloud compute disks describe コマンドを実行します。

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

    次のように置き換えます。

    • DISK_NAME: PersistentVolume の説明から取得したディスクの名前。

    • REGION_NAME: PersistentVolume の説明から取得したディスクのリージョン。

    • PROJECT_ID: 実際の Cloud de Confiance by S3NS プロジェクト ID。

    Resource not found または The resource DISK_NAME was not found のエラー メッセージが表示された場合は、ディスクが存在しません。ニーズに最も適したシナリオに応じて、次のいずれかの方法で問題を解決します。

    • ディスクが誤って削除されたか、名前が間違っていて、データまたは PersistentVolumeClaim を保持する場合、または PersistentVolume が間違ったディスク名で構成されている場合は、次のいずれかの方法で問題を解決します。

      • ディスクを復元する: ディスクのバックアップがある場合は、PersistentVolume が参照しているのとまったく同じ名前とロケーションで復元します。

      • 新しいディスクを作成する: ディスクの復元がオプションでない場合は、PersistentVolume 構成と同じ名前とロケーションで新しいディスクを作成します。

    • PersistentVolumeClaim または PersistentVolume、そのデータ、またはアプリケーションが不要になった場合は、不要なエンティティを削除することをおすすめします。

      • PersistentVolumeClaim を削除する: kubectl コマンドライン ツールを使用して kubectl delete pvc コマンドを実行し、PersistentVolumeClaim を削除します。
      kubectl delete pvc PVC_NAME -n NAMESPACE

      次のように置き換えます。

      • PVC_NAME: 削除する PersistentVolumeClaim の名前。

      • NAMESPACE: 削除する PersistentVolumeClaim の名前空間。

    • PersistentVolumeClaim を削除しても PersistentVolume が残る: PersistentVolume の PersistentVolumeReclaimPolicy が Delete に設定されている場合、PersistentVolumeClaim が削除されると PersistentVolume は自動的に削除されます。persistentVolumeReclaimPolicy が Retain に設定されている場合は、PersistentVolumeClaim が削除された後に PersistentVolume を手動で削除する必要があります。PersistentVolume を削除するには、kubectl コマンドライン ツールを使用して kubectl delete pv コマンドを実行します。

      kubectl delete pv PV_NAME

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

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

エラー 100010202: ボリュームのスナップショット作成に失敗しました

エラー 100010202 は、Compute Engine 永続ディスクのスナップショットの作成に失敗した場合に発生します。この場合、Snapshotting volume failed というエラー メッセージが表示されます。

Backup for GKE サービスによって開始されたスナップショット作成プロセス中に、ディスクの仮想マシン（VM）インスタンスへのアタッチ状態が変更されると、Compute Engine 永続ディスクのスナップショット オペレーションは失敗します。このエラーをトリガーする一般的なシナリオは次のとおりです。

  • ノードの自動修復: 異常なノードが再作成されると、Pod が 再スケジュールされ、ディスクがデタッチされて再アタッチされます。
  • ノードのアップグレード: ノードプールのアップグレード中、通常はノードがドレインされて 置き換えられます。Pod は正常に終了し、新しいノードに再スケジュールされるため、ディスクのデタッチと再アタッチのサイクルがトリガーされます。
  • クラスタの自動スケーリング: スケールダウン イベント中に、クラスタ オートスケーラーがノードを削除すると、そのノード上の永続ディスクを持つ Pod が強制排除され、ディスクがデタッチされます。これらの Pod が別の場所に再スケジュールされると、新しいノードでアタッチが発生します。スケールアップ イベント中、新しいノードでは再アタッチは直接発生しませんが、それらにスケジュールされた Pod によって最初のアタッチがトリガーされます。

これは一時的なエラーです。通常、ディスクのアタッチが安定すると、次の自動実行でバックアップは成功します。クラスタ イベントがバックアップに影響しないようにするには、次の推奨事項を適用します。

  1. スマート スケジューリングを有効にする: スマート スケジューリング （RPO ベースのスケジュール）を使用してバックアップ プランを構成します。これにより、バックアップ プランの全体的な RPO に影響を与えることなく、指定した時間枠内で一時的な障害を自動的に再試行できます。

  2. バックアップ除外期間を設定する: ノードプール のアップグレードまたはクラスタのサイズ変更オペレーションを実行する場合は、その間隔でバックアップ設定に バックアップ除外期間 を追加します。これにより、クラスタがディスク アタッチメントをアクティブに変更している間、Backup for GKE サービスは一時停止し、スナップショットのスケジュール設定を回避します。

  3. 手動バックアップを再試行する: 手動バックアップまたはオンデマンド バックアップの場合は、クラスタ イベントが終了したらバックアップ オペレーションを再試行します。

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

次のステップ