Activer le mode permissif sur un plan de sauvegarde

Cette page explique comment activer le mode permissif sur un plan de sauvegarde.

Lors de l'exécution de la sauvegarde, si Sauvegarde pour GKE détecte des conditions susceptibles de provoquer un échec de la restauration, la sauvegarde elle-même échoue. Le motif de l'échec est indiqué dans le champ state_reason de la sauvegarde. Dans la console Google Cloud , ce champ est appelé Raison de l'état.

À propos du mode permissif

Lorsque les échecs de sauvegarde ne sont pas acceptables et qu'il n'est pas possible de résoudre les problèmes sous-jacents, vous pouvez activer le mode Permissif. Le mode permissif garantit que les sauvegardes sont effectuées, même si des ressources GKE susceptibles de provoquer des échecs de restauration sont détectées pendant le processus de sauvegarde. Des informations sur les problèmes sont fournies dans le champ Motif de l'état de la sauvegarde.

Nous vous recommandons de n'utiliser cette option que si vous comprenez les problèmes et que vous pouvez mettre en œuvre des solutions de contournement pendant le processus de restauration. Pour obtenir la liste des messages d'erreur potentiels dans le champ Motif de l'état de la sauvegarde, ainsi que les actions recommandées, consultez Résoudre les problèmes d'échec de sauvegarde.

Activer le mode permissif

Pour activer le mode Permissif, procédez comme suit :

gcloud

Pour activer le mode permissif, exécutez la commande gcloud beta container backup-restore backup-plans update :

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Remplacez les éléments suivants :

Console

Suivez les instructions ci-dessous pour activer le mode Permissif dans la consoleGoogle Cloud  :

  1. Dans la console Google Cloud , accédez à la page Google Kubernetes Engine.

    Accéder à Google Kubernetes Engine

  2. Dans le menu de navigation, cliquez sur Sauvegarde pour GKE.

  3. Cliquez sur l'onglet Plans de sauvegarde.

  4. Développez le cluster, puis cliquez sur le nom du plan.

  5. Cliquez sur l'onglet Détails pour modifier les informations relatives au plan.

  6. Cliquez sur Modifier pour modifier la section Mode sauvegarde.

  7. Cochez la case Mode permissif, puis cliquez sur Enregistrer les modifications.

Terraform

Mettez à jour la ressource google_gke_backup_backup_plan existante.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Remplacez les éléments suivants :

  • NAME : nom du google_gke_backup_backup_plan que vous souhaitez mettre à jour.

Pour en savoir plus, consultez la section gke_backup_backup_plan.

Résoudre les problèmes d'échec de sauvegarde

Le tableau suivant fournit des explications et des actions recommandées pour différents messages d'échec de sauvegarde affichés dans le champ Motif de l'état de la sauvegarde.

Message d'échec de la sauvegarde Description du message et motif de l'échec Action recommandée

CustomResourceDefinitions "..." have invalid schemas

Description : une définition de ressource personnalisée (CRD) du cluster a été appliquée à l'origine en tant que apiextensions.k8s.io/v1beta1 et ne possède pas de schéma structurel requis dans apiextensions.k8s.io/v1.

Motif : Sauvegarde pour GKE ne peut pas définir automatiquement le schéma structurel. La restauration de l'objet CRD dans les clusters Kubernetes version 1.22 ou ultérieure, où apiextensions.k8s.io/v1beta1 n'est pas disponible, échoue. Cet échec se produit lors de la restauration des ressources personnalisées définies par la CRD. 		Nous vous recommandons d'utiliser les options suivantes :
  • Si vous gérez la CRD, suivez la procédure décrite dans la documentation Kubernetes pour spécifier un schéma structurel pour votre CRD.
  • S'il s'agit d'une CRD gérée par GKE, vous pouvez appeler kubectl delete crd s'il n'existe aucune ressource diffusée par la CRD. Si des ressources existantes sont diffusées par la CRD, vous pouvez activer le mode permissif en comprenant le comportement de restauration. Pour obtenir des recommandations sur les CRD courantes, consultez la documentation.
  • S'il s'agit d'un CRD tiers, consultez la documentation correspondante pour migrer vers apiextensions.k8s.io/v1.

Lorsque le mode Permissif est activé, l'objet CRD sans schéma de structure n'est pas sauvegardé dans un cluster Kubernetes version 1.22 ou ultérieure. Pour restaurer correctement une telle sauvegarde, vous devez exclure les ressources fournies par la CRD de la restauration ou créer la CRD dans le cluster cible avant de lancer la restauration.

Failed to query API resources ...

Description : Un service d'API du cluster est mal configuré. Les requêtes envoyées au chemin d'accès de l'API renvoient alors le message "Échec de la requête des ressources de l'API". Il est possible que le service sous-jacent n'existe pas ou ne soit pas encore prêt.

Raison : Sauvegarde pour GKE ne peut sauvegarder aucune ressource fournie par l'API indisponible. 		Vérifiez que le service sous-jacent est prêt dans le spec.service du service d'API.

Lorsque le mode Permissif est activé, les ressources des groupes d'API dont le chargement a échoué ne sont pas sauvegardées.

Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs

Description : dans Kubernetes v1.23 et versions antérieures, les comptes de service génèrent automatiquement un jeton sauvegardé par un secret. Toutefois, dans les versions ultérieures, Kubernetes a supprimé cette fonctionnalité de jeton généré automatiquement. Un pod du cluster peut avoir installé le volume secret dans le système de fichiers de ses conteneurs.

Motif : si Sauvegarde pour GKE tente de restaurer un compte de service avec son secret généré automatiquement et un pod qui installe le volume secret, la restauration semble réussie. Toutefois, Kubernetes supprime le secret, ce qui bloque le pod dans la création du conteneur et l'empêche de démarrer. 		Définissez le champ spec.serviceAccountName dans le pod. Cette action garantit que le jeton est automatiquement monté sur /var/run/secrets/kubernetes.io/serviceaccount dans les conteneurs. Pour en savoir plus, consultez la documentation Configurer des comptes de service pour les pods.

Lorsque le mode Permissif est activé, le secret est sauvegardé, mais ne peut pas être installé dans les pods des clusters Kubernetes v1.24 et versions ultérieures.

Définitions de ressources personnalisées (CRD) courantes avec problèmes et actions recommandées

Voici quelques CRD courantes qui présentent des problèmes de sauvegarde, ainsi que les actions que nous vous recommandons pour les résoudre :

  • capacityrequests.internal.autoscaling.k8s.io : cette CRD a été utilisée temporairement dans les clusters v1.21. Exécutez kubectl delete crd capacityrequests.internal.autoscaling.k8s.io pour supprimer la CRD.
  • scalingpolicies.scalingpolicy.kope.io : ce CRD était utilisé pour contrôler les ressources fluentd, mais GKE est passé à fluentbit. Exécutez kubectl delete crd scalingpolicies.scalingpolicy.kope.io pour supprimer la CRD.
  • memberships.hub.gke.io : exécutez kubectl delete crd memberships.hub.gke.io pour supprimer la CRD s'il n'y a pas de ressources d'appartenance. Active le mode Permissif s'il existe des ressources d'appartenance.
  • applications.app.k8s.io : active le mode Permissif grâce à une compréhension du comportement de restauration.