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 構成で指定された名前と場所の実際のディスクが Google Cloud プロジェクトに見つかりません。そのため、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. 次のいずれかの方法で、ディスクが Google Cloud プロジェクトに存在することを確認します。

    ゾーンディスク

    ゾーンディスクを使用している場合は、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: 実際の Google Cloud プロジェクト 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: 実際の Google Cloud プロジェクト 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 Persistent Disk スナップショット オペレーションは失敗します。このエラーがトリガーされる一般的なシナリオは次のとおりです。

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

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

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

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

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

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

次のステップ