Résoudre les problèmes de stockage dans Sauvegarde pour GKE

Cette page décrit les erreurs liées au stockage que vous pouvez rencontrer lorsque vous utilisez Sauvegarde pour GKE, les éléments à prendre en compte lorsque vous effectuez l'action et les étapes à suivre pour résoudre le problème.

Erreur 100010105 : Échec de la sauvegarde de PersistentVolumeClaim. Le disque référencé par PersistentVolume n'existe pas

L'erreur 100010105 se produit lorsqu'une tentative de sauvegarde d'un PersistentVolumeClaim échoue, car il fait référence à un disque qui n'existe pas. Un message d'erreur s'affiche alors : Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

Dans Google Kubernetes Engine, les PersistentVolumeClaims demandent du stockage aux PersistentVolumes. Un PersistentVolume représente une partie du stockage, souvent un disque persistant Compute Engine sous-jacent. Une erreur peut se produire lorsqu'un PersistentVolumeClaim est lié à un PersistentVolume et que la configuration du PersistentVolume's spécifie un disque persistant Compute Engine. Toutefois, le disque réel portant le nom et l' emplacement spécifiés dans la configuration PersistentVolume est introuvable dans votre Cloud de Confiance by S3NS projet. Par conséquent, Sauvegarde pour GKE ne peut pas sauvegarder un disque inexistant et une erreur se produit.

Pour résoudre cette erreur, suivez ces instructions :

  1. Identifiez les PersistentVolumeClaim et PersistentVolume problématiques. Les noms du PersistentVolumeClaim problématique et de son PersistentVolume associé sont listés dans le champ state reason de votre opération Sauvegarde pour GKE ayant échoué. Nous vous recommandons de documenter le PersistentVolumeClaim nom, son espace de noms et le nom du PersistentVolume.

  2. Inspectez le PersistentVolume. Pour décrire le PersistentVolume, utilisez le nom du PersistentVolume que vous avez identifié dans le champ "state reason" de la commande suivante :

    kubectl describe pv PERSISTENTVOLUME_NAME

    Remplacez PERSISTENTVOLUME_NAME par le nom de votre PersistentVolume.

  3. Dans la sortie, examinez la section source, en particulier sous csi. Cette section décrit le VolumeHandle que le PersistentVolume tente de référencer. Exemple :

    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
...

    Dans cet exemple, le VolumeHandle contient le chemin d'accès complet au disque, y compris son nom et son emplacement. Par exemple, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Utilisez le VolumeHandle obtenu à partir de la description du PersistentVolume pour identifier le nom et la zone du disque.

  5. Vérifiez que le disque existe dans votre Cloud de Confiance by S3NS projet à l'aide de l'une des méthodes suivantes :

    Disque zonal

    Si vous utilisez un disque zonal, exécutez la commande gcloud compute disks describe à l'aide de Google Cloud CLI :

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

    Remplacez les éléments suivants :

    • DISK_NAME: nom du disque que vous avez obtenu à partir de la description du PersistentVolume.

    • ZONE_NAME: zone du disque que vous avez obtenu à partir de la description du PersistentVolume.

    • PROJECT_ID: ID de votre Cloud de Confiance by S3NS projet.

    Disque régional

    Si vous utilisez un disque régional, exécutez la commande gcloud compute disks describe à l'aide de Google Cloud CLI :

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

    Remplacez les éléments suivants :

    • DISK_NAME: nom du disque que vous avez obtenu à partir de la description du PersistentVolume.

    • REGION_NAME: région du disque que vous avez obtenu à partir de la description du PersistentVolume.

    • PROJECT_ID: ID de votre Cloud de Confiance by S3NS projet.

    Si vous recevez un Resource not found ou The resource DISK_NAME was not found message d'erreur, cela signifie que le disque n'existe pas. Utilisez l'une des méthodes suivantes pour résoudre le problème en fonction du scénario qui correspond le mieux à vos besoins :

    • Si le disque a été supprimé ou mal nommé par erreur et que vous souhaitez conserver les données ou PersistentVolumeClaim, ou si le PersistentVolume a été configuré avec un nom de disque incorrect, utilisez l'une des méthodes suivantes pour résoudre le problème :

      • Restaurer le disque : si vous disposez d'une sauvegarde du disque, restaurez-le avec le nom et l'emplacement exacts référencés par le PersistentVolume.

      • Créer un disque : si la restauration du disque n'est pas possible, créez un disque portant le même nom et au même emplacement que dans la PersistentVolume configuration.

    • Si le PersistentVolumeClaim ou le PersistentVolume, leurs données ou l' application ne sont plus nécessaires, nous vous recommandons de supprimer l'entité inutile :

      • Supprimer le PersistentVolumeClaim : supprimez le PersistentVolumeClaim à l'aide de l'outil de ligne de commande kubectl pour exécuter la commande kubectl delete pvc :
      kubectl delete pvc PVC_NAME -n NAMESPACE

      Remplacez les éléments suivants :

      • PVC_NAME: nom du PersistentVolumeClaim que vous souhaitez supprimer.

      • NAMESPACE: espace de noms du PersistentVolumeClaim que vous souhaitez supprimer.

    • Le PersistentVolume est toujours présent après la suppression du PersistentVolumeClaim: si la PersistentVolumeReclaimPolicy du PersistentVolume est définie sur Delete, le PersistentVolume est automatiquement supprimé lorsque le PersistentVolumeClaim est supprimé. Si le persistentVolumeReclaimPolicy est défini sur Retain, vous devez supprimer manuellement le PersistentVolume après la suppression du PersistentVolumeClaim. Pour supprimer le PersistentVolume, utilisez l'outil de ligne de commande kubectl pour exécuter la commande kubectl delete pv :

      kubectl delete pv PV_NAME

      Remplacez PV_NAME par le nom du PersistentVolume que vous souhaitez supprimer.

Si l'opération échoue toujours, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Erreur 100010202 : Échec de la création de l'instantané du volume

L'erreur 100010202 se produit lorsque la création d'un instantané de disque persistant Compute Engine échoue. Un message d'erreur s'affiche alors : Snapshotting volume failed (Échec de la création de l'instantané du volume).

Une opération d'instantané de disque persistant Compute Engine échoue si l'état de connexion du disque à une instance de machine virtuelle (VM) change pendant le processus de création d'instantané initié par le service Sauvegarde pour GKE. Voici quelques scénarios courants qui déclenchent ce problème :

  • Réparation automatique des nœuds : les nœuds non opérationnels sont recréés, ce qui entraîne la reprogrammation des pods et le détachement et le rattachement des disques.
  • Mises à niveau des nœuds : lors des mises à niveau du pool de nœuds, les nœuds sont généralement drainés et remplacés. Les pods sont arrêtés et reprogrammés sur les nouveaux nœuds, ce qui déclenche des cycles de détachement et de rattachement des disques.
  • Autoscaling de cluster : lors des événements de scaling à la baisse, si l'autoscaler de cluster supprime un nœud, tous les pods de ce nœud avec des disques persistants sont évincés, ce qui entraîne le détachement des disques. Si ces pods sont reprogrammés ailleurs, des rattachements se produiront sur les nouveaux nœuds. Lors des événements de scaling à la hausse, les nouveaux nœuds n'entraînent pas directement de rattachements, mais les pods qui y sont programmés déclenchent des rattachements initiaux.

Il s'agit d'une erreur temporaire. La sauvegarde réussit généralement lors de la prochaine exécution automatisée une fois que la connexion du disque est stabilisée. Pour éviter que les événements de cluster n'aient un impact sur vos sauvegardes, appliquez les recommandations suivantes :

  1. Activer la planification intelligente : configurez votre plan de sauvegarde à l'aide de la planification intelligente (une programmation basée sur le RPO). Cela permet au système de réessayer automatiquement les échecs temporaires dans la fenêtre temporelle spécifiée sans affecter le RPO global du plan de sauvegarde.

  2. Configurer des fenêtres d'exclusion de sauvegarde : si vous effectuez des mises à niveau du pool de nœuds ou des opérations de redimensionnement du cluster, ajoutez une fenêtre d'exclusion de sauvegarde à vos paramètres de sauvegarde pendant ces intervalles. Cela garantit que le service Sauvegarde pour GKE mettra en pause et évitera de planifier des instantanés pendant que votre cluster modifie activement les connexions de disque.

  3. Réessayer les sauvegardes manuelles : dans le cas de sauvegardes manuelles ou à la demande, réessayez l'opération de sauvegarde une fois l'événement de cluster terminé.

Si l'opération échoue toujours, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Étape suivante