Résoudre les problèmes liés aux erreurs système dans Sauvegarde pour GKE

Cette page décrit les erreurs liées au système que vous pouvez rencontrer lorsque vous utilisez Sauvegarde pour GKE, les éléments à prendre en compte lors de la sauvegarde des ressources et les étapes de dépannage.

Erreur 100010108 : Échec de la sauvegarde de PersistentVolumeClaim - CMEK du plan de sauvegarde manquante pour le disque chiffré

L'erreur 100010108 se produit lors de la création de sauvegardes de volumes à portée régionale, et la CMEK du plan de sauvegarde est obligatoire, car le cluster GKE fait référence à un disque chiffré.

Comprendre l'erreur

Lorsque vous créez des sauvegardes de volumes à portée régionale, la clé CMEK du plan de sauvegarde est obligatoire si le cluster GKE fait référence à un disque chiffré. Il s'agit d'une exigence stricte pour les sauvegardes de volumes à champ d'application régional. Si le disque source est chiffré, l'instantané de ce disque n'est possible que si une CMEK de plan de sauvegarde est fournie. Si votre forfait Backup ne comporte pas cette configuration CMEK, la création du snapshot échoue et un message d'erreur semblable à celui-ci s'affiche :

failed to create snapshot as disk "pvc-1" is encrypted with CMEK "projects/proj1/locations/us-east1/keyRings/keyring1/cryptoKeys/key1/cryptoKeyVersions/1", but no Backup Plan CMEK is provided. Please add CMEK to the Backup Plan.

Procédure de dépannage

  1. Identifier la configuration CMEK manquante : le message d'erreur confirme que le PVC en cours de sauvegarde est chiffré, mais qu'il manque une clé de chiffrement dans la configuration du plan de sauvegarde.
  2. Ajouter une CMEK au plan de sauvegarde : mettez à jour la configuration de votre plan de sauvegarde pour inclure une clé de chiffrement gérée par le client (CMEK). Cette clé sera utilisée pour chiffrer les données de sauvegarde, y compris les sauvegardes de volumes à l'échelle régionale.
  3. Assurez-vous d'avoir les autorisations appropriées : vérifiez que le rôle roles/cloudkms.cryptoKeyEncrypterDecrypter est attribué à l'agent de service Sauvegarde pour GKE (service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com) pour la CMEK nouvellement ajoutée.
  4. Testez à nouveau l'opération de sauvegarde : une fois le plan de sauvegarde mis à jour avec la CMEK et les autorisations accordées, réessayez l'opération de sauvegarde.

Erreur 100020102 : CustomResourceDefinition – le schéma n'est pas valide – version v1beta1 de l'API non acceptée

L'erreur 100020102 se produit lorsqu'une tentative de sauvegarde d'un CustomResourceDefinition initialement appliqué en tant que version apiextensions.k8s.io/v1beta1 échoue, car il ne dispose pas du schéma structurel requis dans la version apiextensions.k8s.io/v1 de l'API. Cette erreur génère le message d'erreur suivant : CustomResourceDefinition - has an invalid schema. The resource was originally applied as v1beta1, which has been removed from Kubernetes 1.22+.

Cette erreur se produit, car la version de l'API apiextensions.k8s.io/v1beta1 a été supprimée dans Google Kubernetes Engine version 1.22. Pour en savoir plus sur la suppression d'API pour GKE version 1.22, consultez Suppression d'API pour GKE version 1.22.

Comportement de l'opération de sauvegarde en mode non permissif

En mode non permissif ou dans un plan de sauvegarde strict, l'opération de sauvegarde échoue si elle rencontre une ressource qui ne peut pas être sauvegardée, comme un CustomResourceDefinition créé avec l'API v1beta1. Cette erreur se produit, car la ressource ne dispose pas du schéma structurel requis par l'API v1. La présence de ce CustomResourceDefinition est considérée comme une erreur critique, car il est possible qu'il ne soit pas restauré correctement dans un cluster plus récent.

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

  1. Identifiez le CustomResourceDefinition problématique en exécutant la commande kubectl get crd :

    kubectl get crd CRD_NAME

    Remplacez CRD_NAME par le nom de l'élément CustomResourceDefinition de votre message d'erreur.

  2. Dans la sortie YAML, vérifiez si le CustomResourceDefinition a été correctement converti de l'API vbeta1 vers l'API v1 en localisant les conditions suivantes :

    1. spec.versions : recherchez la condition spec.versions en examinant chaque version listée dans le champ spec.versions. Si le champ schema.openAIV3Schema manque dans l'un des spec.versions, cela signifie qu'aucun schéma structurel n'est défini pour cette version de CustomResourceDefinition.

    2. status.conditions : localisez la condition status.conditions en recherchant la condition type:NonStructuralSchema. Si la valeur status de status.conditions est true, cela confirme explicitement que le schéma n'est pas structurel.

  3. Pour mettre à niveau l'API CustomResourceDefinition vers la version v1, procédez comme suit :

    1. Modifiez la CustomResourceDefinition existante pour la rendre compatible avec la norme v1 en ajoutant un schéma structurel qui définit chaque champ et son type dans la ressource personnalisée. Pour savoir comment ajouter un schéma structurel, consultez Spécifier un schéma structurel.

    2. Appliquez le fichier manifeste v1 compatible à votre cluster.

  4. Si la mise à niveau réussit, réessayez l'opération de sauvegarde. Sinon, utilisez l'une des méthodes suivantes pour résoudre le problème :

    • Supprimez le CustomResourceDefinition en exécutant la commande kubectl delete crd si le CustomResourceDefinition n'est pas utilisé dans le cluster.

      kubectl delete crd CRD_NAME

      Remplacez CRD_NAME par le nom de l'CustomResourceDefinition que vous souhaitez supprimer.

    • Activez le mode permissif sur le plan de sauvegarde, ce qui permet à Sauvegarde pour GKE d'ignorer la ressource, y compris CustomResourceDefinitions dans la version v1beta1 de l'API, et de poursuivre le reste de l'opération de sauvegarde. Pour savoir comment activer le mode permissif, consultez Activer le mode permissif sur un plan de sauvegarde.

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

Erreur 100020103 : Échec de la requête sur les ressources de l'API

L'erreur 100020103 se produit lorsque Sauvegarde pour GKE ne parvient pas à détecter les services d'API Kubernetes personnalisés ou agrégés avant d'effectuer une sauvegarde, ce qui entraîne un message d'erreur indiquant Failed to query API resources. Please check if any API service is unavailable by using 'kubectl get apiservice'. Cela se produit si un service d'API agrégé est mal configuré, ou si ses services et pods sous-jacents sont défectueux ou inaccessibles. En mode non permissif ou dans un plan de sauvegarde strict, Sauvegarde pour GKE arrête l'opération de sauvegarde s'il rencontre un APIService indisponible pour éviter de capturer un état de cluster incomplet ou incohérent.

Pour résoudre cette erreur, procédez comme suit :

  1. Identifiez les services d'API indisponibles en exécutant la commande suivante :

    kubectl get apiservice

    Dans le résultat, recherchez les services d'API où la colonne AVAILABLE est définie sur False.

  2. Inspectez les détails du APIService en échec en exécutant la commande suivante :

    kubectl describe apiservice APISERVICE_NAME

    Remplacez APISERVICE_NAME par le nom du service d'API défaillant, par exemple v1beta1.custom.metrics.k8s.io.

    Dans le résultat, examinez le champ Service sous spec.service et la section Conditions pour identifier le service de sauvegarde, son espace de noms et la cause de l'échec (par exemple, des points de terminaison manquants ou un port cible inaccessible).

  3. Utilisez l'une des méthodes suivantes pour résoudre l'erreur :

    • Restaurez le service de backend : vérifiez que le service de backend dispose de points de terminaison prêts en exécutant la commande suivante :

      kubectl get endpoints -n NAMESPACE SERVICE_NAME

      Remplacez les éléments suivants :

      • NAMESPACE : espace de noms du service de backend.
      • SERVICE_NAME : nom du service de sauvegarde.

      Vérifiez que les pods qui sous-tendent le service existent et qu'ils sont à l'état Running. Résolvez les problèmes de plantage des pods, d'échec d'extraction d'images ou de mauvaise configuration des règles de réseau qui empêchent le trafic d'atteindre le service externe.

    • Supprimer un APIService orphelin : si le APIService appartient à une application, un opérateur ou un outil de surveillance qui a été supprimé ou n'est plus utilisé, supprimez le APIService obsolète :

      kubectl delete apiservice APISERVICE_NAME

      Remplacez APISERVICE_NAME par le nom du service d'API orphelin.

    • Activez le mode permissif : si vous ne pouvez pas corriger ou supprimer immédiatement le service d'API indisponible, activez le mode permissif sur le plan de sauvegarde. Lorsque le mode permissif est activé, Sauvegarde pour GKE poursuit l'opération de sauvegarde. Toutefois, les ressources appartenant au groupe d'API indisponible ne seront pas sauvegardées. Pour savoir comment activer le mode permissif, consultez Activer le mode permissif sur un plan de sauvegarde.

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

Erreur 100040102 : Espace de noms introuvable

L'erreur 100040102 se produit lorsqu'une tentative d'opération de sauvegarde échoue, car un espace de noms spécifié dans le champ d'application de la sauvegarde est introuvable dans le cluster. L'agent Sauvegarde pour GKE n'a pas pu localiser un ou plusieurs espaces de noms explicitement listés dans le champ selectedNamespaces de la configuration BackupPlan. Sauvegarde pour GKE exige que tous les espaces de noms spécifiés soient présents dans le cluster au moment où l'opération de sauvegarde est lancée. Si l'espace de noms est introuvable, le message d'erreur suivant s'affiche :

Namespace [NAMESPACE_NAME] is not found.

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

  1. Vérifiez que l'espace de noms a été correctement saisi en consultant la liste selectedNamespaces dans votre configuration BackupPlan.

  2. Vérifiez que l'espace de noms indiqué dans le message d'erreur existe en exécutant la commande kubectl get namespace :

    kubectl get namespace NAMESPACE_NAME

    Remplacez NAMESPACE_NAME par le nom de l'espace de noms indiqué dans le message d'erreur.

    Si l'espace de noms n'existe pas, un message s'affiche indiquant qu'il n'a pas été trouvé (par exemple, Error from server (NotFound): namespaces "[NAMESPACE_NAME]" not found).

  3. Corrigez le BackupPlan. Si l'espace de noms comporte une faute d'orthographe, remplacez BackupPlan par le nom correct. Si l'espace de noms n'existe vraiment plus et n'a pas besoin d'être sauvegardé, supprimez-le de la liste selectedNamespaces dans la configuration BackupPlan.

  4. Réessayez d'effectuer l'opération de sauvegarde après avoir apporté les corrections nécessaires à BackupPlan, puis lancez une nouvelle sauvegarde.

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

Étapes suivantes