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. Le message d'erreur suivant s'affiche alors. 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. 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 à l'échelle du cluster sont appliquées avant que les services à l'échelle de l'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 à l'aide de 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 utiliser 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 correspondre à 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 stratégies, 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 : utilisez 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 à l'aide de 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é à l'aide de la commande kubectl get events :

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

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

Étapes suivantes