Résoudre les erreurs d'autorisation dans Sauvegarde pour GKE

Ce document décrit les erreurs et les codes correspondants que vous pouvez rencontrer lorsque vous utilisez Sauvegarde pour GKE pour effectuer des opérations de restauration. Chaque section inclut des éléments à prendre en compte lorsque vous effectuez des actions pour résoudre les erreurs de restauration, ainsi que des instructions sur la façon de résoudre les erreurs d'opération de restauration.

Erreur 200010301 : Échec de l'opération de restauration en raison de l'indisponibilité du service de webhook d'admission

L'erreur 200010301 se produit lorsqu'une tentative d'exécution d'une opération de restauration échoue, car un service de webhook d'admission, également appelé rappel HTTP, n'est pas disponible, ce qui entraîne le message d'erreur suivant. Le message d'erreur indique que le serveur d'API GKE a tenté de contacter un webhook d'admission lors de la restauration d'une ressource, mais que le service qui le prend en charge était indisponible ou introuvable :

  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.

Cette erreur se produit lorsqu'une ressource GKE ValidatingAdmissionWebhook ou MutatingAdmissionWebhook est active dans le cluster cible, mais que le serveur d'API GKE ne parvient pas à atteindre le point de terminaison configuré dans le webhook. Les webhooks d'admission interceptent les requêtes envoyées au serveur d'API GKE, et leur configuration spécifie la manière dont le serveur d'API GKE doit interroger les requêtes.

Le clientConfig du webhook spécifie le backend qui gère les requêtes d'admission, qui peut être un service de cluster interne ou une URL externe. Le choix entre ces deux options dépend des exigences opérationnelles et architecturales spécifiques de votre webhook. En fonction du type d'option, l'opération de restauration peut avoir échoué pour les raisons suivantes :

  • Services dans le cluster : le service GKE et ses pods de sauvegarde ne sont pas restaurés ni prêts lorsque le serveur d'API GKE a tenté d'appeler le webhook. Cela se produit lors des opérations de restauration où les configurations de webhook à portée cluster sont appliquées avant que les services à portée espace de noms ne soient entièrement à l'état ready.

  • URL externes : le point de terminaison externe est temporairement indisponible en raison de problèmes de connectivité réseau entre le cluster GKE et le point de terminaison externe, ou en raison de problèmes de résolution DNS ou de règles de pare-feu.

Pour résoudre cette erreur, suivez les instructions ci-dessous :

  1. Identifiez le webhook défaillant mentionné dans le message d'erreur. Par exemple, failed calling webhook "...".

  2. Inspectez le webhook en exécutant la commande kubectl get validatingwebhookconfigurations :

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Remplacez WEBHOOK_NAME par le nom du webhook identifié dans le message d'erreur.

    Vous pouvez également exécuter la commande kubectl get mutatingwebhookconfigurations pour inspecter le webhook :

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Remplacez WEBHOOK_NAME par le nom du webhook identifié dans le message d'erreur.

  3. Suivez les étapes de dépannage ci-dessous en fonction de votre type de configuration :

    En fonction du service : clientConfig

    Définissez un ordre de restauration personnalisé en modifiant la ressource RestorePlan pour inclure un RestoreOrder avec des entrées GroupKindDependency. Cela permet de restaurer et de préparer les composants qui sous-tendent le webhook, tels que Deployment, StatefulSet ou Service, avant ValidatingWebhookConfiguration ou MutatingWebhookConfiguration.

    Pour savoir comment définir un ordre de restauration personnalisé, consultez Spécifier l'ordre de restauration des ressources.

    Cette approche peut échouer, car les pods du service n'entrent pas dans un état ready complet, même après la création de l'objet Service. Une autre raison de l'échec peut être que la configuration du webhook a été créée de manière inattendue par une autre application. Vous pouvez également effectuer une opération de restauration en deux étapes en procédant comme suit :

    1. Créez une ressource Restore à l'aide de la sauvegarde en configurant l'opération de restauration avec un filtre de restauration précis qui inclurait les ressources spécifiques nécessaires au fonctionnement du webhook, par exemple Namespaces, Deployments, StatefulSets ou Services.

      Pour savoir comment configurer la restauration avec un filtre de restauration ultraprécis, consultez Activer la restauration ultraprécise.

    2. Créez une autre ressource Restore pour l'opération de sauvegarde et configurez le reste des ressources de votre choix.

    clientConfig basé sur l'URL

    1. Vérifiez le point de terminaison HTTPS externe et assurez-vous qu'il est actif, accessible et qu'il fonctionne correctement.

    2. Vérifiez qu'il existe une connectivité réseau entre les nœuds et le plan de contrôle de votre cluster GKE et l'URL externe. Vous devrez peut-être également vérifier les règles de pare-feu, par exemple si vous utilisez un cloud privé virtuel, un fournisseur de services cloud ou un fournisseur sur site pour héberger le webhook, les règles réseau et la résolution DNS.

  4. Réessayez l'opération de restauration. Si l'opération continue d'échouer, contactez Cloud Customer Care pour obtenir de l'aide.

Erreur 200010302 : Échec de l'opération de restauration en raison d'une demande de création de ressources refusée

L'erreur 200010302 se produit lorsqu'une tentative d'opération de restauration échoue, car un webhook d'admission refuse une demande de création de ressource. L'erreur suivante s'affiche alors, indiquant qu'une ressource de votre sauvegarde n'a pas pu être créée dans le cluster cible, car un webhook d'admission actif a intercepté la demande et l'a refusée en fonction d'une règle personnalisée :

  [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}

Cette erreur est due à la configuration définie dans le cluster GKE cible, qui comporte un ValidatingAdmissionWebhook ou un MutatingAdmissionWebhook qui applique des règles spécifiques à la création et à la modification de ressources, bloquant ainsi la demande de création de ressources. Par exemple, un webhook empêche la création d'une ressource, car une ressource associée, mais en conflit, existe déjà dans le cluster. Par exemple, un webhook peut refuser la création d'un déploiement s'il est déjà géré par une ressource d'API GKE HorizontalPodAutoscaler.

Pour résoudre cette erreur, suivez les instructions ci-dessous :

  1. Identifiez le webhook qui refuse la requête à l'aide du message d'erreur qui s'affiche lorsque l'opération de restauration échoue. Par exemple : webhook WEBHOOK_NAME denied the request Le message d'erreur contient les informations suivantes :

    • Nom du webhook : nom du webhook qui refuse la requête.

    • Motif du refus : motif spécifique du refus de la demande.

  2. Inspectez le webhook en exécutant la commande kubectl get validatingwebhookconfigurations :

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Remplacez WEBHOOK_NAME par le nom du webhook que vous avez identifié dans le message d'erreur.

    Vous pouvez également exécuter la commande kubectl get mutatingwebhookconfigurations pour inspecter le webhook :

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Remplacez WEBHOOK_NAME par le nom du webhook que vous avez identifié dans le message d'erreur.

  3. Résolvez le problème sous-jacent dans le cluster cible. L'action à effectuer dépend de l'erreur spécifique. Par exemple, en cas de conflit HorizontalPodAutoscaler, vous devez supprimer le HorizontalPodAutoscaler existant dans le cluster cible avant d'exécuter la restauration pour permettre la création des charges de travail sauvegardées et de leurs ressources associées.

  4. Réessayez l'opération de restauration. Si l'opération de restauration continue d'échouer, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Erreur 200060202 : Échec de l'opération de restauration en raison d'une ressource GKE manquante lors de la validation de la charge de travail

L'erreur 200060202 se produit lors de la phase de validation de la charge de travail d'une opération de restauration lorsqu'une ressource GKE que Sauvegarde pour GKE s'attend à valider est introuvable dans le cluster cible. Le message d'erreur suivant s'affiche alors :

  Workload Validation Error: [KIND] "[NAME]" not found

Par exemple : Example: Workload Validation Error: pods "jenkins-0" not found

Cette erreur se produit lorsque Sauvegarde pour GKE crée ou met à jour la ressource GKE dans le cadre du processus de l'opération de restauration, mais que, lorsque la phase de validation commence, une ou plusieurs ressources GKE ne sont plus présentes dans le cluster cible, car elles ont été supprimées après avoir été créées ou mises à jour initialement par le processus de restauration, mais avant que la validation de la charge de travail pour la ressource GKE puisse se terminer. Une erreur de ce type peut se produire pour les raisons suivantes :

  • Suppression manuelle : un utilisateur ou un administrateur a supprimé manuellement la ressource à l'aide de kubectl ou d'autres outils Google Cloud .

  • Automatisation externe : les contrôleurs GitOps tels que Config Sync, ArgoCD, Flux, les scripts personnalisés ou d'autres outils de gestion de cluster ont rétabli ou supprimé la ressource pour qu'elle corresponde à l'état souhaité dans un dépôt.

  • Contrôleurs GKE : un contrôleur GKE a supprimé une ressource, car elle était en conflit avec d'autres ressources ou d'autres règles, ou une chaîne OwnerReference a entraîné une collecte des déchets, ou le processus de nettoyage automatisé par GKE qui supprime les ressources dépendantes lorsque leur ressource owner est supprimée.

Pour résoudre cette erreur, suivez les instructions ci-dessous :

  1. Identifiez la ressource manquante à l'aide du message d'erreur qui s'affiche lorsque l'opération de restauration ne peut pas être effectuée.

  2. Localisez l'espace de noms auquel appartient la ressource à l'aide de l'une des méthodes suivantes :

    • Journaux d'audit GKE : examinez les journaux d'audit GKE générés lorsque vous avez tenté l'opération de restauration. Vous pouvez filtrer les journaux pour les opérations de suppression sur les ressources Kind et Name. L'entrée de journal d'audit contient l'espace de noms d'origine.

    • Détails de la sauvegarde : vérifiez le champ d'application de votre opération de restauration et le contenu de la sauvegarde. L'index de sauvegarde indique l'espace de noms d'origine de la ressource. Vous pouvez également vérifier si RestorePlan contient un TransformationRule qui spécifie les règles de restauration de la ressource dans l'espace de noms de votre choix.

    • Rechercher dans les espaces de noms : exécutez la commande kubectl get pour rechercher la ressource dans tous les espaces de noms :

      kubectl get KIND --all-namespaces | grep NAME

      Remplacez KIND et NAME par les valeurs du message d'erreur. Si la ressource existe toujours, cette commande affichera son espace de noms.

  3. Vérifiez la suppression en exécutant la commande kubectl get :

    kubectl get KIND NAME -n [NAMESPACE]

    Remplacez KIND et NAME par les valeurs du message d'erreur. Vous devriez recevoir un message d'erreur not found.

  4. Pour déterminer la cause de la suppression, utilisez l'une des méthodes suivantes :

    • Journaux d'audit GKE : identifiez l'entité qui a émis la demande de suppression. Par exemple, l'utilisateur, le compte de service ou le contrôleur.

    • Vérifiez les automatisations configurées : si vous utilisez GitOps ou d'autres outils d'automatisation, consultez leurs journaux et leur état pour voir s'ils ont interféré avec les ressources restaurées.

    • Examiner les événements associés : vérifiez les événements GKE dans l'espace de noms déterminé en exécutant la commande kubectl get events :

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      Remplacez NAMESPACE_NAME par le nom de l'espace de noms.

  5. Corrigez la cause de la suppression de la ressource en fonction des résultats de l'étape précédente. Par exemple, mettez en veille les automatisations conflictuelles, corrigez les erreurs de configuration ou ajustez les autorisations des utilisateurs.

  6. Récupérez la ressource manquante à l'aide de l'une des méthodes suivantes :

    • Réappliquez les fichiers manifestes : si vous disposez du fichier manifeste pour la ressource manquante, vous pouvez le réappliquer à l'espace de noms approprié.

    • Effectuez une restauration ultraprécise : effectuez une opération de restauration ultraprécise pour restaurer sélectivement la ressource manquante à partir de la même sauvegarde, ce qui vous permet de spécifier le bon espace de noms. Pour en savoir plus sur la façon d'effectuer une opération de restauration ultraprécise, consultez Activer la restauration ultraprécise.

  7. Réessayez l'opération de restauration. Si l'opération de restauration continue d'échouer, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Erreur 200060201 : Échec de l'opération de restauration en raison du délai d'expiration de la validation de la charge de travail

L'erreur 200060201 se produit lorsqu'une ou plusieurs charges de travail restaurées ne deviennent pas entièrement ready dans le délai prévu lors d'une opération de restauration après la création des ressources dans le cluster. Le message d'erreur suivant s'affiche alors :

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Cette erreur se produit, car Sauvegarde pour GKE effectue une étape de validation après la restauration des configurations de ressources GKE pour s'assurer que les charges de travail critiques fonctionnent correctement. Sauvegarde pour GKE attend que certaines charges de travail atteignent l'état ready, mais au moins une charge de travail n'a pas respecté le critère de préparation suivant dans le délai imparti :

  • Pour Pods : status.Phase est Running

  • Pour Deployments : status.ReadyReplicas est égal à spec.Replicas

  • Pour StatefulSets : status.ReadyReplicas est égal à spec.Replicas

  • Pour DaemonSets : status.NumberReady est égal à status.DesiredNumberScheduled

Pour résoudre cette erreur, suivez les instructions ci-dessous :

  1. Identifiez les charges de travail qui ne sont pas à l'état ready dans le message d'erreur qui liste les charges de travail et leurs espaces de noms qui n'ont pas pu passer à l'état ready.

  2. Inspectez l'état des charges de travail et obtenez des détails et des événements pour les charges de travail ayant échoué en exécutant la commande kubectl describe :

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    Remplacez les éléments suivants :

    • WORKLOAD_TYPE : type de charge de travail, par exemple Deployment, StatefulSet ou DaemonSet.

    • WORKLOAD_NAME : nom de l'instance de charge de travail spécifique.

    • NAMESPACE_NAME : espace de noms dans lequel se trouve la charge de travail.

    • SELECTOR_FOR_WORKLOAD : sélecteur de libellés permettant de trouver Pods associé à la charge de travail. Par exemple, app=my-app.

    Pour les pods de types de charge de travail Deployments ou StatefulSets, vérifiez l'état des pods individuels en exécutant la commande kubectl describe pod :

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Remplacez les éléments suivants :

    • POD_NAME : nom du pod spécifique.

    • NAMESPACE_NAME : espace de noms dans lequel se trouve le pod.

  3. Dans la section Events, analysez les événements et les journaux dans la sortie describe et recherchez les informations suivantes :

    • ImagePullBackOff / ErrImagePull : indique qu'il existe des problèmes de récupération des images de conteneurs.

    • CrashLoopBackOff : indique que les conteneurs démarrent et plantent.

  4. Dans la section Containers, analysez les journaux de conteneur dans la sortie describe pour trouver le nom du conteneur en exécutant la commande kubectl logs :

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Remplacez les éléments suivants :

    • POD_NAME : nom du pod spécifique.

    • NAMESPACE_NAME : espace de noms dans lequel se trouve le pod.

    • CONTAINER_NAME : nom du conteneur dans le pod.

    Selon le résultat describe, plusieurs raisons peuvent expliquer pourquoi le pod n'apparaît pas dans le résultat de la ressource, y compris les suivantes :

    • Échecs des vérifications d'aptitude : les vérifications d'aptitude du conteneur ne fonctionnent pas.

    • Problèmes de ressources : le cluster ne dispose pas de suffisamment de ressources de processeur, de mémoire ou autres, ou les limites de quota sont atteintes.

    • Problèmes liés aux conteneurs d'initialisation : échecs dans les conteneurs d'initialisation empêchant le démarrage des conteneurs principaux.

    • Erreurs de configuration : erreurs dans ConfigMaps, Secrets ou les variables d'environnement.

    • Problèmes de réseau : Pods ne peut pas communiquer avec les services requis.

  5. Vérifiez les ressources du cluster GKE pour vous assurer qu'il dispose d'une capacité de nœud, d'un processeur et d'une mémoire suffisants pour exécuter les charges de travail restaurées. Dans les clusters Autopilot, le provisionnement automatique des nœuds peut prendre plus de temps. Nous vous recommandons donc de vérifier s'il existe des limites ou des erreurs de scaling des nœuds. Résolvez les problèmes sous-jacents en fonction de vos conclusions et corrigez ceux qui empêchent les charges de travail de passer à l'état ready. Cette approche peut impliquer de corriger les fichiers manifestes, d'ajuster les demandes ou les limites de ressources, de corriger les règles réseau ou de s'assurer que les dépendances sont satisfaites.

  6. Une fois les problèmes sous-jacents résolus, attendez que les charges de travail passent à l'état ready. Vous n'avez pas besoin de relancer l'opération de restauration.

Si le problème persiste, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Erreur 200060102 : Échec de l'opération de restauration en raison d'une erreur de validation du volume

L'erreur 200060102 se produit lorsqu'une ou plusieurs ressources VolumeRestore, qui gèrent le processus de restauration des données de VolumeBackup vers un PersistentVolume, sont passées à l'état failed ou deleting pendant la phase de validation du volume d'une opération de restauration. L'échec de la restauration du volume entraîne le message d'erreur suivant dans le champ "stateReason" de la ressource de restauration :

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

Le message d'erreur liste les noms de ressources complets des VolumeRestore ayant échoué, y compris le nom et l'espace de noms PersistentVolumeClaim cibles. Le message d'erreur indique que le processus de restauration des données pour le PersistentVolumeClaim concerné ne s'est pas terminé correctement lorsque Sauvegarde pour GKE a lancé des ressources VolumeRestore pour provisionner PersistentVolumes à partir de VolumeBackups, et que la création du disque persistant sous-jacent à partir de l'instantané a échoué. Les échecs VolumeRestore peuvent se produire pour les raisons suivantes :

  • Quota insuffisant : le quota de disque persistant alloué dans le projet ou la région est insuffisant (par exemple, SSD_TOTAL_GB).

  • Problèmes d'autorisations : le compte de service utilisé par la sauvegarde pour GKE ne dispose pas des autorisations nécessaires pour créer des disques ou accéder aux instantanés.

  • Problèmes réseau : des problèmes réseau temporaires ou persistants interrompent le processus de création du disque.

  • Instantané non valide : la source VolumeBackup ou l'instantané de disque persistant sous-jacent sont corrompus ou inaccessibles.

  • Contraintes de ressources : d'autres contraintes de ressources de cluster entravent le provisionnement de volumes.

  • Erreurs internes : des problèmes internes se sont produits dans le service Persistent Disk.

Pour résoudre cette erreur, suivez les instructions ci-dessous :

  1. Identifiez le PersistentVolumeClaims ayant échoué, listé dans le message d'erreur, qui indique les noms de ressources complets des objets VolumeRestore ayant échoué.

  2. Obtenez les détails de chaque ressource VolumeRestore ayant échoué en exécutant la commande gcloud beta container backup-restore volume-restores describe :

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    Remplacez les éléments suivants :

    • VOLUME_RESTORE_ID : ID de la ressource VolumeRestore ayant échoué.

    • PROJECT_ID : ID de votre projet Google Cloud .

    • LOCATION : emplacement Google Cloud de la restauration.

    • RESTORE_PLAN_ID : ID du plan de restauration.

    • RESTORE_ID : ID de l'opération de restauration.

  3. Examinez les champs state et stateMessage dans le résultat pour obtenir des informations sur l'échec.

  4. Examinez l'état de la cible PersistentVolumeClaim en exécutant la commande kubectl get pvc :

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Remplacez les éléments suivants :

    • PVC_NAME : nom de la ressource PersistentVolumeClaim.

    • NAMESPACE_NAME : espace de noms dans lequel se trouve PersistentVolumeClaim.

  5. Vérifiez que la section status.phase du résultat indique une phase Pending. Cette phase signifie que la PersistentVolumeClaim n'est pas encore liée à un PersistentVolume, ce qui est normal si le VolumeRestore échoue.

  6. Examinez la section Events dans la sortie YAML pour trouver les messages liés aux échecs de provisionnement, tels que ProvisioningFailed, par exemple :

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    Le résultat indique qu'un problème d'autorisation s'est produit lors de l'accès à la clé de chiffrement pendant la création du disque. Pour accorder l'autorisation compute service agent permettant d'accéder à la clé, suivez les instructions de la documentation Sauvegarde pour GKE sur l'activation du chiffrement CMEK.

  7. Examinez les événements GKE dans l'espace de noms PersistentVolumeClaim, qui fournissent des messages d'erreur détaillés du contrôleur PersistentVolume ou du pilote CSI, en exécutant la commande kubectl get events :

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    Remplacez NAMESPACE_NAME par l'espace de noms de PersistentVolumeClaim.

  8. Identifiez les événements liés au nom PersistentVolumeClaim, qui contient des mots clés tels que FailedProvisioning ou ExternalProvisioning. Les événements peuvent également contenir des erreurs du provisionneur de stockage, telles que pd.csi.storage.gke.io.

  9. Examinez les journaux Persistent Disk en consultant les journaux Cloud Audit Logs et Persistent Disk dans Cloud Logging pour détecter d'éventuelles erreurs liées aux opérations de création de disque au moment de l'échec.

  10. En fonction des messages d'erreur générés, résolvez les problèmes sous-jacents suivants :

    • Augmentez les quotas Persistent Disk si nécessaire, par exemple (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Vérifiez et corrigez les autorisations IAM.

    • Examiner et résoudre les problèmes de réseau.

    • Contactez l'équipe Cloud Customer Care pour résoudre les problèmes liés à l'instantané ou au service Persistent Disk.

    • L'état de PersistentVolumeClaim reste Pending.

    • Le processus de restauration ne relance pas automatiquement le VolumeRestore. Pour résoudre ce problème, vous devez déclencher une opération de restauration pour la charge de travail Deployment ou StatefulSet qui utilise le PersistentVolumeClaim concerné.

    • Utilisez une restauration précise pour restaurer de manière sélective la charge de travail Deployment ou StatefulSet associée à l'PersistentVolumeClaim ayant échoué. Cette approche permet aux mécanismes GKE standards de gérer à nouveau le processus de création et de liaison PersistentVolumeClaim si le problème sous-jacent est résolu. Pour en savoir plus sur la restauration ultraprécise, consultez Activer la restauration ultraprécise.

Si le problème persiste ou si la cause de l'échec VolumeRestore n'est pas claire, contactez Cloud Customer Care pour obtenir de l'aide.

Erreur 200060101 : Échec de l'opération de restauration en raison du délai d'expiration de la validation du volume

L'erreur 200060101 se produit lors de la phase de validation du volume d'une opération de restauration lorsque Sauvegarde pour GKE cesse d'attendre, car au moins une ressource VolumeRestore, qui gère la restauration des données à partir d'un VolumeBackup, n'a pas atteint l'état succeeded dans le délai imparti. Il est également possible que d'autres ressources VolumeRestore soient incomplètes.

Le message d'erreur dans le champ stateReason de la ressource Restore affiche la première ressource VolumeRestore rencontrée qui n'était pas encore à l'état succeeded lors de la vérification du délai avant expiration. Il inclut le nom et l'espace de noms PersistentVolumeClaim cibles pour ce VolumeRestore spécifique, par exemple :

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

Sauvegarde pour GKE lance l'approvisionnement des ressources VolumeRestore à partir de PersistentVolumes depuis VolumeBackups. Cette erreur indique que la création du disque persistant sous-jacent à partir de l'instantané et la liaison ultérieure de PersistentVolumeClaim à PersistentVolume ont pris plus de temps que le délai d'attente calculé pour le VolumeRestore cité. D'autres VolumeRestores pour la même opération de restauration peuvent également être dans un état non terminé.

Même si le délai d'attente a été atteint du point de vue de Sauvegarde pour GKE, le processus de création de disque sous-jacent pour la ressource VolumeRestore mentionnée, et potentiellement pour les ressources VolumeRestore, peut toujours être en cours ou avoir échoué.

Pour résoudre ce problème, suivez les instructions ci-dessous :

  1. Identifiez le nom et l'espace de noms PersistentVolumeClaim ayant expiré dans le message d'erreur, par exemple (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Listez tous les VolumeRestores associés à l'opération de restauration pour afficher leur état actuel en exécutant la commande gcloud beta container backup-restore volume-restores list :

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet Google Cloud .

    • LOCATION : emplacement Google Cloud de la restauration.

    • RESTORE_PLAN_NAME : nom du plan de restauration.

    • RESTORE_NAME : nom de l'opération de restauration.

  3. Recherchez les VolumeRestores qui ne sont pas à l'état succeeded.

  4. Obtenez des informations sur le VolumeRestore mentionné dans l'erreur et sur tout autre VolumeRestores qui n'est pas à l'état succeeded en exécutant la commande gcloud beta container backup-restore volume-restores describe :

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Remplacez les éléments suivants :

    • VOLUME_RESTORE_ID : ID de la ressource VolumeRestore.

    • PROJECT_ID : ID de votre projet Google Cloud .

    • LOCATION : emplacement Google Cloud de la restauration.

    • RESTORE_PLAN_NAME : nom du plan de restauration.

    • RESTORE_NAME : nom de l'opération de restauration.

  5. Vérifiez les champs state et stateMessage. La valeur du champ state est probablement creating ou restoring. Le champ stateMessage peut fournir plus de contexte et contenir les détails de la PersistentVolumeClaim cible.

  6. Examinez l'état de la cible PersistentVolumeClaims identifiée en exécutant la commande kubectl get pvc :

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Remplacez les éléments suivants :

    • PVC_NAME : le nom du PersistentVolumeClaim.

    • PVC_NAMESPACE : espace de noms de PersistentVolumeClaim.

    La valeur de status.phase PersistentVolumeClaim's est probablement Pending. Recherchez les erreurs suivantes dans la section Events :

    • Waiting for first consumer to be created before binding : indique que StorageClass est volumeBindingMode: WaitForFirstConsumer.

      Le provisionnement de PersistentVolume est retardé jusqu'à ce qu'un Pod utilisant le PersistentVolumeClaim soit créé et planifié. Le problème peut être lié à la planification Pod, et non au provisionnement du volume lui-même. Par conséquent, nous vous recommandons de vérifier pourquoi les Pods consommant les PersistentVolumeClaim ne sont pas planifiés ou ne démarrent pas.

    • FailedProvisioning ou erreurs du provisionneur de stockage : Par exemple, pd.csi.storage.gke.io.

  7. Examinez les événements GKE dans les espaces de noms concernés en exécutant la commande kubectl get events :

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    Remplacez PVC_NAMESPACE par l'espace de noms de PersistentVolumeClaim.

    Recherchez les événements liés aux noms PersistentVolumeClaim, tels que les messages ou les erreurs de provisionnement.

  8. Consultez les journaux Cloud Audit Logs et les journaux de disque persistant dans Cloud Logging.

  9. Surveillez l'état de tous les VolumeRestores dans les états creating et restoring.

    Une fois le problème résolu, l'état de VolumeRestores peut passer à succeeded ou failed. Si les VolumeRestores atteignent l'état succeeded, les PersistentVolumeClaims doivent devenir Bound et les charges de travail doivent être fonctionnelles. Si un VolumeRestore passe à l'état failed, vous devez suivre des étapes de dépannage pour résoudre l'erreur de validation du volume. Pour en savoir plus, consultez Erreur 200060102 : Échec de l'opération de restauration en raison d'une erreur de validation du volume.

Si VolumeRestores reste à l'état creating ou restoring pendant une période excessive, contactez Cloud Customer Care pour obtenir de l'aide.

Étapes suivantes